Dotaz: diagnostika spojeni, dlouhe latence

[temporary]

DV,

při navázání tcp spojení k serveru dochází k dlouhým prodlevám mezi navázáním spojení a následným spuštěním daemona poslouchajícího na daném portu.

Nejlépe to asi lze pochopit z tcpdumpu, pokouším se telnetem spojit na port 25. Prodleva mezi navázáním spojení a počátkem SMTP komunikace je vždy 70 sekund. SMTP je jenom příklad, podobně se systém chová při veškeré tcp komunikaci. Například ping dostává odpověď okamžitě. Firewall není zapnuty.

client:
$ date
Wed Nov  1 20:24:35 CET 2006
$ telnet fiser 25

server:
# cat log
# /usr/sbin/tcpdump -i br0 -p tcp port 25 and host 192.168.9.111
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
20:25:28.130601 IP 192.168.9.111.14799 > fiser.smtp: S 1143135126:1143135126(0) win 5840 <mss 1460,sackOK,timestamp 38509522 0,nop,wscale 2>
20:25:28.130629 IP fiser.smtp > 192.168.9.111.14799: S 2085761170:2085761170(0) ack 1143135127 win 5792 <mss 1460,sackOK,timestamp 1436587 38509522,nop,wscale 2>
20:25:28.130753 IP 192.168.9.111.14799 > fiser.smtp: . ack 1 win 1460 <nop,nop,timestamp 38509522 1436587>
20:26:16.969863 IP fiser.smtp > 192.168.9.111.14798: P 2063793410:2063793433(23) ack 1122728013 win 1448 <nop,nop,timestamp 1485434 38507104>
20:26:16.969980 IP fiser.smtp > 192.168.9.111.14798: F 23:23(0) ack 1 win 1448 <nop,nop,timestamp 1485434 38507104>
20:26:16.970026 IP 192.168.9.111.14798 > fiser.smtp: R 1122728013:1122728013(0) win 0
20:26:16.970070 IP 192.168.9.111.14798 > fiser.smtp: R 1122728013:1122728013(0) win 0
20:26:38.203577 IP fiser.smtp > 192.168.9.111.14799: P 1:24(23) ack 1 win 1448 <nop,nop,timestamp 1506671 38509522>
20:26:38.203749 IP 192.168.9.111.14799 > fiser.smtp: . ack 24 win 1460 <nop,nop,timestamp 38527038 1506671>

Odpovědi

[*]

/usr/sbin/tcpdump -i br0 \( tcp and \( port 25 or port 113 or port 53 or port 111 \) \) or \( udp and \( port 53 or port 111 \) \) and host 192.168.9.111

doporucuji jak na klientovi, tak na serveru.

[*]

i kdyz...

20:26:16.970070

20:26:38.203577

todle uz naznacuje, ze nepujde o problem pri nabazovani spojeni...

[*]

i kdyz zase Reset a v odpovedi Push+ack. asi zase neco logoval xinetd...

[*]

jinak dalsi podezreli viz:

grep /etc/nsswitch.conf -e hosts

a prepinace typu nospoof apod v /etc/host.conf

[*]

sakra. dyt je to skoro kazdy treti radek z jineho spojeni...