wwan0 interface not working under Stretch (no IPv4 address) #2544
Comments
|
I believe there is a kernel command line option that may help - add |
|
Here is my cmdline.txt: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=30ff3213-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait ipv6.disable=1 Adding that option did not resolve the issue, here is the relevant section from syslog: There are a few additional error messages but same result. |
|
Did you disable new Predictable Network Interface naming, which is now default on Stretch? Alternatively, update your network config files and reference interfaces with their new predictable names. |
|
I think your IPv6 theory might be a red herring - that "carrier lost" message looks more significant.
|
|
The 3g modem is actually externally powered so I don't believe power is the problem here. I tested some older Raspbian installs and with interesting results:
And the version I provided partial logs for previously was the latest 2018-04-18-raspbian-stretch-lite which also fails to get an IP address. I've attached the syslog from a fresh image for both of these versions. The line that seems to indicate something is wrong is "wwan0: carrier lost" 2017-09-07-raspbian-stretch-lite.log |
|
That's about as narrow a time range (for images, at least) that we could have hoped for. 2017-09-07 is 4.9.41 (this firmware commit), while 2017-11.29 is 4.9.59 (here). Considering that, the traces are quite different. Looking for wwan0 messages we get (old, good): vs (new, bad): If you've got the time, could you try upgrading the firmware of the older, working image: Obviously I'd like to know if it stills works after the update. Afterwards you can revert using: If you are really keen, you could cross-check the result by downgrading the firmware of the newer image using the same hashes as before but in the reverse order, i.e. b9becbb to downgrade, then a6b3e85 to get back. |
|
Sorry for the delay, I've been on holiday. OK the plot thickens...I have run the tests as you suggested, and here are the results: Starting with 2017-09-07-raspbian-stretch-lite.img,
Then I started again with a fresh 2017-11-29-raspbian-stretch-lite,
|
|
I think that lets the kernel off the hook. @XECDesign Can you think of a change between the 2017-09-07 and 2017-11-29 releases that might have broken wwan/3G connectivity in this way? |
|
Does putting |
|
adding In the bad cases, it looks like dhcpcd is trying to assign an IPv6 address to the wwan0 interface, when in fact, I don't think the wwan0 supports IPv6. |
|
Does this fix the issue? |
|
Before you try that, it would be interesting to know whether I am sure the culprit is the jump from dhcpcd 6.10.1 to 6.11.5, but checking whether ipv6 is a red herring may be useful information when determining why that jump breaks it. |
|
Adding However downgrading to dhcpcd 6.10.1 and restarting dhcpcd did - the IP address is now present on wwan0 and the interface works as expected. I also tried a fresh install of 2018-04-18-raspbian-stretch-lite, (where wwan0 doesn't have an IP out-of-the-box) and can confirm that the downgrade of dhcpcd works for that too. |
|
Thanks for confirming. It may be worth sending an email to the dhcpcd mailing list (bottom of the page here https://roy.marples.name/projects/dhcpcd). Otherwise, I can take a look into later at some point. |
|
Thanks, I have posted to that list https://roy.marples.name/archives/dhcpcd-discuss/0002101.html |
|
@spl237 This one's on us. From what I gather, that patch ends up treating 3G modems as wifi devices and starting wpa_supplicant, which doesn't make sense. |
|
OK, it's trivial to fix - I'll just patch to check for "wlan" rather than "w". Odd that the OP reports it works properly under jessie, though, as the code in our jessie release of dhcpcd has the same test for "w" as above. (I think it was missed out for a few months after we updated to stretch, but we put it in back in November last year.) |
|
I think in jessie 3g modems showed up as serial devices and were handled through ppp rather than showing up as wwan devices, but I'm not sure. Another user reported on the mailing list that everything worked fine for them on the latest version of dhcpcd until an upgrade broke it, which would probably be when we added this patch back in. |
|
Out of curiosity: can't such kind of tests be done after actual interface types rather than after their names? |
|
This is a hack to deal with a badly-behaved driver for a particular wifi dongle, which does not correctly set internal flags and so is not identified as a wifi device. Hence in the case of this one device, we unfortunately do need to make an assumption based on its name... |
|
That's something Roy pointed out as well. There's probably going to be some inconsistent behaviour if interfaces are renamed using udev rules or through persistent network interface naming. |
|
We could just tell anyone with an Edimax dongle to throw it away and buy another one! Or tell whoever wrote the driver / firmware for it to fix the problem and not support it in the meantime... |
|
If it is a driver issue we can patch it in raspberrypi/linux. |
|
If you're up for it, I think this is the driver (but it's worth double-checking): And Roy's description of the problem:
|
|
A version of dhcpcd with that patch removed to help confirm that that was the problem: |
|
I can confirm that dhcpcd5_6.11.5-1+rpt5_armhf.deb does not work, but dhcpcd5_6.11.5-1.rpt6.test_armhf.deb does! |
|
@spl237 Have you any idea which internal flags are being incorrectly set in the driver? I'm happy to fix this up if I know what to fix! Or has it already been done? Not sure of exact status of this one. |
|
@JamesH65 An interim fix is to modify the patch (#2544 (comment)) to check for interfaces starting with "wl" (eg. wlan0) rather than just "w" |
|
@spl237 ISTR us discussing this? Cannot remember what the result was. |
|
We couldn't find a dongle that exhibits the behaviour the patch was added to fix. It's probably better to revert the patch anyway and then if the problem resurfaces again, fix it properly in the driver. |
|
The latest version of dhcpd in apt has the fix, so this can probably be closed. |
|
Thanks all, esp. @XECDesign |
|
Looks like this has indeed found the faulty driver: |
My RPI Model 2B is connected via USB to a 3G modem that uses the sierra_net driver.
Under Jessie, when the modem has a data connection, I get an IPv4 address on wwan0, and can access the Internet.
Under Stretch, it seems to try to assign an IPv6 address rather than an IPv4 address, but then reports the carrier as lost immediately:
I don't believe my carrier is assigning an IP6 address, but it looks like the OS can't pick up the right IP?
If I manually run "dhclient wwan0" on Stretch then the right IPv4 address is shown, and the interface works as expected.
How can I resolve this issue?
The text was updated successfully, but these errors were encountered: