dhcpcd5 cannot cope with USB bus resets #102
Comments
|
Comparing the output from configure, the difference is this: Maybe building with |
|
So I don't forget: We used to have trouble with persistent interface names failing because the the system would try to rename them while dhcpcd had hold of them. The problem seemed to go away 'on its own', but now I suspect it's because we started building with libudev available on the build machine. From README:
|
|
Quick glance at the logs you posted. It looks like in the working case: In the non-working case. I think we'd need to check what udev event dhcpcd is listening for that's making it decide that the interface has departed when there are no kernel messages to suggest that that's the case. |
|
The output of |
|
Looks like you can also launch dhcpcd with |
|
There's a race between the kernel and udev. In the working case, whereas in the nonworking case it's |
|
I can confirm that adding |
|
The issue is apparently gone in 7.0.3. There's 432 commits between it and 6.11.5 but none of them strikes me like an obvious candidate, so I'm bisecting to find the fix. |
I believe we have to have udev support for persistent interface names to work reliably. Ideally, we'd backport a fix. |
|
Sorry I was mistaken, I did manage to reproduce the issue with 7.0.3 now. |
|
Might be worth reporting the issue on the dhcpcd mailing list.
|
…ion) After an EMI-induced USB bus reset, the on-board Ethernet interfaces should be brought up again and assigned IP addresses. On jessie this required amending /etc/network/interfaces, but on stretch, dhcpcd is used instead. Nevertheless add the required directives as comments to /etc/network/interfaces in case users prefer not to use dhcpcd. There's an issue with dhcpcd wherein address assignment after a bus reset fails if kernel and udevd uevents are received in a specific order. Work around by disabling reception of udevd uevents for now. Link: RPi-Distro/repo#102 Signed-off-by: Lukas Wunner <lukas@wunner.de>
|
@XECDesign: The issue is now fixed on the dhcpcd master branch with commit rsmarples/dhcpcd@cd3ab83. Could you cut a new release of the dhcpcd Raspbian package one of these days with the commit cherry-picked? I've double-checked that 6.11.5 plus this commit compile cleanly and fix the issue. Thanks! |
|
Thanks. A new dhcpcd package should hit the repo shortly. |
|
Okay I've verified that the issue is gone in dhcpcd5_6.11.5-1+rpt5. Thanks a lot! |
The Revolution Pi products are used in EMI contaminated environments, which results in occasional USB bus resets. It is crucial that after a bus reset, the smsc95xx interface is brought up again and assigned an IP address so that the product remains reachable over the network.
On Raspbian jessie we ensured that with an
allow-hotplug eth0directive in/etc/network/interfaces, but on stretch the interfaces are handled by dhcpcd by default. When simulating a bus reset using usbreset on stretch, it turned out that dhcpcd fails to assign an IP address after a bus reset most of the time:So I cloned the original repository, checked out the dhcpcd-6.11.5 tag, extracted dhcpcd5_6.11.5-1+rpt4.debian.tar.xz and invoked
dpkg-buildpackage -b -us -uc -a armhf. Surprisingly, bus resets are handled flawlessly with the resulting package:I then compared the dhcpcd-6.11.5 tag with the source package but they are identical.
Something is fishy here. Either you've made modifications to the source code which are not part of
dhcpcd5_6.11.5-1+rpt4.debian.tar.xz, or the change in behavior was caused by a different build environment. To allow you to verify the latter, I'm including the output of theconfigurebuild stage below. Either way, we'd appreciate if the issue could be fixed in Raspbian, because even though we can ship a working deb package to our customers, they might overwrite it with a non-working package made available later by the Foundation. Thanks!Cc: @mduckeck
The text was updated successfully, but these errors were encountered: