Closed tohojo closed 6 years ago
Good one, the right answer here is to send packets with the right source address if I can get that working.
Meanwhile, would you prefer the prior default of the unspecified IP? That's easy to go back to, and would be what I'd use if/when the setting of the source address works. Maybe the warning is preferable to this, and it may actually be pretty uncommon(?) that packets don't make it back to the source. I believe it's just up to the system's routing tables and I don't expect this to show up as unexplained packet loss, either it should work or not...
Pete Heist notifications@github.com writes:
Good one, the right answer here is to send packets with the right source address if I can get that working.
Yeah, I agree.
Meanwhile, would you prefer the prior default of the unspecified IP? That's easy to go back to, and would be what I'd use if/when the setting of the source address works. Maybe the warning is preferable to this, and it may actually be pretty uncommon(?) that packets don't make it back to the source. I believe it's just up to the system's routing tables and I don't expect this to show up as unexplained packet loss, either it should work or not...
Hmm not sure; I haven't been bitten by that error myself, so I have no idea how common that is...
On Nov 24, 2017, at 5:53 PM, Toke Høiland-Jørgensen notifications@github.com wrote:
Meanwhile, would you prefer the prior default of the unspecified IP? That's easy to go back to, and would be what I'd use if/when the setting of the source address works. Maybe the warning is preferable to this, and it may actually be pretty uncommon(?) that packets don't make it back to the source. I believe it's just up to the system's routing tables and I don't expect this to show up as unexplained packet loss, either it should work or not...
Hmm not sure; I haven't been bitten by that error myself, so I have no idea how common that is...
Ok, I’m going to just revert the default for now, especially in light of the server startup problem where it might not actually work before all interfaces are up.
I’ll try to get some time on the source address problem this weekend.
Pete Heist notifications@github.com writes:
On Nov 24, 2017, at 5:53 PM, Toke Høiland-Jørgensen notifications@github.com wrote:
Meanwhile, would you prefer the prior default of the unspecified IP? That's easy to go back to, and would be what I'd use if/when the setting of the source address works. Maybe the warning is preferable to this, and it may actually be pretty uncommon(?) that packets don't make it back to the source. I believe it's just up to the system's routing tables and I don't expect this to show up as unexplained packet loss, either it should work or not...
Hmm not sure; I haven't been bitten by that error myself, so I have no idea how common that is...
Ok, I’m going to just revert the default for now, especially in light of the server startup problem where it might not actually work before all interfaces are up.
Yeah, the startup thing has some potential for pain... Probably a good idea to just revert, then.
Also, this reminds me that it may be a good idea to have a unit file that binds to a specific interface. Will open another pull request
I’ll try to get some time on the source address problem this weekend.
Awesome! :)
Yay, was able to get the source address set properly with x/net, so unspecified IPs are safe to use and the warning is gone [*]. :) I was saddled up for a showdown, but it wasn't that bad. Notes:
Awesome, great work!
Since the default for the server now is to explicitly listen on each active address, irtt will no longer automatically listen on new interfaces or even new addresses on existing ones. This makes it a bit harder to run a long-running irtt server instance on a machine that changes addresses (and can even lead to problems if irtt is started at boot before all interfaces are fully configured).
Unfortunately, I don't believe the Go standard library has an interface for discovering new addresses. It's not a huge amount of code to subscribe to updates via netlink (I implemented this in a tool of mine: https://github.com/tohojo/nsregd/blob/master/nsregc.go#L281), but it does require pulling in a netlink library, and it's obviously not portable.