Whats the command to find Nic cards serial numbers in linux ? I tried dmidecode options and lshow
may be I missed some thing
I'm not sure about serial numbers, but lspci gives me the following information about my ethernet card:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
If you haven't mucked with your MAC address since bootup, it will be globally unique. See http://www.coffer.com/mac_info/locate-unix.html
NICs aren't required to have any other serial number than that, and if they do it might not be electronically readable.
Use "ifconfig" to get each ports globally unique MAC Addresses
ifconfig -a
For all adapters
Related
I'm trying to create a usb based ethernet device on my computer, basically I want to tell my computer (linux based) that one of its usb ports is actually an ethernet port. I have done extensive research and while it's supposed to be possible, I can't find any examples of code / commands to run.
According to wikipedia:
The USB-eth module in Linux makes the computer running it a variation of an Ethernet device that uses USB as the physical medium. It creates a Linux network interface, which can be assigned an IP address and otherwise treated the same as a true Ethernet interface. Any applications that work over real Ethernet interfaces will work over a USB-eth interface without modification, because they can't tell that they aren't using real Ethernet hardware.
So in theory, this should be possible, I just need some help or a gentle nudge in the right direction to get this thing rolling. What I'm NOT trying to do is plug a usb to ethernet dongle/adapter into my computer, I have several of those lying around and that doesn't help me out at all.
this is ethernet-over-usb
https://en.wikipedia.org/wiki/Ethernet_over_USB
without external hardware you can try the CDCether kernel module and ethtool ( then you can only connect to a usb device that operates in usb device mode )
( https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_device_networking , http://tldp.org/HOWTO/Motorola-Surfboard-Modem/usb.html, http://www.linux-usb.org/usbnet/ )
else you need a physical adapter for this. the adapter translates between the protocols and the different hardware interfaces.
in usb protocol can only be one host in a network, therefore you need at least a host-to-host cable ( http://www.linux-usb.org/usbnet/ ) if you want to connect two usb host devices, i.e. two pcs
required kernel module ( driver ) when using a physical adapter is either usbnet ( with its minidrivers ) or usb-eth
Good day every body
I use MC7455 module in linux machine connected using PCI
but when i do : lspci , i didnt find it
and also with dmesg , it is not detected
Is this problem related to drivers missing ?
(For those wondering: This question is asking about the Sierra Wireless MC7455 LTE modem module)
Your modem card is a mini-PCI-e card, but that modem does not connect to the PCI bus. The mini-pci-e slot also connects to the USB bus. This modem card connects only to the USB bus, so it will not show up with lspci.
Instead is should show up as a USB device.
I have lots of experience with MC7304, assuming MC7455 works similar.
MC7455 has a miniPCIe interface, I assume your motherboard has such interface because you said the modem is connected. Have you installed SierraWireless driver? If not, Linux doesn't detect the modem. At least that's my case.
If you don't have a miniPCIe interface on the motherboard, you can use a miniPCIe to USB adaptor.
Once the modem is detected, for MC7304 at least, I can find modem in dmesg as well as by lspci.
Check this link: https://techship.com/faq/38/
I had exactly same issue with my Qotom Q355G4, the device was not detected at all. It was fixed by putting adhesive tape over pins #23, 25, 31, 33.
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.
I have a Linux virtual machine running on VMWare Fusion (on Mac OS X) that I intend to use as a development environment for an embedded system. Would it be possible for my Linux VM to talk to my embedded system's serial port using a USB-to-serial adapter? Any recommendations for what sort of adapter I should get?
There are two ways to do it:
Your host-OS supports your USB<->serial converter (very likely). If so you can just allow your VM to talk to the serial port. If so the VM will see a standard serial port and everything will be fine.
Your guest-os in the VM supports the USB<->serial converter, AND your host-OS allows raw USB forwarding.
All in all the chances are good that it works..
Btw: there are good and bad USB<->Serial converters. If you find out that the serial connection seems to work (everything detects/works as expected for a couple of seconds), but you can't get a reliable connection for a longer time, then it's very possible that the usb<->serial dongle sucks....
You get what you pay for... When buying these things I'd check comp.arch.embedded and ask which usb dongles are known to just work, and which not. (My recommendation is to stick with products from Assmann. You can order them at digikey).
I've found USB serial adaptors to be a bit hit & miss with embedded work. One thing to be aware of is that the buffering tends to work differently from "real" serial ports, and latency of characters through the system can be quite variable. Some embedded development systems (think bootloaders, cheap JTAG probes etc) can be quite sensitive to this and will give timeouts and so on.
Note this doesn't only apply to USB serial adaptors, I've had similar problems with high end multi-port serial cards, but usually with those you can tweak the FIFO / IRQ settings to get something working.
I have experienced that a USB to serial adapter with a FTDI chipset and drivers is more reliable and compatible with more devices than the Prolific chipset
Depends upon the VM software, but VMWare Fusion does support USB devices. The question becomes, does your IDE support talking to a USB device instead of an old-fashioned serial port? With Linux, probably yes.
I had no problems whit serial adapters from ATEN.
USB serial adapter is USB standard device (just like mass storage) that mean that any USB compliant adapter should work.
pl2303: I have found this device to be very reliable and are often in the generic and cheap USB to RS232 adapters. I've seen expensive adapters fail and my generic adapter from geeks.com work great.
I just picked up a USB 1.1 - RS232 adapter (Digitus DA-70119) from WeirdStuff for 10 bucks. I plugged it into my Mac mini and VMWare Fusion showed me this.
Once I clicked on the USB icon, my Ubuntu 9.10 VM had no trouble seeing it
$ lsusb
Bus 002 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
$ dmesg
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
pl2303 2-1:1.0: pl2303 converter detected
usb 2-1: pl2303 converter now attached to ttyUSB0
I can now use /dev/ttyUSB0 in my Linux VM to talk to my target system.
Is there a simple way to detect nic and associated ports on systems loaded with linux.
From my study on this, i found lshw -C network would help me to some extent, by giving details on ports and interfaces.
But i didn't get clear differentiation done with nic and associated ports.
Say if i have 2 nic cards with one 4 ports and other nic with 2 ports, how to i detect this information using lshw or any way!!.
lshw -C network ( only portion of the information pasted here)
Using lshw -C network, we can use the serial number for example:
*-network:0
description: Ethernet interface
product: 82575EB Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci#0000:01:00.0
logical name: eth0
version: 02
serial: 00:14:4f:e7:40:e0
*-network:1
description: Ethernet interface
product: 82575EB Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci#0000:01:00.1
logical name: eth1
version: 02
serial: 00:14:4f:e7:40:e1
*-network:0 DISABLED
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller (Copper)
vendor: Intel Corporation
physical id: 0
bus info: pci#0000:2b:00.0
logical name: eth6
version: 06
serial: 00:15:17:be:e6:75
*-network:1 DISABLED
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller (Copper)
vendor: Intel Corporation
physical id: 0.1
bus info: pci#0000:2b:00.1
logical name: eth4
version: 06
serial: 00:15:17:be:e6:74
serial number kind of helps, the first five tuples help me to distinguish the nics and the last tuple in the serial number seems to be in sequence when in comes to different ports on given nic.
-Thanks
Harish
I'm not entirely sure what information you want to know. I'm guessing you want to know which ethernet interfaces are on the same board. One quick way to detect is via the sysfs directory which contains information about devices and drivers. This information can also be correlated to lspci.
Example:
find /sys/devices/ -type d | grep eth
Which outputs data on my system in the format of:
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0
Where pci0000:00 is the bus, and the last number is the card (0000:02:00.0).
Then if I run lspci I can look up the card identifier to get more information
lspci | grep 02:00
Nets me:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
On your system, you should have multiple eth* mapped to each card. This should tell you the mapping of which eth to which card and more information about each specific card.