<div dir="ltr"><div><div><div><div>John,<br><br></div><div>thank you very much for your detailed answers!<br></div><div><br></div>When we discovered the binding of an additional (wrong) interface in netstat-g we first did not know if this is for sending or receiving. We had not been sure if this could cause spread sending something to the wrong interface which might lead to retransmissions or other problems in spread communication.<br><br>So we decided to instruct spread to bind the one and only interface corresponding to the given host's address by the spread.conf stated below. As we understood the implementation for this in spread 4 has room for improvement. But this is not a problem because we learnt the binding is for incoming direction and there will almost never be incoming traffic on that wrong interface at the spread port.<br><br></div>Nevertheless we like the more strict behavior of spread 5 for that. We will keep our restriction to the one and only interface for spread, because the other interfaces are used for other things. And we do not want spread to touch these other interfaces.<br><br></div>Cheers!<br><br></div>Martin<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 1:02 AM, John Lane Schultz <span dir="ltr"><<a href="mailto:jschultz@spreadconcepts.com" target="_blank">jschultz@spreadconcepts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Martin, Everyone,<br>
<br>
I also looked at what would happen under Spread v5.0 if you omitted the interface specification in your configuration. In that case, I think it would bind a recv channel to INADDR_ANY (so traffic on any interface to its port that wasn’t already bound by another process could reach it) and it would join the multicast group on its main address interface. So, you might not need the interface specification any more if you don’t care about limiting on which interface traffic to your port might arrive. That is, if the only reason you were using the interface specification was to force the multicast group join to occur on the correct interface, then that issue might be gone in Spread v5.0. Give it a shot and see, if you like.<br>
<br>
r = DL_init_channel_gen(RECV, NULL, [INADDR_ANY, port]) /* recv data */<br>
bind(r, [INADDR_ANY, port])<br>
<br>
DL_join_multicast_gen(r, 239.192.2.2, 151.1.1.1)<br>
join(r, multiaddr=239.192.2.2, interface=151.1.1.1)<br>
<br>
tr = DL_init_channel_gen(RECV, 0, [INADDR_ANY, port+1]) /* unicast recv token */<br>
bind(tr, [INADDR_ANY, port+1])<br>
<br>
I also forgot to mention that in v5.0, I separately make a socket for sending that is always bound to the main address of the daemon:<br>
<br>
s = DL_init_channel_gen(SEND | RECV, NULL, [151.1.1.1, 0])<br>
bind(s, [151.1.1.1, 0])<br>
<br>
This can be important because Spread v5.0 now enforces that, at the IP level, the source address of received traffic matches that primary address associated with the daemon who claims to have sent it in the packet. So, Spread itself now implements a weak form of IP based “firewalling.” It will ignore packets who source IP address doesn’t match the address of the transmitter marked in the packet.<br>
<br>
This is an important change and means, for example, that spmonitor must be run on one of the machines in the current configuration or its traffic will be ignored too. This was done intentionally so that if someone wanted to send traffic to your Spread deployment, then they would either have to forge IP headers or be on one of the machines in your configuration.<br>
<span class=""><br>
Cheers!<br>
<br>
-----<br>
John Lane Schultz<br>
Spread Concepts LLC<br>
Cell: 443 838 2200<br>
<br>
</span><div><div class="h5">On Dec 14, 2016, at 12:51 PM, John Lane Schultz <<a href="mailto:jschultz@spreadconcepts.com">jschultz@spreadconcepts.com</a>> wrote:<br>
<br>
Martin,<br>
<br>
Here’s the difference between the two versions in how they bind and how they join multicast groups for your configuration file. I used 151.1.1.1 as my example.<br>
<br>
##########################<br>
Spread v4.4:<br>
<br>
mr = DL_init_channel(RECV, 239.192.2.2, 239.192.2.2, port) /* multicast recv data */<br>
bind(mr, [239.192.2.2, port]);<br>
join(mr, multiaddr=239.192.2.2, interface=INADDR_ANY)<br>
<br>
ur = DL_init_channel(RECV | DL_BIND_ALL, 239.192.2.2, 155.1.1.1, port) /* unicast recv data */<br>
bind(ur, [155.1.1.1, port])<br>
join(ur, multiaddr=239.192.2.2, interface=155.1.1.1)<br>
<br>
tr = DL_init_channel(RECV, 0, 155.1.1.1, port+1) /* unicast recv token */<br>
bind(tr, [155.1.1.1, port+1])<br>
<br>
##########################<br>
Spread v5.0:<br>
<br>
ur = DL_init_channel_gen(RECV, NULL, 155.1.1.1) /* unicast recv data */<br>
bind(ur, [155.1.1.1, port])<br>
<br>
DL_join_multicast_gen(ur, 239.192.2.2, 151.1.1.1)<br>
join(ur, multiaddr=239.192.2.2, interface=151.1.1.1)<br>
<br>
tr = DL_init_channel_gen(RECV, 0, 155.1.1.1, port+1) /* unicast recv token */<br>
bind(tr, [155.1.1.1, port+1])<br>
<br>
mr = DL_init_channel_gen(RECV, NULL, 239.192.2.2) /* multicast recv data */<br>
bind(mr, [239.192.2.2, port])<br>
<br>
DL_join_multicast_gen(mr, RECV, 239.192.2.2, 151.1.1.1)<br>
join(mr, multiaddr=239.192.2.2, interface=151.1.1.1)<br>
<br>
##########################<br>
<br>
The reason why you see v4.4 joining the same group on different interfaces is that v4.4 joins 239.192.2.2 on interfaces INADDR_ANY and interface 151.1.1.1 on different file descriptors.<br>
<br>
Meanwhile, v5.0 joined 239.192.2.2 both on interface 151.1.1.1 on two different file descriptors.<br>
<br>
The extra join on the unicast recv file descriptor is probably only necessary on Windows where the extra multicast recv file descriptor isn’t even created.<br>
<br>
Cheers!<br>
<br>
-----<br>
John Lane Schultz<br>
Spread Concepts LLC<br>
Cell: 443 838 2200<br>
<br>
On Dec 14, 2016, at 7:18 AM, Martin Schu <<a href="mailto:martin.sc11111@gmail.com">martin.sc11111@gmail.com</a>> wrote:<br>
<br>
Hi John,<br>
<br>
we have some strange observation:<br>
With spread-4.4.0 running on some of our hosts we see a wrong binding of an additional interface for multicast, which makes no sense to us and might be causing problems due to wrong routed traffic.<br>
With spread-5.5.0rc1 this malfunction is gone. Only the correct interface is bound.<br>
<br>
Maybe you can help us to understand what is happening here. Below is the output of netstat -g on the same host with same configuration. Only the spread installation was updated! No other change.<br>
<br>
Any advice is greatly welcome. We don't understand what causes that wrong interface binding.<br>
<br>
Best regards,<br>
Martin<br>
<br>
** spread.conf:<br>
Spread_Segment <a href="http://239.192.2.2:8982" rel="noreferrer" target="_blank">239.192.2.2:8982</a> {<br>
host1 155.1.1.1 { 155.1.1.1 }<br>
host2 155.1.1.2 { 155.1.1.2 }<br>
host3 155.1.1.3 { 155.1.1.3 }<br>
}<br>
Spread_Segment <a href="http://239.192.2.4:8982" rel="noreferrer" target="_blank">239.192.2.4:8982</a> {<br>
host4 155.1.1.4 { 155.1.1.4 }<br>
host5 155.1.1.5 { 155.1.1.5 }<br>
host6 155.1.1.6 { 155.1.1.6 }<br>
}<br>
<br>
** spread-4.4.0<br>
running:<br>
<br>
<br>
$ netstat -g<br>
IPv6/IPv4 Group Memberships<br>
Interface RefCnt Group<br>
--------------- ------ ---------------------<br>
lo 1 224.0.0.1<br>
eth0 1 224.0.0.1<br>
eth1 1 224.0.0.1<br>
eth2 1 239.192.2.2<br>
!!!WRONG!!!<br>
<br>
eth2 1 224.0.0.1<br>
eth3 1 239.192.2.2<br>
CORRECT<br>
<br>
eth3 1 224.0.0.1<br>
eth4 1 224.0.0.1<br>
<br>
<br>
<br>
** no spread running:<br>
<br>
<br>
$ netstat -g<br>
IPv6/IPv4 Group Memberships<br>
Interface RefCnt Group<br>
--------------- ------ ---------------------<br>
lo 1 224.0.0.1<br>
eth0 1 224.0.0.1<br>
eth1 1 224.0.0.1<br>
eth2 1 224.0.0.1<br>
eth3 1 224.0.0.1<br>
eth4 1 224.0.0.1<br>
<br>
<br>
<br>
**<br>
spread-5.0.0rc1<br>
running:<br>
<br>
<br>
$ netstat -g<br>
IPv6/IPv4 Group Memberships<br>
Interface RefCnt Group<br>
--------------- ------ ---------------------<br>
lo 1 224.0.0.1<br>
eth0 1 224.0.0.1<br>
eth1 1 224.0.0.1<br>
eth2 1 224.0.0.1<br>
eth3 2 239.192.2.2 CORRECT<br>
eth3 1 224.0.0.1<br>
eth4 1 224.0.0.1<br>
<br>
<br>
<br>
<br>
</div></div>______________________________<wbr>_________________<br>
Spread-users mailing list<br>
<a href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a><br>
<a href="http://lists.spread.org/mailman/listinfo/spread-users" rel="noreferrer" target="_blank">http://lists.spread.org/<wbr>mailman/listinfo/spread-users</a><br>
<br>
</blockquote></div><br></div></div>