I have the following problem. My PC is very old and it has a built in ethernet port that doesn't work, not due to a misconfiguration, I think it's physically damaged. It didn't work in either Ubuntu or even on Windows. I have an ethernet PCI card which is the one I use. The problem is, for some odd reason, the card that does works sometimes changes from eth0 to eth1 and I have to run dhcpd as I don't always get an IP via DHCP. Now, the actual question is, is there some way to disable the card that doesn't work using its MAC address or something? I can't disable either eth0 or eth1 as I'm sure it's not always "pointing" to the same card.
Are they the same kind of chipset or different ones?
If they are differnt then probably the simplest solution would be to just blacklist the modules for that Ethernet chipset.
You will first need to find the module name (this is for eth0):
dmesg | grep eth0
See if you have something like the following:
[ 2.209295] r8169 0000:05:00.0: eth0: RTL8168d/8111d at 0xffffc90000c6e000, 00:24:1d:11:b6:64, XID 081000c0 IRQ 44
In my case 'r8169' is the module name. You can also see a list of currently loaded modules with 'lsmod' so check that it appears in there.
Next you need to black list the module. There is an entry on the Arch wiki for that.
Fellow archer here; I have a method I use to disable my nVidia graphic card's HDMI port audio chip based on its hardware pci id; perhaps you could apply the same approach to your nic:
Find the ethernet's pci id:
$ lspci | grep Eth
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
Find the corresponding directory:
$ find /sys/devices -name *00:19.0
/sys/devices/pci0000:00/0000:00:19.0
There should be a file named "remove" in that directory.
You can disable the device at startup by editing /etc/rc.local
echo 1 > /sys/devices/pci0000:00/0000:00:19.0/remove
On second thought; this may not work in your case if modules get loaded prior to /etc/rc.local finishing... it would do you little good to have /dev/eth0 and /dev/eth1 assigned in the "wrong" order and then have /etc/rc.conf disable one of them... you could still end up with your prefered nic as eth1. This used to be a problem with alsa on multiple sound cards so methods were devised to assign the numbering of the cards via module parameters. Perhaps the module itself allows this?
I'm gathering from your description this in an onboard NIC. The best solution would be to disable it in the motherboard BIOS rather than the OS. The method for this varies by manufacturer but I'm sure you could find a manual for your model online somewhere.
I'm confused it didn't show up: In case you don't need the low level solution proposed by cjpembo, you can just use
ip link set dev <interface name> down
You get them via ip link show.
Related
My question is about Lichee Pi Zero board (based on Allwinner/Sunxi V3s SoC).
Initially I used pre-built Linux image (kernel 4.10.02), it has no built-in Wi-Fi support (for Realtek 8327BS chip), so I downloaded the latest kernel version from here and built it with the default settings.
LCD is ok, Wi-fi looks good too (LED is blinkikng), but I cannot use keyboard anymore - there is no reaction from OS, when I connect something to USB (no message and no input from keyboard).
Hardware is OK and works good with the old Linux image.
I have also tried the latest kernel from kernel.org with the same bad result.
Please help to understand the reason. I suppose bad settings, but HID supoort is enabled.
Update 1.
I establish connection through UART. As I see, some USB features are detected during boot:
I'm able to load some drivers using insmod also:
Unfortunately, Linux still does not recognize any USB Device. I have connected mouse, keyboard, hub, mass storage and got no reaction from OS. It looks like devices do not get power (there is no light from mouse).
Update 2.
The best way I have found at the moment is to use buildroot-licheepi-zero.
It's very easy to use:
make licheepi_zero_defconfig
make menuconfig (optional)
make
After many-hour wainting I got the sdcard.img. It includes all neccessary files (zImage, RootFS, u-boot.bin, etc) and could be placed to SD with linux dd or etcher.
Linux boots successfully, but you can use terminal only through UART, as there is no LCD output.
You can put LCD itself to work:
make uboot-menuconfig
make
BUT there is still no user login prompt on the LCD after boot. So I need to log in and put command through UART.
Please share suggestion if any.
Update 3.
The change below enables login prompt on LCD (and disables it through UART):
make menuconfig
Now we are able to use Wi-Fi:
insmod /lib/modules/4.14.14-licheepi-zero/kernel/drivers/staging/rtl8723bs/r8723bs.ko
ifconfig wlan0 up
edit file /etc/wpa_supplicant.conf to add your Wi-Fi SSID and PSK
wpa_supplicant -B -d -i wlan0 -c /etc/wpa_supplicant.conf
udhcpc -i wlan0
Connection is established now, we can ping and so on.
There is still the question - how to enable full-functional terminal both on LCD and UART.
Many thanks!
With regards,
Maksim
The best solution is to use Buildroot.
Please check updates at topic start for details.
I want to change Vendor_ID and Device_ID from a PCI device.
However, every change I make will not save and I have no clue why.
First I tried making changes using setpci which results in this:
# sudo setpci -s 01:00.0 00.w
# 8086
# sudo setpci -s 01:00.0 00.w=168C
# sudo setpci -s 01:00.0 00.w
# 8086
Then I tried making the same changes using two different hex editors, editing the config file located in /sys/bus/pci/devices/0000:01:00.0/, but after saving, the file seems unchanged.
I did open it as root and I don't get any errors when saving.
I also tried ethtool, but it cannot even access the registers:
# sudo ethtool -e wlan0
# Cannot get EEPROM data: Operation not supported
I tried everything of the above on both Lubuntu 15.10 and Knoppix 7.6, resulting in the exact same behaviour.
So, why does this happen?
If the registers are protected, is there a way to unprotect them?
Some more information:
The mentioned pci device is a Intel 7260-AC Wireless Network Adapter
I want the BIOS to recognize it as a Qualcomm Atheros AR9485 Wireless Network Adapter, because it's whitelist blocks everything else.
Modifying the BIOS is not an option.
I'm running Lubuntu and Knoppix from a USB drive
PCI Configuration registers typically have attributes such as read only (RO), read write (RW), or other less common ones.
The problem is that you are trying to write a value to a read only register. I have not seen the documentation for this particular device, but I have worked with other Intel PCI devices and I have never seen a RW (read/write) device ID or vendor ID register. For example, look at this link on page 96, the VID and DID registers are RO (read only).
Unfortunately, there is no way to change the read only attribute of the register, as this is almost certainly enforced at the hardware level.
Assuming you could change the device ID or vendor ID registers, I imagine this would not necessarily mean a working network adapter, as the BIOS and OS use these values for ACPI and device drivers. There may be a way to fake the device ID and vendor ID in the BIOS, but as you say that is not an option and I don't think it would work anyway.
Depending on how/why your BIOS is whitelisting Qualcomm wireless adapters versus Intel wireless adapters might provide some workaround for this problem. I say the best solution would be to alter the BIOS whitelist somehow, perhaps through an update.
In case it helps, I have code that can modify PCI configuration registers of any device (although this will not circumvent hardware level restrictions such as RO, RW, ...). I don't think this will fix your problem but at the very least you can learn more about PCI configuration registers from it.
I have a server running Debian 7. The eth0 interface is configured to use the on-board ethernet card. This is basically used to connect to the internet. As it happens, I had to connect this server to some PCs through a switch, obviously on a different series of IPs. for this, I installed an external NIC in the PCI slot but, strangely it didn't seen to work. The configurations were alright. I checked them more times than I can imagine. So, I disabled my eth0 interface and connected eth1 (external NIC) to the internet. If for the same settings, the on-board card worked, so should the external one. But, it didn't. When I tried to ping some servers like 8.8.8.8, it gives me Destination Host Unreachable and on termination shows, 0 packets "transmitted" and 0 packets received, which is baffling, to say the least. The PCI slot is working because I checked if the drivers were being recognised or not. The NIC itself is working (checked with another machine running Debian 6). Any help/sugesstions would be appreciated.
P.S The NIC in question is D-Link System DGE-530T Gigabit Ethernet Adapter (rev 11)
You need to check to see if the card is being listed in lspci or not. Second, is this a virtual machine?
I would also check to see if the BIOS is handling IRQ's in auto or are they specifically assigned.
I'm running Ubuntu 11.10 on a BeagleBone with an Edimax EW-7711UAn wifi adapter plugged into the USB port. I've configured /etc/network/interfaces and the wifi works, BUT:
The wlan0 interface doesn't always come up when booting the device. It comes up successfully about one in three attempts.
The interface sometimes goes down again, especially when not used for a while.
The /etc/network/interfaces file includes:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid "Bodoni"
wpa-psk "<mypassword>"
In order to try to address point 1), I put the following in /etc/rc.local:
nohup sh -c "ifdown wlan0 && ifup wlan0"
But it hasn't seemed to help much. I'm guessing that the second problem might be connected with power management, so I might try turning that off in /etc/rc.local.
But does anyone have any thoughts on how I might get the wifi to come up reliably on boot? I'm running the BeagleBone headless with no Ethernet (it's on a robot) so it's important I get this fixed!
FYI, I'm using the default drivers - lsmod gives:
Module Size Used by
aes_generic 27837 2
arc4 1111 2
rt2800usb 12386 0
rt2800lib 45146 1 rt2800usb
crc_ccitt 1457 1 rt2800lib
rt2x00usb 10595 1 rt2800usb
rt2x00lib 39077 3 rt2800usb,rt2800lib,rt2x00usb
mac80211 228509 3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211 167722 2 rt2x00lib,mac80211
rfkill 16703 1 cfg80211
binfmt_misc 6224 1
spidev 4620 0
I'm hoping not to have to compile a new driver because I haven't had much success with that!
I've had a similar problem with my BeagleBones using another wifi adapter using the rt2800usb driver. Specifically I am using a DLINK DWA-125 (HW Rev A2) which is based on the rt3070 chip.
Same exact symptoms that you are reporting if I plug the DWA-125 directly into the USB port on the BeagleBone.
BUT if I plug the adapter into a USB extension cable and then plug the extension cable into the BeagleBone USB port, everything works fine. I have done 100s of hours of Cloud9 development using this setup and no problems with Wifi whatsoever.
I am running the Angstrom distro - and I find the same issue on all three of last BB releases (4/22. 5/? and 6/18).
Length of USB extension cable doesn't seem to matter (at least between 1ft and 12ft - haven't tried anything below 1ft.)
I have 6 BeagleBones (4 ver A5 and 2 ver A6) - behavior is the same on all of these Beaglebones.
Also have 4 DWA-125 Rev A2 USB adapters - behavior is the same on all of these.
I have not experimented with other USB Wifi Adapters using the same or other chips/drivers. And I haven't spent the time to track down the root cause of this behavior - I have code to write!
But, give it a try in case your experience matches mine - its a quick and easy 'fix'.
---- Addendum:
I just tried an experiment with the Belkin N150 Micro USB Wifi Adapter - based on the rtl8192cu chip and the standard drivers that come with the 6/18 BeagleBone Angstrom distribution.
Got very similar behavior: The Wifi doesn't work at all when plugged directly into the USB port. But when plugged in via a 1ft USB extension cable, everything works fine.
I had the same problem. The best explanation i've found so far is this one from Adafruit
The main idea is that the Wifi dongle is destructed by the HDMI adapter, that is situated just under the USB slot. You have two workarounds in this case:
Put the Wifi-dongle as far as possible from the USB-slot by means of a cable
Disable the HDMI interface if you don't really need it!
Only the second option helped me.
Here are the steps:
> mkdir /mnt/boot
> mount /dev/mmcblk0p1 /mnt/boot
> nano /mnt/boot/uEnv.txt
Remove the # in front of the cape_disable command
##Disable HDMI
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
I hope it will help you guys!
I've fixed the problem by removing the USB ESD spike protection IC (U10, TPD4S012). It should be wired between the USB connector and the CPU but it was placed after the USB connector on my board (rev. A4). I don't know if this is fixed on later revisions.
Update: this won't help much in some cases. Check this thread.
I had a similar problem for most of a year until I googled long enough to find
wicd
After setting things up with wicd my 5 beaglebones have been rock solid on my home network on wifi dongles from the back bedroom to the garage. /etc/network/interfaces is not the way to go. I must have tried hundreds of configurations and some seemed to last for a day or two. I do remember the doc gave a good default for interfaces, very barebones. And wicd runs your supplicant if ever needed.
It took me ages to get reliable WiFi on the BeagleBone. In the end, the answer was to use an Atheros dongle, since I had poor luck with RealTek and RALink chipsets. The NetGear WNA1100 works very reliably for me, in both Angstrom and Ubuntu. See my post here.
I have two legacy machines connected to a Linux box with USB using the ftdi_sio driver, to /dev/ttyUSB0 and /dev/ttyUSB1. The Linux box is relaying and analyzing the traffic between the machines. When the Linux box boots up, the machines are connected to the files pretty much randomly. The problem is to know which one is which.
I could just ask the devices, of course, but I'd like to avoid the risk of malfunction due to sending wrong data to the wrong device. Is there a way to figure out, for example, the id of the device connected to a tty file?
Check this Using Linux USB page.
/proc/bus/usb/devices lists information about the devices currently attached to the USB bus. This is very useful when trying to figure out if the device is correctly enumerated.
Maybe you can use the output from lsusb -v and look at iProduct + iSerial to determine the order the devices are attached.