is dnswl dead?
valdis.kletnieks at vt.edu
Fri May 3 16:47:25 UTC 2019
On Fri, 03 May 2019 00:55:17 -0500, Jose Manuel Vazquez Castro said:
> And check first connectivity ping and telnet tcp ports 22 , 873 to ips
> destination's from your linuxbox:
> Record A rsync2.dnswl.org
> Or use in the command directly the ip.
> You are behinds a router, proxy , Nat device. May cause problems or deny
> filter traffic. If share a Wireshark capture will see what's happens ..
>From here, tcpdump/wireshark indicate that something is indeed amiss.
rsync gets through the 3-packet handshake, and then about 20 packets
11:34:52.749962 IP 192.168.1.73.42138 > 220.127.116.11.rsync: Flags [.], ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 0
11:34:52.750309 IP 192.168.1.73.42138 > 18.104.22.168.rsync: Flags [P.], seq 79:87, ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 8
11:34:52.851104 IP 22.214.171.124.rsync > 192.168.1.73.42138: Flags [.], ack 87, win 227, options [nop,nop,TS val 1658500119 ecr 3218474733], length 0
11:34:53.162604 IP 126.96.36.199.rsync > 192.168.1.73.42138: Flags [R.], seq 32, ack 87, win 227, options [nop,nop,TS val 1658500197 ecr 3218474733], length 0
The far end tosses an ACK for the packet, and then an ACK/RST rather than a FIN.
Rather anti-social - usually indicative of the daemon at the far end crashing and
closing the socket.
(Side note - is it me, or does the rsync dissector for wireshark do a less than optimal job?)
(And yes, I know for a fact that my router doesn't bork rsync, as it works
for other stuff on a regular basis..)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 832 bytes
Desc: not available
More information about the NANOG