Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Error from multiple adapters with same IP address
05-11-2017, 10:06 PM
Post: #1
Error from multiple adapters with same IP address
The ohNet device stack returns a fatal error when there are mutiple adapters with the same IP address and different subnet masks.

This problem has been reported by some MinimServer users running on unRAID but I am able to reproduce it on any Linux system. This configuration works:

Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
     inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether f0:ad:4e:00:a6:f4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::f2ad:4eff:fe00:a6f4/64 scope link
       valid_lft forever preferred_lft forever

and this configuration doesn't work:

Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 127.0.0.1/32 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether f0:ad:4e:00:a6:f4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::f2ad:4eff:fe00:a6f4/64 scope link
       valid_lft forever preferred_lft forever

The failing configuration has an additional loopback adapter 127.0.0.1/32. Because this has a different subnet mask, the code in OsNetworkListAdapters in Os.c adds it to the adapter list and this causes an "address already in use" error when the device stack tries to bind a second server socket listener to the loopback adapter address. (MinimServer is calling initParams.setDvServerPort to fix the port number for server sockets.)

I can't think of any good reason for the same IP address to be configured with different subnet masks but I don't think ohNet should fail if this happens. I have created a patch for this and I have verified that it fixes the problem. The patch adds some code to OsNetworkListAdapters in Os.c to check for this situation and only adds the adapter with the least specific subnet mask as this is the effective result of such a configuration. The patch is attached and I have tested it using 1.17.2735.


Attached File(s)
.zip  multisubnet.zip (Size: 1.08 KB / Downloads: 2)
Find all posts by this user
Quote this message in a reply
15-11-2017, 02:18 PM
Post: #2
RE: Error from multiple adapters with same IP address
Thanks for the patch. I've applied it now.
Find all posts by this user
Quote this message in a reply
15-11-2017, 05:49 PM
Post: #3
RE: Error from multiple adapters with same IP address
Thanks very much!
Find all posts by this user
Quote this message in a reply
16-11-2017, 03:58 PM
Post: #4
RE: Error from multiple adapters with same IP address
The patch turned out not to work on Mac (which uses the same OS porting layer but can report NULL subnet masks). If you have a moment, can you check that you're happy with my changes please?
Find all posts by this user
Quote this message in a reply
16-11-2017, 10:28 PM (This post was last modified: 16-11-2017 11:01 PM by simoncn.)
Post: #5
RE: Error from multiple adapters with same IP address
(16-11-2017 03:58 PM)simonc Wrote:  The patch turned out not to work on Mac (which uses the same OS porting layer but can report NULL subnet masks). If you have a moment, can you check that you're happy with my changes please?

I am slightly puzzled by this as the previous code dereferenced ifa_netmask without a NULL check and the current code continues to do this in line 1159. Is there something else about adapters with a NULL netmask that prevents them from being added to the list (lines 1146 to 1151)? If so, the change seems OK.

Still on the subject of Os.c (but a different issue), there is a new UNUSED macro in Windows\Os.c that causes a compilation failure (syntax error) on Visual Studio 2010. A patch is attached.

On further reflection, the change might not be OK because if there is some other adapter later in the OS adapter list with a NULL netmask and the same IP address as the current adapter, the check in line 1179 will cause the current adapter not to be added to the ohNet list.

If adapters with NULL netmasks are never added to the ohNet list, the code in lines 1173 to line 1183 should be changed to:

Code:
while (addrsIter != NULL) {
    TIpAddress iterAddress = ((struct sockaddr_in*)addrsIter->ifa_addr)->sin_addr.s_addr;
    if (addrsIter->ifa_netmask != NULL) {
        TIpAddress iterNetMask = ((struct sockaddr_in*)addrsIter->ifa_netmask)->sin_addr.s_addr;
        if (iterAddress == address && (iterNetMask & netMask) == iterNetMask) {
            break; // superset subnet will be added later
        }
    }
    addrsIter = addrsIter->ifa_next;
}


Attached File(s)
.zip  unused.zip (Size: 504 bytes / Downloads: 0)
Find all posts by this user
Quote this message in a reply
17-11-2017, 07:46 AM
Post: #6
RE: Error from multiple adapters with same IP address
Thinking about this some more, there is another (related) issue with the approach in the patch. If there are two adapters A and B with A preceding B in the OS list, the logic for adding A to the ohNet list looks ahead to B and doesn't add A if B is for the same address and has a less specific netmask.

This doesn't do the right thing if B would fail the criteria for being added to the ohNet list. In this case, A should be added to the ohNet list, but it isn't.

The cleanest solution is to do this in two passes. The first pass is the logic that was there before the patch (create the ohNet list and filter out some adapters that should never be added). The second pass would check the ohNet list for overlapping netmasks and remove adapters that have more specific netmasks. With this approach, the NULL check wouldn't be needed because an adapter with a NULL netmask wouldn't be added to the ohNet list in the first pass.

I will work on an updated patch and post it in the next few days.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: