This has been an issue I have been fighting for a couple of weeks. I have a BBB with Ubuntu. Everything runs great and I am developing python controlled GPIO and such. I am picking up learning ARM development as well as Linux usage programming.
My application requires connecting the BBB to another ARM board (custom board) . This board has a USB slave/client port that connects to a laptop USB host ( and will send the laptop an IP address with udhcpd) and everything is fine. I can connect this board to the BBB and then connect the BBB to my laptop (and also have the BBB Ethernet connected to my network) and everything gets an IP address is fine. HOWEVER I can only get this to work if connections are made in a particular order!!! I must first boot BBB WITHOUT the the ARM board connected to the BBB host. Then once it boots I can connect and BBB (manually bring up usb1) receives an IP address from the ARM and the BBB can also give a separate IP address to the laptop, everyone is happy. The ARM-BBB connection is usb1 and the BBB client port is usb0 as expected. My set-up will require the second ARM board to be connected to the BBB on boot(as they will be tethered inside of an enclosure). When I do this nothing works. I cant even get the BBB to give an IP address to my laptop. It seems that the RNDIS/Ethernet gadget that is on usb1 (ARM connection) affects BBB usb0 and screws up the dhclient and udhcpd services and gets confused. I am not knowledgeable enough at Linux networking to figure this out. I have tried many different configs in /etc/network/interfaces but to know avail. I get a feeling its a dhclient and/or udhcpd configuration issue.
If someone could give me some guidance on solving this it would be appreciated. If there is any info I can provide that will help let me know.
I am assuming this can be duplicated by someone who has two BBBs .
Yes, that was my backup plan. I would delay the power up of the secondary board until the BBB reaches a certain point in its boot cycle. However I am trying to minimize the hardware changes. Is there any pure software change that would have the same effect? What is actually going on with the BBB? Is it seeing the usb gadget first and assigning it the usb0 default interface and that screws everything else up?
I know there is a way to assign network interfaces to actual hardware addresses but everytime it boots the usb1 interface for the rndis/ethernet gadget changes? Is there a way to always assign it to usb1 and the BBB usb client to usb0?
You are dependent on modules here:
g_ether : provides support for the OTG port acting as an ethernet interface [ie plugging it in to your PC and it shows up as an ethernet card]
cdc_ether: provides support to USE an ethernet interface provided by some other device via the USB host port.
I’m using Robert Nelsons excellent Ubuntu kernel, and checking the kernel compile config, I see that it has:
CONFIG_USB_NET_CDCETHER=y
AND
CONFIG_USB_ETH=m
The first line means that the support for USING a usb ethernet device is compiled into the kernel itself, you can’t turn it off or on.
The second line means that support for ACTING as a usb ethernet device is compiled as a module, so you can use
‘insmod g_ether’ to enable it [or add it to your modules.conf file to have it loaded automatically].
If you compile your own kernel, then you could set them BOTH to be modules. Then you can decide when to have the modules loaded. Ie you could place g_ether into the modules.conf file to have it loaded automatically. Then you could create a file such as:
That is excellent information and I think you hit the nail on the head. I am also using Robert Nelsons Ubuntu image however I am not knowledgeable or brave enough at this time to try to compile my own kernel. I will fisrt look into the fact that the external ARM board is being assigned to usb0 and the BBB slave port as usb1 If that is what is gong on . I will modify references to those interfaces in /etc/network/interface file as well as dhclient and udhcpd services. If that works that will be easiest fix for my application. If not I will learn the udev rules as you mentioned. I will post with the results.
Gary, thanks again for your very useful advice. I owe you a beer!