search

heistp / irtt

Isochronous Round-Trip Tester
GNU General Public License v2.0
185 stars 23 forks source link

MultipleAddresses warning is emitted even when -b is specified #2

Closed tohojo closed 6 years ago

tohojo commented 6 years ago 
$ irtt server -b 10.60.4.2
IRTT server starting...
[MultipleAddresses] warning: multiple IP addresses, bind addresses should be explicitly specified with -b or clients may not be able to connect
heistp commented 6 years ago

Let me know if this causes any trouble for you or is a pain for setup in any way.

I originally got nailed by this because I was sending packets to a remote router with multiple interfaces, one Ethernet on an internal 10.a.b.0 subnet, and another OpenVPN on a 10.x.y.0 subnet. The irtt server was running right on the router, I was trying to connect to 10.a.b.1 through my OpenVPN tunnel, but packets were coming back from 10.x.y.1, or similar. Doh.

I don't know how many other situations this can happen in or if it's all that common, but the problem is avoided when the bind address is explicitly specified, and those that don't have any unspecified bind addresses shouldn't be warned anymore. Thanks for noticing!

tohojo commented 6 years ago

Haven't been bitten by it, but saw the explanation in the FAQ. Wouldn't the right thing to do be to always use the same source address for the reply as the destination of the incoming request? Not sure how difficult that is to do in Go?

heistp commented 6 years ago

On Nov 21, 2017, at 11:37 PM, Toke Høiland-Jørgensen notifications@github.com wrote:

Haven't been bitten by it, but saw the explanation in the FAQ. Wouldn't the right thing to do be to always use the same source address for the reply as the destination of the incoming request? Not sure how difficult that is to do in Go?

That sounds right to me too, but unfortunately there’s no apparent way in the standard net package to specify a source address for an individual packet when sending it. I’m still exploring some lower level net stuff in golang.org/x/net http://golang.org/x/net. There’s a vague note about using oob data to specify socket options and very little info on it. Some more discovery to do...

DSCP is also at the socket level and not per-packet, so there has to be a mutex on the server across setting sock opts and sending the packet so clients don’t stomp on one another. I'd also love to see if I can get that out of there, but at least it seems that setting the option happens quickly.