fetch http://localhost:6666 hangs



Hello!

I just noticed, that on my recent "6.1-STABLE #4: Thu Jun 8" amd64 system
attempts to connect to a bogus port (like 6666) hang instead of failing
with "Connection refused" immediately, as they on other systems.

Why would this be? There is nothing listening: ``netstat -n | grep 6666'' is
empty. The ipfw rules are very simple:

00200 pipe 1 ip from any to 172.21.128.43 dst-port 2049
65535 allow ip from any to any

While fetch is trying to connect, the tcpdump prints:

% tcpdump -vvv -i lo0 port 6666
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 68 bytes
14:28:43.465182 IP (tos 0x0, ttl 64, id 56427, offset 0, flags [DF], proto: TCP (6), length: 64) localhost.52326 > localhost.6666: S, cksum 0x0558 (correct), 583002422:583002422(0) win 65535 <mss 16344,nop,wscale 1,nop,nop,timestamp 1610196770 0,sackOK,eol>
14:28:46.464121 IP (tos 0x0, ttl 64, id 56491, offset 0, flags [DF], proto: TCP (6), length: 64) localhost.52326 > localhost.6666: S, cksum 0xf99f (correct), 583002422:583002422(0) win 65535 <mss 16344,nop,wscale 1,nop,nop,timestamp 1610199770 0,sackOK,eol>
14:28:49.663980 IP (tos 0x0, ttl 64, id 56530, offset 0, flags [DF], proto: TCP (6), length: 64) localhost.52326 > localhost.6666: S, cksum 0xed1f (correct), 583002422:583002422(0) win 65535 <mss 16344,nop,wscale 1,nop,nop,timestamp 1610202970 0,sackOK,eol>
14:28:52.863836 IP (tos 0x0, ttl 64, id 56559, offset 0, flags [DF], proto: TCP (6), length: 48) localhost.52326 > localhost.6666: S, cksum 0x5993 (correct), 583002422:583002422(0) win 65535 <mss 16344,sackOK,eol>
[...]

Meanwhile, a "healthy" system prints:

% tcpdump -vvv -i lo0 port 6666
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 68 bytes
14:29:55.716350 IP (tos 0x0, ttl 64, id 7958, offset 0, flags [DF], proto: TCP (6), length: 64) localhost.49238 > localhost.6666: S, cksum 0x7d0e (correct), 3929347125:3929347125(0) win 65535 <mss 16344,nop,wscale 1,nop,nop,timestamp 1704674149 0,sackOK,eol>
14:29:55.718358 IP (tos 0x0, ttl 64, id 7959, offset 0, flags [DF], proto: TCP (6), length: 40) localhost.6666 > localhost.49238: R, cksum 0xd901 (correct), 0:0(0) ack 3929347126 win 0

Any clues? Thanks!

-mi
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Problem accessing some websites
    ... you can see the size being set in tcpdump. ... listening on ppp0, link-type LINUX_SLL, capture size 96 bytes ...
    (Debian-User)
  • Re: Problem accessing some websites
    ... you can see the size being set in tcpdump. ... listening on ppp0, link-type LINUX_SLL, capture size 96 bytes ...
    (Debian-User)
  • Re: packet capture
    ... >Subject: Re: packet capture ... >I agree tcpdump -w somefile is great. ... >format, so you can process it later with tcpdump, snort, ngrep, or ... >Then snort for analyzing the packets (okay tcpdump does this too, ...
    (Security-Basics)
  • Re: No packet loss, just incorrect sequence...
    ... As others have mentioned you should definitely use tcpdump to capture some traffic while downloading something. ... Not only will this clearly diagnose the TCP performance problem but it will irrefutably demonstrate it to your ISP. ...
    (uk.comp.sys.mac)
  • Some problems in capturing traffic with tcpdump at ~ 1 Gbps
    ... hyperthreading and 2 Gbytes RAM size) ... Mbps (we have some traffic samples acquired with tcpdump). ... improvement in the packet capture process. ... With this configuration we can capture 1 Gbyte of traffic, ...
    (comp.os.linux.networking)