Re: BeagleBone Black USB networking - DHCP failing to respond

[Eric Brundick]

Wow, just found the "journalctl" command... logs are kept in an organized "journal" on this system, so "journalctl -b" shows you all daemon messages from the current boot.  Haven't experienced this problem in a bit but I'll post journal logs when it crops up.

I also just ran "opkg update ; opkg upgrade" and got the newest version of everything, so maybe it's fixed...

On Sunday, April 28, 2013 8:24:19 AM UTC-4, Eric Brundick wrote:

Hi folks!  I am quite happy to have received my BBB so early after ordering and so I've tinkered with it a bit.  One thing that keeps cropping up is occasionally my Mac cannot see the BBB over the private USB network link between it and the bone's USB Mini-B connector.

I have the Mac drivers installed per the beaglebone's start page, the Mac can of course see the BEAGLEBONE USB mass storage volume, but that USB network link--while it does show up on both the Mac and the bone, occasionally the DHCP doesn't seem to work.

Details:

From the Mac's perspective, "en4" is the device configured for this link:

en4: flags=863<UP,BROADCAST,SMART,RUNNING,SIMPLEX> mtu 1486

ether c8:a0:30:af:99:29 

inet 169.254.58.84 netmask 0xffff0000 broadcast 169.254.255.255

media: autoselect

status: active

In the System Properties>Network>BeagleBoneBlack settings I have attempted forcing it to "Renew DHCP Lease", it always seems to fail and leaves the IP address at 169.254.58.84.

From the BeagleBone Black's perspective, viewed over the FTDI serial console:

usb0      Link encap:Ethernet  HWaddr A2:24:F6:7B:22:16  

          inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:89 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:25442 (24.8 KiB)  TX bytes:3626 (3.5 KiB)

root@beaglebone:/lib/systemd/system# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.7.0     0.0.0.0         255.255.255.252 U     0      0        0 usb0

Everything looks good there, and I noticed there is a "udhcpd" service that serves out the DHCP replies:

root@beaglebone:/lib/systemd/system# ps auxwww | grep udhcp

root       759  0.0  0.1   2152   712 ?        Ss   00:30   0:00 /usr/sbin/udhcpd -f -S /etc/udhcpd.conf

root       783  0.0  0.1   1960   612 ttyO0    S+   00:38   0:00 grep udhcp

However, watch this tcpdump from the BeagleBone while I issue the "Renew DHCP Lease" from the Mac:

root@beaglebone:/lib/systemd/system# tcpdump -i usb0 -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on usb0, link-type EN10MB (Ethernet), capture size 65535 bytes

00:38:54.329377 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:38:54.529492 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:38:55.717268 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:38:57.813579 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:39:02.646378 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:39:10.746119 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

00:39:19.651589 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:a0:30:af:99:29, length 300

Obviously the USB network link is working, but I presume that "udhcpd" process isn't replying?

FYI the Ethernet is not plugged in.

While I am no stranger to Linux I am quite new to Angstrom.  Is there any logfiles or other manner of obtaining syslog info that udhcpd might be kicking out to help diagnose further?

Thanks!

[Eric Brundick]

FYI ever since performing the opkg upgrade, I've not seen this issue occur.

There seems to be a small glitch in the opkg upgrade procedure; the new kernel "kernel-image-3.8.8" refuses to install since it overwrites some driver files provided by the old kernel-image-3.8.6, so you have to manually install it:

opkg --force-overwrite kernel-image-3.8.8

I found this out only after I put my BBB into a non-bootable state and had to recover it (with the uboot command prompt, forcing it to boot the old kernel).

[Jason Stapels]

Now you tell me! :-)

Thanks for the tip... I'm still a little rattled from recovering from my own unbootable state so I think I'll hold off a bit before the upgrade and stick to working from my linux box. (I wasn't aware of the uboot stuff, but I was able to force it to boot of the SD by holding down the POWER button for an extended length of time).

~ Jason

[Eric Brundick]

I take it back, just had the DHCP issue pop up again.

Tcpdump shows inbound DHCPREQUEST's coming from the Mac, journalctl -b shows DHCP OFFERs being sent from udhcpd but I'm not seeing them from tcpdump.

Jan 01 00:10:06 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:08 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:08 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:10 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:10 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:14 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:14 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:23 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:23 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:31 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:31 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:40 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:40 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:49 beaglebone udhcpd[261]: Sending OFFER of 192.168.7.1.[m

Jan 01 00:10:49 beaglebone g-ether-load.sh[126]: Sending OFFER of 192.168.7.1.[m

[Eric Brundick]

For what it's worth, from the BeagleBone trying to ping 192.168.7.1 does not show up in the "tcpdump -i usb0 -n" output.  So there's something goofy going on there.  Likewise the usb0 entry in ifconfig shows that it has not really attempted much in the way of TX packets:

usb0      Link encap:Ethernet  HWaddr B6:10:BA:3D:01:25  

          inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:173 errors:0 dropped:0 overruns:0 frame:0

          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:53796 (52.5 KiB)  TX bytes:2249 (2.1 KiB)

TX packets 8?  I must've sent 30 pings over the wire to 192.168.7.1 (which my Mac does not have, it's showing a 169.254 type of address despite multiple presses of the Renew DHCP Lease button in System Preferences.)  The routing table clearly lists usb0 as the destination for 192.168.7.0/30 frames:

(from ip route ls)

192.168.7.0/30 dev usb0  proto kernel  scope link  src 192.168.7.2

Something's definitely wrong here with the USB network driver.  I don't see any iptables rules in place.  udhcpd is clearly receiving the DHCP requests and is clearly sending replies per its log, but nada over the wire.

[Eric Brundick]

Alright I'm gonna have to point the finger at the Mac now.  The problem consistently disappears when I restart the Mac (reboot works, not just power-cycle), and consistently comes back when I power-cycle the 'bone after that first working session.  Using kextunload on HoRNDIS and kextload doesn't seem to help so I suspect a bug in the Mac's USB subsystem that clears up after a reboot.

[Eric Brundick]

Just caught this message on the serial debug console when rebooting the BBBlack without rebooting the Mac-

The Angstrom Distribution beaglebone ttyO0

Angstrom v2012.12 - Kernel 3.8.8

beaglebone login: [   12.013822] systemd-udevd[89]: worker [118] terminated by signal 11 (Segmentation fault)

[   12.156035] systemd-udevd[89]: worker [118] failed while handling '/devices/ocp.2/47400000.usb/musb-hdrc.0.auto/gadget/net/usb0'

[Jason Stapels]

For the noob's here, how are you accessing the serial console to view these messages?

Is that virtual device via the same USB connection or do I need to have an FTDI cable?

[Eric Brundick]

FTDI cable.

[Eric Brundick]

Also starting to notice that one USB port on the Mac works a lot better than the other.  Such a strange issue especially the way it manifests itself from the beaglebone linux side...