Re: "cvs update" hängt bei TSDL + natd + tcpmssd

Hallo Udo!

> das kommt mir irgendwie bekannt vor. Sehr bekannt sogar. Hast Du schon mal
> versucht, Dateien per ftp auf den cvs-Server zu schieben? Oder per uucp
> Dateien auf diesen Rechner zu kopieren? Das dürfte auch nicht gehen.

ftp geht prinzipbedingt nicht, da ich mit passive ftp aus meinem lan raus
muß aber nur mit active ftp in das netz, wo der cvs-server steht, reinkomme,
da hängtim Zielnetz noch eine ipchains-Firewall dazwischen. Auf deren Logs ich übrigens
Zugriff habe, falls die irgendwie relevant sein sollten. Uucp ist
beiderseits nicht konfiguriert. Scp funktioniert aber.

> Du hast bei Deinem tcpdump wahrscheinlich gesagt "Gib mir den Traffic
> zu Rechner X, Port cvs." Sorg mal für Ruhe im LAN, nimm Dir zwei xterms,

Ja.

> screens oder Konsolen, starte auf der einen tcpdump -ni tun0, auf der
> anderen tcpdump -ni <ethernet-interface-für-tdsl> und wirf dann den cvs
> update an.

> Ich bin versucht, die hier stehende halbvolle Flasche Glenfiddich[0] zu
> wetten, daß Du "icmp: $somebox to $yourip, $cvshost unreachable, frag
> needed, MTU 4711" Messages sehen wirst. Und das diese Messages auf de

Lieber nicht, ich habe schon mal bei einem Quiz in einem Irish Pub einen
Glenfiddich gewonnen und sah mich dann überraschend mit der Aufgabve
konfrontiert, diesen schneller als gewohnt leeren zu müssen. War nicht so
richtig recovery ... ;-)

Jedenfalls, ich sehe nichts dergleichen. Hier mal die tcpdumps. 129.69.74.30
= der CVS-Server, {217.80.51.46,192.168.1.1} = der FreeBSD-Router,
192.168.1.47 = der Client auf dem cvs update läuft:

a) von ed0, dem Interface über das nur PPPoE läuft:

13:05:12.274161 PPPoE DATA v1, type 1, sess 31081 len 42] 129.69.74.30.2401
> 217.80.51.46.58273: . ack 436 win 17520
13:05:12.577445 PPPoE DATA v1, type 1, sess 31081 len 42] 217.80.51.46.58259
> 129.69.74.30.2401: R 3539691661:3539691661(0) ack 848641397 win 33580 (DF)
13:05:23.571687 PPPoE DATA v1, type 1, sess 31081 len 14] ID-096 LCP:
 Echo-Request, Magic-Number=-1740868657
                         0960 000c 983c 73cf 6a6a 6a6a 0000
13:05:23.571936 PPPoE DATA v1, type 1, sess 31081 len 14] ID-096 LCP:
Echo-Reply, Magic-Number=258539913
                         0a60 000c 0f69 0189 6a6a 6a6a d950
13:05:33.586499 PPPoE DATA v1, type 1, sess 31081 len 14] ID-097 LCP:
Echo-Request, Magic-Number=-1740868657
                         0961 000c 983c 73cf 6a6a 6a6a 0000
13:05:33.586762 PPPoE DATA v1, type 1, sess 31081 len 14] ID-097 LCP:
Echo-Reply, Magic-Number=258539913
                         0a61 000c 0f69 0189 6a6a 6a6a d950

b) von tun0:

13:05:11.222800 129.69.74.30.2401 > 217.80.51.46.58273: S 3485065972:3485065972
 (0) ack 3650808953 win 16384 <mss 1460,nop,wscale 0>
13:05:11.223679 217.80.51.46.58273 > 129.69.74.30.2401: . ack 1 win 33580 (DF)
13:05:11.261857 217.80.51.46.58273 > 129.69.74.30.2401: P 1:20(19) ack 1 win
 33580 (DF)
13:05:11.294612 129.69.74.30.2401 > 217.80.51.46.58273: . ack 1 win 17520
13:05:11.440256 129.69.74.30.2401 > 217.80.51.46.58273: . ack 20 win 17501
13:05:11.441043 217.80.51.46.58273 > 129.69.74.30.2401: P 20:55(35) ack 1 win
 33580 (DF)
13:05:11.645063 129.69.74.30.2401 > 217.80.51.46.58273: P 1:12(11) ack 55 win
 17520
13:05:11.673093 217.80.51.46.58273 > 129.69.74.30.2401: P 55:423(368) ack 12
 win 33580 (DF)
13:05:11.779709 129.69.74.30.2401 > 217.80.51.46.58273: P 12:520(508) ack 423
 win 17520
13:05:11.782175 217.80.51.46.58273 > 129.69.74.30.2401: P 423:436(13) ack 520
 win 33580 (DF)
13:05:12.021568 129.69.74.30.2401 > 217.80.51.46.58273: . ack 436 win 17520
13:05:12.153377 217.80.51.46.58273 > 129.69.74.30.2401: P 3356:4168(812) ack
 520 win 33580 (DF)
13:05:12.274292 129.69.74.30.2401 > 217.80.51.46.58273: . ack 436 win 17520
13:05:12.577219 217.80.51.46.58259 > 129.69.74.30.2401: R 3539691661:
 3539691661(0) ack 848641397 win 33580 (DF)

c) von fxp0, dem internen LAN-Interface:

13:05:11.645247 129.69.74.30.2401 > 192.168.1.47.58273: P 1:12(11) ack 55 win
 17520
13:05:11.672956 192.168.1.47.58273 > 129.69.74.30.2401: P 55:423(368) ack 12
 win 33580 (DF)
13:05:11.779863 129.69.74.30.2401 > 192.168.1.47.58273: P 12:520(508) ack 423
 win 17520
13:05:11.782055 192.168.1.47.58273 > 129.69.74.30.2401: P 423:436(13) ack 520
 win 33580 (DF)
13:05:12.021763 129.69.74.30.2401 > 192.168.1.47.58273: . ack 436 win 17520
13:05:12.151383 192.168.1.47.58273 > 129.69.74.30.2401: . 436:1896(1460) ack
 520 win 33580 (DF)
13:05:12.152613 192.168.1.47.58273 > 129.69.74.30.2401: . 1896:3356(1460) ack
 520 win 33580 (DF)
13:05:12.153270 192.168.1.47.58273 > 129.69.74.30.2401: P 3356:4168(812) ack
 520 win 33580 (DF)
13:05:12.274442 129.69.74.30.2401 > 192.168.1.47.58273: . ack 436 win 17520
13:05:12.577014 192.168.1.47.58259 > 129.69.74.30.2401: R 3539691661:
 3539691661(0) ack 848641397 win 33580 (DF)
13:05:13.078605 192.168.1.47.58273 > 129.69.74.30.2401: . 436:1896(1460) ack
 520 win 33580 (DF)
13:05:17.078450 192.168.1.47.58273 > 129.69.74.30.2401: . 436:1896(1460) ack
 520 win 33580 (DF)

> Lösung: In tcpmssd die MTU runterschrauben, bis die Meldungen nicht mehr
> kommen. Path MTU discovery über tun0 funktioniert leider nicht, weil
> irgendwer oder irgendwas die ICMP messages kaputtschlägt.

Nö, das half nicht. Habe die testweise schon einfach mal bis auf 998
runtergesetzt, ohne daß sich was verbessert hätte.

Viele Grüße,
Tobias.

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 12 Mar 2001 - 13:20:39 CET