USB Ethernet Adapter disables onboard Adapter?

Maybe this is caused by some "clever" piece of software? Often when a USB networking device is available the user wants to use that. I think "networkmanager" can be configured to behave like that, but I do not use it on most of my Raspberries.

Anyway, it would be better to get a VLAN capable switch instead of an extra adapter. You can use the single network interface for different VLANs and you can do a lot more clever things on your network with a switch like that. (e.g. isolating some systems in a separate network, have a public WiFi that does not connect to the rest of your LAN, etc)

A Wireless USB adapter works on mine at the same time as the onboard ethernet. TP-Link (something) from Amazon.

Alternatively, a Huawei HiLink (something or other) from 3UK, for a mobile internet connection.

--

Chris Elvidge 
England 
mailto:elvidge@eim.ae

I think the Pi's on-board Ethernet adapter is already a USB Ethernet adapter - i.e. it isn't a proper, independent, Ethernet adapter. This may be causing the problem though I can't think why.

Another Dave

--
Change nospam to gmx

Apart from the helpful comments posted so far, it's worth noting that you won't get anything like interface speed -- both adapters will in effect be running off a single USB controller.

You are all lacking basic linux sysadmin skills.

This is a feature. USB devices are added in the order they were discovered, and that depends on the order things are enabled in the kernel. Sometimes this can be a little random.

This has some implications for USB devices, like the builtin ethernet and the plugin USB ethernets. The r-pi devices are rather slow in discovery, taking tens of milliseconds to initialise. This means that external USBs gets discovered first.

Since Linux assigns ethX names to the devices as they are discovered, this means that the "outboard" usb takes over, unless you override this in udev.conf. (/etc/udev/rules.d/xxxx). man udev for more info about this than what you ever wanted to know.

In a normal, autoconfigured smb, ipv4+dhcp and ipv6+ra network setting this is of absolutly no consequence. The ethernets will discover their role within about 5 seconds without manual intervention.

But if you start hacking you need to do it right, and make a file in /etc/udev/rules.d that assignes the low-level addresses to the ethernet in question.

Or you just accept the order the r-pi discovers stuff, and configure them accordingly. With an outboard USB as eth0 and the builtin one as eth1 (say "ifconfig -a" to see all the interfaces, even the quiet, unconfigured ones) you need to configure the ethernets for this hardware layout.

This is a machine built by hackers for hackers. If you cannot even handle a manual ifconfig from a peecee to a r-pi then you should go buy a mac.

seriously. Even the peecee is too much for you.

-- mrr

Now everyone knows why Linux people are considered A$$hol#s

You mean because one person said something you don't like, you ascribe a negative property to *all* people who use Linux? Very mature reasoning.

Jim

Finally, we've got a flame going!

--
It's a money /life balance.

This make two.

Thanks for your replies and flames :-)

The problem still is unsolved. I started reading the udev manual but this is really too much for that problem. Since I have tons of problems with my RPis I consider dumping them all, buy a used PC, buy some other

*reliable* hardware or wait for something wonderful happening (like peace on earth, end of hunger, Snowden getting married to his gf, whatever ...)

Gregor

I suspect it's because the external USB Ethernet adaptor has so far been discovered first and given the settings that you originally made for the built-in interface.

I had a similar problem with a full size x86 box, containing two PCI NICs, that I used several years ago as a firewall. The two NICs were not detected in a consistent order, so sometimes the internal and external ports were swapped and it didn't work.

In my case above the problem was solved by substituting a two port NIC. I'm sorry to say that I don't know how to solve your problem, if it turns out to be the same one.

Dave

Known issue with parallell discovery of units. You need to make explict udev entries for them.

-- mrr

I don't know about the other problems you have had but in my experience the one you have with ethernet being disabled may well be more to do with Linux (or the way your distribution is configured) than the Pi. That's for a number of reasons including experience with Linux on desktop PCs.

By the way, looking back over the thread I don't see anyone advising you to use Unix commands to check status. What output do you get from

ifconfig -a lsusb

You could run them before and after the USB Ethernet device is connected and also watch the system log with

tail -F /var/log/syslog

Of the three, ifconfig -a should be the most informative. If you are still interested perhaps you could post the before and after results here or in a Linux newsgroup.

James

I have a similar problem with the server and three RS232 USB convertors. They may or may not be detected in the same order on each boot, plug/unplug one or more and things move around.

This "wandering" is work aroundable with udev rules. The learning curve for udev is a bit steep but it's not difficult. An example, RS232 USB:

KERNEL=="ttyUSB[0-9]*", ID=="4-2:1.0", SYMLINK+="apcups"

Expanded the above means when the kernel device name is ttyUSB 0 to 9 followed by anything and the associated USB port ID is 4-2:1.0 make a symlink apcups to that kernel device. I expect that can be modified to work for the USB ethernet ports.

The hard bit might be finding the string to use for the ID, I can't remember the exact command I used... try pokeing about with udevinfo.

--
Cheers 
Dave.

Forgot that ID number is the ID of the physical port rather than any unique ID of a device plugged into any port. If your device does have a unique ID testing for that is better as you can plug it into any port, in any order, and it will be correctly "found". Using the physical port ID means you have to plug the expected kit into the right physical port.

--
Cheers 
Dave.

What does lsusb say, both with and without the external adaptor fitted?

Heh, I just did but you beat me to it. :-)

The way to fix this, in my experience, is with udev rules keyed on MAC address; I imagine USB network adaptors could be constrained the same way, though I haven't had occasion to find out.

R

Also, you can turn on udevd logging in the /etc/udev/...conf file and then you will find the IDs as the devices are discovered written to the syslog. (/var/log/.....log files).

Yes, this has a steep learning curve; but you ARE poking about in Linux internals now, and you ARE using the kernel as a router, which are rather advanced subjects.

-- mrr