I have a laptop that is connected to my organization's network using one or more network adapters. I am trying to write a tool that will continuously monitor the connectivity status and connection quality of each network. However my networking knowledge to limited and the terminology confuses me.
Specifically finding all the network adapters. Someone suggested that I use the command ifconfig and it gave me what are called "interface identifiers".
ex:
['lo0', 'gif0', 'stf0', 'en0', 'en1', 'en2', 'bridge0', 'p2p0']
I'm not quite sure how this helps me solve my problem because I don't know what interface identifiers are and I am not sure how to leverage this information. My assumption is that they represent a computer or a router in the network.
If someone could clear this up or explain it to me in layman's terms that would be really helpful.
First of all, you need to understand that there may be physical network cards(OR/AND logical network adapters) present in the computer to identify connection/manage connection.
Next, you have an incorrect notion about interface identifier.
What you talked about(eth,virbr,lo) are interfaces. In IPv4 addressing scheme, we don't have interface ID. We have interface ID's in IPv6 addresses.
As mentioned in The Payoff of IPv6’s Very Large Address Size
In IPv4, IP addresses have no relationship to the addresses used for underlying data link layer network technologies. A host that connects to a TCP/IP network using an Ethernet network interface card (NIC) has an Ethernet MAC address and an IP address, but the two numbers are distinct and unrelated in any way.
With the overhaul of addressing in IPv6, an opportunity presented itself to create a better way of mapping IP unicast addresses and physical network addresses. Implementing this superior mapping technique was one of the reasons why IPv6 addresses were made so large. With 128 total bits, even with a full 48 bits reserved for network prefix and 16 bits for site subnet, we are still left with 64 bits to use for the interface identifier, which is analogous to the host ID under IPv4.
Having so many bits at our disposal gives us great flexibility. Instead of using arbitrary “made-up” identifiers for hosts, we can base the interface ID on the underlying data link layer hardware address, as long as that address is no greater than 64 bits in length. Since virtually all devices use layer two addresses of 64 bits or fewer, there is no problem in using those addresses for the interface identifier in IP addresses. This provides an immediate benefit: it makes networks easier to administer, since we don't have to record two arbitrary numbers for each host. The IP address can be derived from the MAC address and the network identifier. It also means we can in the future tell the IP address from the MAC address and vice-versa.
Visit this link for more clear understanding about interface ID.
Now,returning to clear your confusion,
all of the connections(interfaces) such as Ethernet-0,Ethernet-1,WiFi-1,etc. have their own interface identifier.You can think of them as a kind of special identification number which identifies the kind of interfaces available at that moment!
When you type ifconfig in Linux, it displays the status of the currently active interfaces.
Now,coming on the example part, let's say you have two Ethernet connections on your system, say, eth0 and eth1(these are interface names) ---so ifconfig will print these two as a result of it's output!
So,to identify these two separate interfaces,there must be an
interface identifier.The interface identifier(generally 64-bit) is
either automatically generated from the interface's MAC address using
the modified EUI-64 format, obtained from a DHCPv6 server,
automatically established randomly, or assigned manually.
Also,the interfaces which you have mentioned are some of the most-commonly used interfaces :-
'lo0', 'gif0', 'stf0', 'en0', 'en1', 'en2', 'bridge0', 'p2p0'
lo0---local network connection(0 for 1st connection of lan)
en0---ethernet connection(0,1,2 for 1st,2nd and 3rd connection on Ethernet)
bridge0---a bridged connection to this machine
p2p0---a peer-to-peer connection
don't know about gif,stf.Please note that there are logical connections/virtual connections,instead of limitation of physical connections(using NIC cards) too!
I discovered that there are man entries for gif and stf -- on OSX, at least. These are generic tunnel interface, and IPv6 to IPv4 tunnel interface ("Six To Four"), respectively.
Related
Background:
I'm trying to communicate with an IP camera without the need of a DHCP server. This is how the camera acquires an IP address:
Basic DHCP procedure (discover etc.)
If above should fail the camera has a fallback address of 192.168.0.90
The camera then starts the avahi-daemon and successfully gets a link-local address too for robustness
The IP aliasing is now done and the interface has two IPs.
Problem:
Now the problem is that when I avahi-browse to browse the services on the network, the camera replies with both IP addresses (checked with Wireshark).
Only one is shown by avahi and it could be the zeroconf:ed address or the fallback address.
I want the link local address only, not the fallback. Any reliable way to get it?
Old question but just in case someone else has the same problem:
Avahi will only return one of the IP addresses reported by the device. This seems to be a (debatable) design decision and is explained in this post of the avahi mailing list. So I'm afraid there's no reliable way to get only the link-local address, if you are using avahi-browse.
On a side note, RFC3927 section 1.9 specifically recommends NOT to configure both a routable address and a link-local address simultaneously for the same interface. But I do understand this is the camera's behaviour and probably outside your control.
Is there a way to double the number of ephemeral ports and work around the 16-bit limit? I have tried creating virtual ethernet interfaces over eth0, and hope that would lift the limit. Although the application is utilizing the new virtual IPs in outbound traffic, it seems still hitting the same ephemeral-port limit. I suppose the virtual ports have 1-to-1 mapping to the ports on the physical interface.
ifconfig eth0:1 10.10.10.210 netmask 255.255.255.192
ifconfig eht0:2 10.10.10.211 netmask 255.255.255.192
Could someone please advise how I could double the total number of ephemeral ports in Linux, without adding an extra NIC?
(FYI, I have tried increasing ulimit/max open file, changing the port range, enabling tcp recycle/timestamps, reducing tcp fin timeout... I suppose we simply need more than 65k ports for this proxy machine.)
If you create virtual interfaces over eth0, then you should be able to assign different IP addresses to those interfaces. With that, you can use the same ephemeral port numbers (they are allocated in the kernel, so you dont really have much control) for multiple sockets each bound to different addresses -- you will probably need to set SO_REUSEADDR option. The reason this will work is because for incoming packets (UDP/TCP), the flow is identified by looking at both local source IP and the port number.
And as #Duck mentioned, since TCP/UDP headers allocate only 16 bits for port numbers, there is not much point in increasing the ephemeral range in the local stack.
It's a limitation of the network protocols. Both TCP & UDP, for instance, have 16 bit source and destination ports. Even if you could increase the number of ports no one could address them.
It seems there's a way, but it's not for free. It's called "bind before connect". See this short but dense article, which sums it up very nicely.
Having multiple virtual IPs is just a start. Quoting the linked article:
On Linux the ephemeral port range is a global resource, it's not a specific setting local to an IP address.
So that's bad and you have to improve your starting position with few right settings (where most of them you already found) and get around the global limit with a clever socket allocation technique. The result is that you'll control all the outgoing IPs manually. This also seems not to cope well with other apps on the system using the traditional "connect" way.
It turns out that you cannot use 0 for binding ephemeral port if you want to exceed the 65535 limit. Instead, you need to use an explicit port number.
And also turning on tcp_tw_reuse might be helpful: http://krenel.org/tcp-time_wait-and-ephemeral-ports-bad-friends.html
Greetings,
For various reasons, my connection to the internet looks like this:
[DSL Modem in Bridge Mode] <-ethernet-> (eth0)[Linux system](eth1) <-ethernet-> [Wireless Router]
(Where the Linux system is running PPPoE, BIND, DHCP, etc.)
In order to diagnose a recent problem, I needed to connect to the web interface on the DSL modem. In order to do this I have to connect from a specific address range and as I am running PPPoE on eth0, I haven't assigned an address to it nor even turn it on. (The modem's web interface is at a fixed IP address regardless of what mode the modem is in and only answers to traffic from a fixed address range)
So anyway, to connect to the modem, and not finding anything helpful on the internet, I just tried assigning an IP address to eth0 after already starting PPPoE (like this: ifconfig eth0 192.168.1.5 netmask 255.255.255.0 up). I didn't really think that it would actually work. But it did. I.e. PPPoE and a static address assigned to eth0 at the same time and both worked correctly. Thus my question.. Should it? Is it safe to do this long-term or am I just lucky that it works long enough for me to get that which I need to done?
Thanks!
It's fine. PPPoE and IP are carried in Ethernet frames of different types.
The router will replace the source MAC address of the package it received with the address of the previous hop and the destination MAC address with the address of next hop.
The linux provides a functionality to worked as a router. My question is how the kernel code implement the function for mac address update during its package forwarding process? And where is this part of code
I try to find the codes in /net/ipv4, but can not found anything...
That is not what actually happens.
IP is not dependent on ethernet, so what happens is dependent upon the underlying protocol of the lower layer.
The same thing happens if it is a locally-originated IP packet, or if it is one which has been routed for another host.
Linux's IPv4 stack is not ethernet-dependent in any way, in fact lots of other link-layer protocols are supported by the kernel. IP being a WAN protocol, you can route between different underlying protocols. Some examples are
ppp, slip (serial lines)
PPTP, GRE (for tunnels, mostly VPNs)
IP over ATM
Token ring (mostly legacy, I think)
Loopback and dummy (for local communication only)
Wifi (although this is actually mostly identical to ethernet)
So what actually happens when routing IP frames from one ethernet interface to another is that the link-layer is stripped off completely, then a new link-layer is formed after routing. If the protocol were not ethernet, an appropriate link-layer packet for that protocol would be used instead.
So nobody "changes the MAC address", but rather, the link-layer packet is just completely rebuilt.
I'm working with a cluster of about 40 nodes running Debian 4. Each node runs a daemon which sits and listens on a multicast IP.
I wrote some client software to send out a multicast over the LAN with a client computer on the same switch as the cluster, so that each node in the cluster would receive the packet and respond.
It works great, except when I run the client software on a computer that has both LAN and WAN interfaces. If there is a WAN interface, the multicast doesn't work. So obviously, I figure the multicast is incorrectly going over the WAN interface (eth0), rather than the LAN (eth1.) So, I use the SO_BINDTODEVICE socket option to force the multicast socket to use eth1, and all is well.
But I thought that the kernel's routing table should determine that the LAN (eth1) is obviously a lower cost destination for the multicast. Is there some reason I have to explicitly force the socket to use eth1? And, is there some way (perhaps an ioctl call) that I can have the application automatically determine if a particular interface is a LAN or WAN?
If you don't explicitly bind to an
interface, I believe Linux uses the
interface for the default unicast
route for multicast sending.
Linux needs a multicast route, if none exists you will get a EHOSTUNREACH or ENETUNREACH error. The LCM project documents this possible problem. The routing will be overridden if you use the socket option IP_MULTICAST_IF or IPV6_MULTICAST_IF. You are supposed be able to specify the interface via scope-id field in IPv6 addresses but not all platforms properly support it. As dameiss points out, Stevens' Unix Network Programming book covers these details, you can browse most of the chapter on multicast via Google Books for free.
If you don't explicitly bind to an interface, I believe Linux uses the interface for the default unicast route for multicast sending. So my guess is that your default route is via the WAN interface.
Richard Stevens' "Unix Network Programming, Vol. 1", chapter 17 (at least in the 3rd edition), has some good information and examples of how to enumerate the network interfaces.