Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with multiple IP address interfaces #698

Open
stephan57160 opened this issue Aug 5, 2021 · 6 comments
Open

Problem with multiple IP address interfaces #698

stephan57160 opened this issue Aug 5, 2021 · 6 comments

Comments

@stephan57160
Copy link
Contributor

stephan57160 commented Aug 5, 2021

My application is a GO application, unning on a Linux/arm box.
It uses the GOZYRE layer (for the full context).

Initialization is like :

	...
	myIp := findMyIp() // returns "192.168.57.92" in the following
	node :=	gozyre.New("myBox", myIp, 0, headers, false)
	node.SetBeaconPeerPort(49374)
	node.Start()
	...

GO to C is rather straightforward and does not seem to bring special things.
Basically, it would look like:

	node = zyre_new("myBox");
	zyre_set_header(node, xxx, yyy);
	zyre_set_interface(node, "192.168.57.92");
	zyre_set_beacon_peer_port(49374);
	...

All is fine for years ;-)

Now, I add another IP on the same unique interface:

	[root@myBox ~]$ ifconfig eth0:1
	eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
	        inet 192.168.1.201  netmask 255.255.255.0  broadcast 192.168.1.255
	        ether b8:27:eb:9a:38:ce  txqueuelen 1000  (Ethernet)
	[root@myBox ~]$ 

Then, when the application is (re-)started, the other nodes in the
network are confused. They show continuous Enter/.../Exit for this particular
node.

Using TCPDUMP, I see the following:

  • broadcast is performed on 192.168.57.255: ok.
  • source address of TCP connection is set to 192.168.57.92: ok.
  • content of the TCP flow shows tcp://192.168.1.201:49374 !!
    This requests other nodes to contact my Box on its wrong address.

If one specifies the interface address with zyre_set_interface(), the same
address should be used to identify the TCP connection, no ?

Did I miss anything ?
Did I miss a call to something special ?
Or further investigations would be of interest ?

@cowratt
Copy link

cowratt commented Mar 9, 2022

Did you ever find a solution to this? I am having the exact same problem: A machine with two network interfaces is constantly sending the Enter message on the eth1 and appears to only be listening on eth0. Any help would be greatly appreciated.

Thanks!

@stephan57160
Copy link
Contributor Author

stephan57160 commented Mar 9, 2022

Sorry, no solution so far ...
I suppose that the ZMQ layer fails to detect the right interface, but did not time to investigate further, no.

Moreover, I think that there will be some "differences" with other OS than Linux.
For those, not sure I'm qualified to do anything.

But ... I'm glad to see that I'm not alone with this problem ;-)

@sphaero
Copy link
Contributor

sphaero commented Mar 9, 2022

I've experienced it as well. It's fixable for the broadcast but it's a bigger problem for the grouping of Zyre peers. At least last time I checked.

Imagine two nics with a single group of peers but peers connected on either of the two nics. A whisper can't reach all peers then except for the peer with the two nics.

@sphaero
Copy link
Contributor

sphaero commented Mar 9, 2022

Btw if you look in the code it's not hard to force it to attach to a specific NIC

@stephan57160
Copy link
Contributor Author

Hmmmm...
When I checked, I did not find it so "easy", but I'm not that familiar with its code.
And ... not sure wether ETH0:1 would be considered as a NIC...

I'll check again, hopefully, this week.

@sthoduka
Copy link
Contributor

when you call zyre_set_interface, the provided argument should be the name of the interface rather than an IP address, right? i.e. zyre_set_interface(node, "eth0:1"). I'm not sure if that will fix your problem, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants