Jump to content
dude67

Huawei E367 not detected in Mageia [solved]

Recommended Posts

Sweet :thumbs:

 

Glad you got it sorted. Usually the path is required, because normally as users, we have various environment variables set that allow it to work for us. But things like udev, etc, won't have paths set up, and so requires it being provided in it's full entirety :)

 

So I'll take those virtual :beer: and change them into real ones located in my fridge :)

Share this post


Link to post
Share on other sites

# Huawei, newer modems
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

This is the rule in ‎/lib/udev/rules.d/40-usb_modeswitch.rules that works on one of the computers but not the other.

Note that the full path to usb_modeswitch is not used.

I don't know if this is a bug or the result of security setting and as I don't have the hardware I can't test or report a bug.

Share this post


Link to post
Share on other sites

Now thinking about that, it would have had the same effect if I'd added the full path to the existing rule (40-usb_modeswitch.rules file).

 

Perhaps I should test that. But if that's the case, how come it works with the first system and not the second?

 

OK, in the first case (worked out of the box) it was recognized as

Bus 002 Device 004: ID 12d1:1506 Huawei Technologies Co., Ltd.

But in the second system (did not work originally) it was recognized as

Bus 001 Device 008: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552 (HSPA modem)

Is that the reason it worked on one machine and not on the other? If so I guess the question is: why is it recognized as different types in different Mageia1 system?

Share this post


Link to post
Share on other sites

Now thinking about that, it would have had the same effect if I'd added the full path to the existing rule (40-usb_modeswitch.rules file).

 

Perhaps I should test that. But if that's the case, how come it works with the first system and not the second?

 

OK, in the first case (worked out of the box) it was recognized as

Bus 002 Device 004: ID 12d1:1506 Huawei Technologies Co., Ltd.

But in the second system (did not work originally) it was recognized as

Bus 001 Device 008: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552 (HSPA modem)

Is that the reason it worked on one machine and not on the other? If so I guess the question is: why is it recognized as different types in different Mageia1 system?

The last question is the easy one. :D

Both systems recognized it as a 12d1:1446 or mass storage mode, on one system usb_modeswitch did it's job and switched it to a 12d1:1506 or modem mode, on the other it didn't.

 

The question now becomes why and that's why I asked about security settings.

If one is set to Standard and the other to a higher level it might explain things.

Share this post


Link to post
Share on other sites

The question now becomes why and that's why I asked about security settings.

If one is set to Standard and the other to a higher level it might explain things.

Sorry, didn't realize you had asked me something...

 

Anyway, both are set to standard level security.

Share this post


Link to post
Share on other sites

dude67, no one can force you to join the Mageia community and report bugs and no one can prevent your use of Mageia. :D

 

The choice is yours, the loss is that other Mageia users and developers learn nothing from your experiences but as I said the choice is yours.

Share this post


Link to post
Share on other sites

dude67, no one can force you to join the Mageia community and report bugs and no one can prevent your use of Mageia. :D

 

But I am a member of the Mageaia forum and have asked there a question recently...

 

I just thought this was a better forum for this type of question. Had it been a purely Mageia related problem, I would have asked it there.

 

And I think it's their (the developers) loss, if they don't frequent here at MUB. We have a huge database of solutions to different problems. B)

Share this post


Link to post
Share on other sites

The decision about where to ask about a problem is chosen by the user (dude67) in this case, so he has the right to ask it here, or on the Mageia forums or on any other Linux forum to get a solution to his problem. As Mageia is Mandriva based, then there is still a reason why he has chosen to ask his question here or more importantly he asked it here because he has been frequenting here for a long time now and is a regular member like most of us here. Anyone who uses google, will find it. A quick search of google proves this:

 

http://www.google.co.uk/search?hl=en&safe=off&site=&q=mageia+huawei+e367&oq=mageia+huawei+e367&aq=f&aqi=&aql=&gs_sm=e&gs_upl=385l4809l0l5637l18l18l0l10l10l0l235l1485l0.3.5l8l0

 

simple, few keywords of mageia huawei e367 and this site provides the first search results. I didn't force google to do it. Anyone using Mageia would then find these results. If dude67 is happy asking his question here about another distro, and gets his answer/solution, that's great :thumbs: if not, he can always ask it in alternative forums. I personally, generally start here, and try elsewhere if I don't find a solution, but then the majority of the ones I've asked of late have been more complex :)

Share this post


Link to post
Share on other sites

The decision about where to ask about a problem is chosen by the user (dude67) in this case, so he has the right to ask it here, or on the Mageia forums or on any other Linux forum to get a solution to his problem. As Mageia is Mandriva based, then there is still a reason why he has chosen to ask his question here or more importantly he asked it here because he has been frequenting here for a long time now and is a regular member like most of us here. Anyone who uses google, will find it.

Yes of course he has every right to seek help here or anywhere else he feels comfortable and he did get the help he needed here. :D

 

What I was trying to point out which I guess I didn't fully explain is that if it is a bug in usb_modeswitch, usb_modeswitch-data or the kernel-server and it does look like a bug in one of those it will not get fixed if it's never reported.

 

Yes one can search the Internet for workarounds for problems like (dude67) has found for his problem but wouldn't it be better if the problem was fixed at its source so that it just worked?

 

@ dude67

If you decide to report this on the Mageia forum or file a bug report at https://bugs.mageia.org/ (it's up to you) it is not a problem to give a link to this thread rather than starting at the beginning and retyping everything.

 

By the way I do have the utmost respect for the members here and the help they give or I would not be here. :D

Share this post


Link to post
Share on other sites

@ ken, "By the way I do have the utmost respect for the members here and the help they give or I would not be here."

 

I never doubted that for a second. :-)

 

Cheers. John.

Edited by AussieJohn

Share this post


Link to post
Share on other sites

@ ken, "By the way I do have the utmost respect for the members here and the help they give or I would not be here."

 

I never doubted that for a second. :-)

 

Cheers. John.

 

Me either :) btw Ken, agree with you about the bug, although it should be dead easy to fix, if they just fix the rule to have the full path like we did here, then it would work for all installs :)

 

But is a weird one in that it works on one and not the other without the amendment.

Share this post


Link to post
Share on other sites
But is a weird one in that it works on one and not the other without the amendment.

Looking back the working system was a desktop kernel and the problem one was a server kernel which I ignored at the time as I thought that the only difference in the server kernel was support for PAE (Physical Address Extensions) but it may have security measures built in that require the full path to usb_modeswitch in udev rules.

 

We'll never know until someone files a bug report so that the developers can look at the problem.

Share this post


Link to post
Share on other sites

Looking back the working system was a desktop kernel and the problem one was a server kernel which I ignored at the time as I thought that the only difference in the server kernel was support for PAE (Physical Address Extensions) but it may have security measures built in that require the full path to usb_modeswitch in udev rules.

 

We'll never know until someone files a bug report so that the developers can look at the problem.

 

It was actually the other way around :) server version worked, but desktop one didn't. His laptop has server kernel, and his wife's that failed with the desktop one. Although, the path would be better off provided by default, that way the problem wouldn't occur irrespective of kernel or other potential measures be it the security level or something else.

Share this post


Link to post
Share on other sites

It was actually the other way around :) server version worked, but desktop one didn't. His laptop has server kernel, and his wife's that failed with the desktop one. Although, the path would be better off provided by default, that way the problem wouldn't occur irrespective of kernel or other potential measures be it the security level or something else.

You're correct Ian, I'll have to learn to read. :D

 

Also of note is that the working machine is running an older kernel than the problem machine. When/if he updates the kernel on his machine he may run into the same problem.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...