Fwd: [mat-wg] Atlas: DNS TCP Errors
Hello Atlas, feature request, when preforming DNS queries over TCP would it be possible for the probe to differentiate between a timeout and a TCP Reset. Currently the result just records the following when it gets a reset[1]. `error.timeout: 5000` A similar feature to record ICMP prohibited for udp queries would also be useful but likely much harder. Thanks John [1]https://atlas.ripe.net/api/v2/measurements/7859749/results?start=1488844800&stop=1488931199&format=json
Hi John, On 2017/03/14 14:49 , John wrote:
feature request, when preforming DNS queries over TCP would it be possible for the probe to differentiate between a timeout and a TCP Reset. Currently the result just records the following when it gets a reset[1].
`error.timeout: 5000`
I'll create a ticket for that. I have no idea about the ETA at the moment.
A similar feature to record ICMP prohibited for udp queries would also be useful but likely much harder.
I wonder if the retry option would help here. The second send should get an error from the kernel if the previous one resulted in an error ICMP. Actually getting the ICMP is possibly too hard, but a send error may help a bit. But it requires some experimenting to see if this approach would work. Philip
Hi Philip, On 14/03/2017 15:45, Philip Homburg wrote:
Hi John,
On 2017/03/14 14:49 , John wrote:
feature request, when preforming DNS queries over TCP would it be possible for the probe to differentiate between a timeout and a TCP Reset. Currently the result just records the following when it gets a reset[1].
`error.timeout: 5000`
I'll create a ticket for that. I have no idea about the ETA at the moment. Awesome thanks, no need for ETA just wanted to get it on the radar
A similar feature to record ICMP prohibited for udp queries would also be useful but likely much harder.
I wonder if the retry option would help here. The second send should get an error from the kernel if the previous one resulted in an error ICMP.
Actually getting the ICMP is possibly too hard, but a send error may help a bit. But it requires some experimenting to see if this approach would work. a bit to low level, kernel, socket programing for me but a quick google produces this if it helps
""" Normally, UDP pretty much ignores ICMP errors, so if you want to see them, you need to open a raw socket to receive all ICMP packets and look for ones relevant to your socket. On Linux, at least, an alternative is to set the IP_RECVERR socket option. If you do that, you can do a recvmsg with the MSG_ERRQUEUE flag set to get any ICMP (or other) errors associated with your socket. This has the advantage of not requiring elevated privileges or a second socket. """ http://stackoverflow.com/questions/23118113/c-sockets-send-udp-and-process-i... Thanks
On 3/14/17 14:37, John wrote:
""" Normally, UDP pretty much ignores ICMP errors, so if you want to see them, you need to open a raw socket to receive all ICMP packets and look for ones relevant to your socket.
On Linux, at least, an alternative is to set the IP_RECVERR socket option. If you do that, you can do a recvmsg with the MSG_ERRQUEUE flag set to get any ICMP (or other) errors associated with your socket. This has the advantage of not requiring elevated privileges or a second socket. """
http://stackoverflow.com/questions/23118113/c-sockets-send-udp-and-process-i...
The connected UDP socket (second answer) should work fine on Linux to receive ICMP errors for rejected UDP messages. Best Nils
participants (3)
-
John -
Nils Ohlmeier -
Philip Homburg