Is there a possibility that I can hardcode interface name(say eth1) to a specific interface in the linux driver code?
This is in a controlled environemnt only, so breaking from default linux way(dynamically assigning name) is ok.
You may not need to do that; you could instead just fiddle with the dynamic assignment mechanism. udev has configuration files that control how names are assigned to devices, and if I remember it will also allow you to create links with handy names for given device names... so you can probably achieve your effect by re-configuring rather than re-coding.
Check out the man page and docs for udev.
You can rename network devices which are not up using the "ifconfig" command or the ioctl it uses. I strongly recommend that you don't :)
Related
We are a hardware vendor and want to provide support for linux.
This means we want to provide a (user space) shared library that can be used by our customers applications without struggling with the lowlevel protocol.
Our Hardware is accessed via USB/HID and thus our library need to get access to /dev/hidrawX.
But to get access to this device (or other kind of hardware devices) it seems that we need to modify the system by adding permissions to the udev system (see
Get access to USB device on Linux (libusb-1.0)?).
Is this really best practice? If so, where should I do this? In the .deb/.rpm/... installer of the customers application? What about FlatPak or similar concepts?
Udev is standard and best practice. Every linux distribution has udev rules files typically for ex in case of ubuntu it is found in /etc/udev/rules.d folder. You need to create a udev rule file and write MODE="0666" rule to it. Take a look at this example for how to write udev rule.
I have a task to make a virtual device under a real one with the help of device mapper kernel module. Virtual device must transfer any request to a real device, so both devices must be equal.
In prospective I should be able to control requests, so I wrote kernel module, representing device mapper target, using this article.
After making module and inserting it (insmod command) I setup my device (dmsetup create). Then do mount and can work with a real device through just created virtual.
But the question is how to repeat above mentioned instructions in boot time? I'd like to use my virtual device as a general one (by changing fstab, I guess).
Thanks in advance!
If you are going to use your device as the root filesystem, you need to create an initramfs that sets it up. Basically a shell script that issues dmsetup commands, followed by a mount and finally pivot_root to the new filesystem.
There was a discussion on the dm-devel mailing list last year on how to do this in the Linux kernel without an initramfs, by specifying mapper lines on the kernel command line. This is they way Chrome OS does it, because they can't/won't use an initramfs. See here for documentation of this feature. The functionality was never merged though.
The patch series was updated and resubmitted in May 2017. Hopefully we will eventually see it merged in some form or other.
If you are not going to use your device as the root filesystem, you can still use the same approach if you want, but there might be easier ways.
I have tried using several commands as well as couple of examples using C/C++ but am still not able to find a flawless method that can differentiate between physical or virtual ethernet adapters. Physical means, on that available on your board or installed externally and virtual means created by virtualization apps such as VirtualBox/VMWare/Virtual PC or VPN etc.
Any pointers?
There is no flawless method. A virtual adapter can have any MAC address, including one that might have been assigned by a constructor to a physical device. And the other way around, given that one can change the MAC address of a physical adapter. You can only make an educated guess.
You might find it easier to detect if you are running virtualized at all, rather than look for specific information about the NICs. The virt-what(1) tool looks through aspects of the running system to guess if the system is virtualized or not. (The script isn't as smart as you think, but it does have a lot of small information gathering tools in one place.)
Someone intentionally trying to bypass a license check would probably not find it difficult to defeat this mechanism.
Maybe one can use mii-tool and check if it fails, which it does for virtual:
mii-tool vmbr2
SIOCGMIIPHY on 'vmbr2' failed: Operation not supported
mii-tool eno1
eno1: negotiated 1000baseT-FD flow-control, link ok
EDIT:
What is mii-tool: view, manipulate media-independent interface status
This utility checks or sets the status of a network interface's
Media Independent Interface (MII) unit. Most fast ethernet
adapters use an MII to autonegotiate link speed and duplex
setting.
https://www.man7.org/linux/man-pages/man8/mii-tool.8.html
I want to determine if a network card is enabled, up, and plugged in. Basically, I want to know if the network card will work. I need this information from with a C++ program, and would like to display an error message when the network isn't working properly. If possible I would like to avoid using shell commands to determine this information.
You can look at /sys/class/net/eth0/operstate where eth0 is your interface to see if it's up.
Look at /sys/class/net/eth0/carrier to see if there is a carrier.
Though I guess executing ifconfig and friends will give you more compatibility to *BSDs.
open AF_NETLINK socket
bind it to sockaddr_nl with nl_groups = RTMGRP_LINK
send message RTM_GETLINK to kernel
make poll/epoll on socket to read RTM_NEWLINK and RTM_DELLINK messages
you will receive initial interfaces list and its changes in future
Remember, on Linux "everything" is a file.
The best way would be to use the approved kernel<->userspace communication, namely sysfs, mounted at /sys. Network devices are linked at /sys/class/net
If you wish to use the ioctl interface, look at man netdevice
How do you want to identify the network card? You might try taking a look at /etc/udev/rules.d/70-persistent-net.rules which maps hardware MAC addresses into nice names (like eth0).
Then, when you have the nicer name, you can run things like ethtool eth0 to determine if it is [physically] connected (last line), ifconfig eth0 to determine if it is up (look for "UP BROADCAST..."), and if it has an IP address.
I'm willing to guess there are automatic libraries for this though; have you looked around? I'm not sure if there's easily accessible code in NetworkManager, but that should be a good first place to look.
Run through the output of getifaddrs, you can use the link layer for the MAC address to identify an adapter and check the ifa_flags for IFF_UP. Use AF_NETLINK for notifications about interface changes.
Is it safe to assume that the loopback network adapter on a Linux system will always be called 'lo' - is this just a naming convention that may not be adhered to, or must it always be the case?
I don't know of any Linux system that has a loopback interface anything other than lo. I would rely on this naming convention, if I write a system-specific script, but not when writing a portable program. For example loopback in OSX is lo0.
A reliable way in C is calling a SIOCGIFCONF ioctl on a socket, iterating over the interfaces, calling SIOCGIFFLAGS ioctl on each one, and checking which interfaces have a IFF_LOOPBACK flag set (see /usr/include/linux/if.h).
SIOCGIFCONF will also give you interface names.
In my experience it is a common name, although you shouldn't always trust in it being so. Maybe enumerating the interfaces and looking for the one with an address of 127.0.0.1 would be the way to go?
It's a pretty old convention, in fact I have not seen a Linux box/distro yet that didn't call it 'lo'.
However, device names in *nix systems are so diverse it can be assumed they will change. Use the standards if you want portability (in this case, 127.0.0.1).
Interfaces can be renamed to anything you want - but anyone who renames the loopback interface is being extremely silly and deserves to have a nonworking system :)
Yes, you can enumerate the interfaces, and get their names. But perhaps it's just as easy to just assume it's going to be "lo".
Using 127.0.0.1 is probably the failsafe way to go about it.
RFC3330 defines 127.0.0.0/8 to always be the loopback subnet.
The use of localhost however, defined on Windows in c:\windows\system32\drivers\etc\hosts and Linux in /etc/hosts is purely convention. Furthermore the name lo is the typical name given to the localhost interface in Linux.
If you must be absolutely certain, use 127.0.0.1.