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.
Related
My question is:
How to captuare an incoming IP packet from a network interface, change its content and resend it from another network interface?
The choice is yours, there is no preference (and hence no "normal").
using libnetfilter_queue to deliver to userspace and do extensive modification there.
or an xtables module, also works (since it's called by NF anyway). Allows for sufficient fine-grained configuration with help from userspace.
nfhook module, if you must. All configuration you must implement yourself.
well and finally, if you like things that hurt, you might as well implement your own virtual NIC driver.
The usual way of doing something like this is to create a netfilter hook module.
See this example for a quick start.
You don't mention what you intend to change exactly, which makes it difficult to answer your question properly.
For content substitution on a router kind of device (guess), netsed might be the simplest approach available.
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 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 :)
I need to store persistent reference to third party device on an arbitrary IP network where the IP address of the devices may be static or randomly assigned by DHCP. I don't control the devices on the network and I can't rely on DNS and other ad-hoc networking protocols existing or working with the devices.
So I have been instructed to investigate using hardware addresses and ARP. This will work but I don't want to duplicate code. The kernel must manage an ARP table. On Windows you can access it using GetIpNetTable etc.
I am hoping there is an API to answer these two questions:
How do I translate from IP to MAC address? (ARP)
How do I translate from MAC to IP address? (InARP)
If not then I may have to do it more manually:
How do I read the kernel's ARP table?
How do I add an entry if I have the determined a mapping myself?
/proc/net/arp
K
ARP tables tend to be fairly local and short-lived. If you examine the protocol, the real MAC addresses are generally only provided when the given IP address is in the local subnet.
Otherwise, the packet is forwarded to the local router, which is then responsible for forwarding it.
If you do "arp -g" on Windows or "arp -a" on UNIX, you'll see the table, but I don't think it will do you any good, due to the reasons mentioned above. That command and
That's really what DNS is for but, as you say, it may not be an option for you.
You may well have to write your own 'ARP' database at your application level.
As for ARP:
You could use system("/usr/bin/arp -option_of_choice"); and parse the output, but that's an ugly hack. -- Not my recommendation.
Take a look at /usr/include/linux/sockios.h -- At the SIOCGARP, SIOCDARP, and SIOCSARP details. Those are ioctls that you can perform to manage the ARP table on linux. Of course, you'll have to perform these ioctls on a socket fd.
Here's some examples: SIOCGARP examples
I'm sure you can find many other examples in several other languages as well. As I'm assuming that you're using C.
As for RARP:
A quote from the linux rarp manpage:
" This program is obsolete. From version 2.3, the Linux kernel no longer
contains RARP support. For a replacement RARP daemon, see ftp://ftp.demen-
tia.org/pub/net-tools"
So you'll have to install rarpd on the target system.