GNOME Bugzilla – Bug 723978
ModemManager doesn't work with the new Huawei E5372T
Last modified: 2014-10-15 09:46:18 UTC
Created attachment 268605 [details] Output from "sudo journalctl -b" Unfortunately, ModemManager doesn't work with the new Huawei E5372T. Although it's a wireless modem as well, that's no good for computers that only have ethernet cards. After installing "usb_modeswitch" and connecting the modem to the USB port, I got the attached output from "sudo journalctl -b". Let me know if you need any further information in order to get it working.
Can you get ModemManager debug logs following these steps? http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
Created attachment 271975 [details] ModemManager output after plugging device
Created attachment 271976 [details] NetworkManager output after plugging device
That specific issue (modem not created because no primary port) may already be solved in the following commit: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=accb611e1f7ec648c6a7a6080c89b41fa5f9fd5c Please try with ModemManager git master; and re-open if it didn't fix it.
Created attachment 272038 [details] ModemManager (v1.2.0.104.g31a19c2) output after plugging device
After upgrading to ModemManager v1.2.0.104.g31a19c2, the problem still exists. I've attached the new debug output as requested. Let me know when you'd like me to run another test.
(In reply to comment #5) > Created an attachment (id=272038) [details] > ModemManager (v1.2.0.104.g31a19c2) output after plugging device Thanks; now I see a /dev/cdc-wdm0 being flagged as AT-capable, which is one pretty new thing coming in latest kernels (through the huawei_cdc_ncm) driver. I have a branch to handle that, let me look for it.
There is a branch in the upstream git repository named 'aleksander/huawei-ndisdup-cdc-wdm-rebased-1.2'; can you get it and try with that one?
Created attachment 272097 [details] Debug outputs from MM and NM My modem now shows up in the list, but I can't connect to the network. Due to this, I've broken the log files up into two parts this time. Thanks for sticking with this matter until it's resolved. Telstra is easily the best mobile broadband network in Australia, and this is its latest/greatest modem. It's very important that we get this working! By the way, this is a 4G modem. However, I can only see 2G and 3G options in the "type" list when I edit the connection. When we get this going, will I get the full 4G speeds?
(In reply to comment #9) > Created an attachment (id=272097) [details] > Debug outputs from MM and NM > > My modem now shows up in the list, but I can't connect to the network. Due to > this, I've broken the log files up into two parts this time. > > Thanks for sticking with this matter until it's resolved. Telstra is easily > the best mobile broadband network in Australia, and this is its latest/greatest > modem. It's very important that we get this working! > So now the detection works ok, but the dialling log is too short... did it really get stuck in step 2/8 of the SimpleConnect()? Can you provide a full ModemManager log, including all the detection up until when the modem doesn't do anything else? I'm interested to see whether it got properly registered or not, and how the enabling sequence goes. > By the way, this is a 4G modem. However, I can only see 2G and 3G options in > the "type" list when I edit the connection. When we get this going, will I get > the full 4G speeds? The 'type' values when editing the connection are obsolete; don't look at those. For now, you can check what the output of "mmcli -m 0" is; look for the current allowed/preferred modes there. If the device is 4G it will likely say "2g,3g,4g allowed, none preferred".
Created attachment 272208 [details] Debug outputs from MM and NM Yes, it really got stuck in step 2/8 yesterday! It eventually just went back to showing "not connected" in the GUI. I tried this a couple of times with the same result. Today, I've done things a little differently. I've kept the logs in one piece so that you won't think anything is missing. After plugging in the modem and waiting about 10 seconds for things to settle, I then ticked the "enable mobile broadband" toggle button in the GUI. It then tried to connect a few times without success. After getting bored of this, I then tried to connect manually (like I did yesterday) by clicking on the "Mobile" entry in the connections list. Does the extra information in today's log files help you to diagnose the problem? FYI, I've included the output from "mmcli -m 0" as well. I've removed any bits that seemed unique to this device.
(In reply to comment #11) > Created an attachment (id=272208) [details] > Debug outputs from MM and NM > > Yes, it really got stuck in step 2/8 yesterday! It eventually just went back > to showing "not connected" in the GUI. I tried this a couple of times with the > same result. > > Today, I've done things a little differently. I've kept the logs in one piece > so that you won't think anything is missing. > > After plugging in the modem and waiting about 10 seconds for things to settle, > I then ticked the "enable mobile broadband" toggle button in the GUI. > > It then tried to connect a few times without success. After getting bored of > this, I then tried to connect manually (like I did yesterday) by clicking on > the "Mobile" entry in the connections list. > > Does the extra information in today's log files help you to diagnose the > problem? FYI, I've included the output from "mmcli -m 0" as well. I've > removed any bits that seemed unique to this device. Ok, so the connection logic goes up to the dialling step, where we launch the following: (cdc-wdm0): --> 'AT^NDISDUP=1,1,"telstra.internet"<CR><LF>' (cdc-wdm0): <-- '<CR><LF>ERROR<CR><LF>' So, the modem returns an error to our dialling request, not good. But, what is more interesting is the fact that we're getting these logs: (cdc-wdm0): <-- '<CR><LF>^DSFLOWRPT:000000B2,00000000,00000000,000000000000065C,0000000000000000,00000000,00000000<CR><LF>' huawei_status_changed(): Duration: 178 Up: 0 Kbps Down: 0 Kbps Total: 1 Total: 0 The previous DSFLOWRPT logs are usually seen when the device is already in connected state. So could it be that this is really the case? Maybe the device does auto-connection by default whenever it's plugged in? Can you try to bring the interface up (e.g. ifup wwan0) and run a DHCP client in the interface (e.g. dhclient wwan0)?
Created attachment 272607 [details] Outputs from connection attempt #5 You're right on the money about the connection already being active. I meant to tell you that earlier, but the thought unfortunately got lost before I could put pen to paper. As stated back when I opened the ticket, this modem is Wi-Fi as well as USB. The wireless option is great when I'm on the go with my laptop. However, it's no good at home because my desktop only has an Ethernet card. You can take a look at the device here: "http://www.telstra.com.au/broadband/mobile-broadband/prepaid/devices-and-starter-kits/#tab-4g-wifi". Once the power button is pressed, the device connects automatically. Running "ifconfig wwan0 up" worked fine, but neither "dhcpcd -d wwan0" nor "dhclient -d wwan0" succeeded. I've included all of the relevant output in the attached tarball. Let me know if/when you'd like me to run more tests. I should note that I can successfully connect to the Internet via USB in Windows. The IP address I'm assigned by the modem's DHCP server is the same as the "start IP address" I designated via its settings webpage.
In addition to what I wrote earlier, it turns out that Huawei actually has a Linux version of their Mobile Partner application. The problem is that it wasn't designed to run on Arch Linux, and it'd take quite a bit of fiddling to get it going on my system. At least part of it is licensed under the GPLv2, so you can probably use the relevant bits of code to your advantage. If you're interested, the current release is available here: "http://dl.huaweinews.com/USB-Modem/mobile-partner-23.009.09.02.910.zip".
(In reply to comment #13) > Created an attachment (id=272607) [details] > Outputs from connection attempt #5 > > You're right on the money about the connection already being active. I meant > to tell you that earlier, but the thought unfortunately got lost before I could > put pen to paper. > > As stated back when I opened the ticket, this modem is Wi-Fi as well as USB. > The wireless option is great when I'm on the go with my laptop. However, it's > no good at home because my desktop only has an Ethernet card. > > You can take a look at the device here: > "http://www.telstra.com.au/broadband/mobile-broadband/prepaid/devices-and-starter-kits/#tab-4g-wifi". > Once the power button is pressed, the device connects automatically. > > Running "ifconfig wwan0 up" worked fine, but neither "dhcpcd -d wwan0" nor > "dhclient -d wwan0" succeeded. I've included all of the relevant output in the > attached tarball. Let me know if/when you'd like me to run more tests. > > I should note that I can successfully connect to the Internet via USB in > Windows. The IP address I'm assigned by the modem's DHCP server is the same as > the "start IP address" I designated via its settings webpage. Oh well, this is a whole different thing then :) So, the modem gets automatically connected because that is what's supposed to be doing. In your case, you'll get a network interface exposed by the kernel and what you need to do is configure a static IP address (the "start IP address") in that interface. So, you shouldn't treat this interface as a modem actually, even if it is, as you're managing it from its built-in web server. This is unfortunate, but there's little we can do in ModemManager to handle that. We could of course TRY to detect that this is such a modem and completely avoid it in ModemManager. Actually, there are plans to do so, so that MM decides it's an unmanaged WWAN device and tell that to NM so that it treats the interface as any other e.g. Ethernet interface you have in the system. I'm going to resolve the bug as NOTGNOME as we're moving all bugs to the new ModemManager bugzilla in fd.o. Also, you may want to follow this bug: https://bugs.freedesktop.org/show_bug.cgi?id=85041