/ Forside / Teknologi / Netværk / TCP/IP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
TCP/IP
#NavnPoint
Per.Frede.. 4668
BjarneD 4017
severino 2804
pallebhan.. 1680
EXTERMINA.. 1525
xou 1455
strarup 1430
Manse9933 1419
o.v.n. 1400
10  Fijala 1204
route på Linux
Fra : Stephan Henningsen


Dato : 30-05-05 15:50

Hey,

Jeg har et skørt problem; skørt fordi jeg aldrig har oplevet det
før. Jeg har to maskiner i et netværk, hvoraf den ene er
forbundet med en wlan usb dongle. Maskinerne kan nå hinanden med
ping, og telnet fungerer også fint. wget (--proxy=off) og ssh
når aldrig helt igennem. ssh -d afslører, at de faktisk bliver
enige om protokol og udvæksler serverversioner, men så stopper
den ved "debug1: expecting SSH2_MSG_KEXDH_REPLY". wget stopper
med "HTTP request sent, awaiting response...".

Jeg ved ærligt talt ikke, hvad der er problemet, men jeg vil
umiddelbart gætte på maskinernes route-tabel eller at driveren
til min dongle er syg. Fordi kommunikerer de to maskiner over
andre enheder (bluetooth og kabel) så virker ovennævnte fint.

Her er de to route-tabeller krydret med linieskift:

root@1901000039# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.0.0.0 * 255.255.255.0 U 0 0
0 wlan0


root@tetris# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.0.0.0 * 255.255.255.0 U 0 0
0 eth1


--
Stephan Henningsen

 
 
Morten Fjendbo (30-05-2005)
Kommentar
Fra : Morten Fjendbo


Dato : 30-05-05 16:59

Stephan Henningsen typed:
> Hey,
>
> Jeg har et skørt problem; skørt fordi jeg aldrig har oplevet det
> før. Jeg har to maskiner i et netværk, hvoraf den ene er
> forbundet med en wlan usb dongle. Maskinerne kan nå hinanden med
> ping, og telnet fungerer også fint. wget (--proxy=off) og ssh
> når aldrig helt igennem. ssh -d afslører, at de faktisk bliver
> enige om protokol og udvæksler serverversioner, men så stopper
> den ved "debug1: expecting SSH2_MSG_KEXDH_REPLY". wget stopper
> med "HTTP request sent, awaiting response...".
>
> Jeg ved ærligt talt ikke, hvad der er problemet, men jeg vil
> umiddelbart gætte på maskinernes route-tabel eller at driveren
> til min dongle er syg. Fordi kommunikerer de to maskiner over
> andre enheder (bluetooth og kabel) så virker ovennævnte fint.
>
> Her er de to route-tabeller krydret med linieskift:
>
> root@1901000039# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> 10.0.0.0 * 255.255.255.0 U 0 0
> 0 wlan0
>
>
> root@tetris# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> 10.0.0.0 * 255.255.255.0 U 0 0
> 0 eth1

Uden at kende noget til dit problem så ser det ud til at mange andre
har haft samme problem:
http://www.google.com/search?q=expecting+SSH2_MSG_KEXDH_REPLY&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official



Stephan Henningsen (31-05-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 31-05-05 07:54

Morten Fjendbo wrote:

> Uden at kende noget til dit problem så ser det ud til at mange andre
> har haft samme problem:
> http://www.google.com/search?q=expecting+SSH2_MSG_KEXDH_REPLY&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official

Hvis du tænker på nogle specielle ud af de 437 resultater, kan du
så ikke poste dem? "expecting SSH2_MSG_KEXDH_REPLY" er indeholdt
i samtlige debug-output fra samtlige problemer som folk har haft
oplevet med ssh, så et svar på mit problem, springer ikke just i
øjnene. Ellers tak =)

--
Stephan Henningsen

Lasse Jarlskov (31-05-2005)
Kommentar
Fra : Lasse Jarlskov


Dato : 31-05-05 19:45

On Mon, 30 May 2005 16:49:54 +0200, Stephan Henningsen
<test@hotmail.com> wrote:

>Jeg har et skørt problem; skørt fordi jeg aldrig har oplevet det
>før. Jeg har to maskiner i et netværk, hvoraf den ene er
>forbundet med en wlan usb dongle. Maskinerne kan nå hinanden med
> ping, og telnet fungerer også fint. wget (--proxy=off) og ssh
>når aldrig helt igennem. ssh -d afslører, at de faktisk bliver
>enige om protokol og udvæksler serverversioner, men så stopper
>den ved "debug1: expecting SSH2_MSG_KEXDH_REPLY". wget stopper
>med "HTTP request sent, awaiting response...".

Hvad er MTU på linket?

Ping og telnet overfører kun små pakker - det samme gør wget indtil
html-siden skal sendes. SSH-protokollen kender jeg ikke så meget til,
men skal jeg tolke på "expecting SSH2_MSG_KEXDH_REPLY", så skal
parterne til at udveksle kryptografiske nøgler - noget der nok også
resulterer i store pakker.

Prøv at pinge med store pakker; 1500 bytes, 1492 bytes og 1472 bytes
f.eks.


/Jarlskov

Stephan Henningsen (01-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 01-06-05 10:12

> Hvad er MTU på linket?

Hvordan ser jeg det?


> Prøv at pinge med store pakker.

Yes, det vil jeg prøve senere. Men jeg mener nu helt bestemt, at jeg
stresstestede den med nogle store ping-pakker på et tidspunkt, og det
virkede fint.

Jeg prøvede i øvrigt også at kommunikere mellem to dongles af samme
type med samme driver (zd1211), og det resulterede i en masse ping
DUPs og wget og ssh virkede stadig ikke. Jeg får ingen DUPs når jeg
pinger mellem zd1211 og et andet wlan-kort. Jeg tror mest på at
zd1211-driveren er kvast indeni.

--
Stephan Henningsen

Kasper Dupont (02-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 02-06-05 13:44

Stephan Henningsen wrote:
>
> > Hvad er MTU på linket?
>
> Hvordan ser jeg det?

ifconfig

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Kasper Dupont (02-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 02-06-05 13:43

Stephan Henningsen wrote:
>
> Hey,
>
> Jeg har et skørt problem; skørt fordi jeg aldrig har oplevet det
> før. Jeg har to maskiner i et netværk, hvoraf den ene er
> forbundet med en wlan usb dongle. Maskinerne kan nå hinanden med
> ping, og telnet fungerer også fint. wget (--proxy=off) og ssh
> når aldrig helt igennem. ssh -d afslører, at de faktisk bliver
> enige om protokol og udvæksler serverversioner, men så stopper
> den ved "debug1: expecting SSH2_MSG_KEXDH_REPLY". wget stopper
> med "HTTP request sent, awaiting response...".

Jeg ville prøve at bruge ethereal i hver ende af forbindelsen
for at finde ud af, om årsagen er pakker, der ikke når over
nettet eller, såfremt det ikke er tilfældet, hvilken maskine,
der er problemer med.

Hvis problemet viser sig at ligge på den ene maskine ville
jeg så fortsætte med strace for at finde ud af, hvad
programmet foretager sig.

En mulighed jeg ville undersøge er DNS problemer. Måske står
serveren og venter på et reverse DNS opslag.

>
> root@1901000039# route

Uheldigt hostnavn, det kunne misforstås som en IP adresse.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Stephan Henningsen (03-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 03-06-05 14:04

Kasper Dupont wrote:
>
> Jeg ville prøve at bruge ethereal i hver ende af forbindelsen

Da den ene ende er en embedded ARM, så gør det generent debugging
vanskeligt; der er ikke plads til at lægge de store værktøjer over på
den. En tcpdump har jeg dog fået lagt over, men jeg forstår ikke så
meget af den =\


> Hvis problemet viser sig at ligge på den ene maskine ville jeg så
> fortsætte med strace for at finde ud af, hvad programmet foretager
> sig.

Problemet opstår både når jeg bruger wget og firefox, så jeg vil
tillade mig indtil videre at udelukke dem fra at være fejlkilder.

Endvidere opstår problemet kun, når jeg går på ARM-boxen via wlan0
(10.0.0.1); går jeg gennem eth0 (192.168.17.1) så går http-requests
igennem, som de skal.


> En mulighed jeg ville undersøge er DNS problemer. Måske står
> serveren og venter på et reverse DNS opslag.

Jeg bruger kun IP-adresser i mine requests. eth0 virker og wlan0
virker ikke, og de skal opføre sig ens uanset DNS-situationen?


>> root@1901000039# route
>
> Uheldigt hostnavn, det kunne misforstås som en IP adresse.

Jeg har rettet det til au1901000039, men et har ikke hjulpet på dette
problem.


Ethereal ser super fedt ud. Jeg har nogle output her, som du måske kan
hjælpe med at tolke på; jeg er ikke så skarp i tcp =)

Det første er fra wget http://192.168.17.1/index.html som virker, og den
anden er fra wget http://10.0.0.1/index.html som jeg lukker loggen på
efter 30 sekunder, hvor wget bare hænger. Min klient-maskine, hvor
ethereal kører, hedder 192.168.1.2 og 10.0.0.44.
Jeg har tilladt mig at overskride linielængderne så loggen er mere læsbar:


No. Time Source Destination Protocol Info
1 0.000000 192.168.17.2 192.168.17.1 TCP 33121 > www [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=17286420 TSER=0 WS=2

Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33121 (33121), Dst Port: www (80), Seq: 0, Ack: 0, Len: 0

No. Time Source Destination Protocol Info
2 0.000359 192.168.17.1 192.168.17.2 TCP www > 33121 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=407517 TSER=17286420 WS=0

Frame 2 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
3 0.000393 192.168.17.2 192.168.17.1 TCP 33121 > www [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=17286421 TSER=407517

Frame 3 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33121 (33121), Dst Port: www (80), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
4 0.001115 192.168.17.2 192.168.17.1 HTTP GET /index.html HTTP/1.0

Frame 4 (175 bytes on wire, 175 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33121 (33121), Dst Port: www (80), Seq: 1, Ack: 1, Len: 109
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
5 0.001483 192.168.17.1 192.168.17.2 TCP www > 33121 [ACK] Seq=1 Ack=110 Win=5792 Len=0 TSV=407517 TSER=17286421

Frame 5 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 1, Ack: 110, Len: 0

No. Time Source Destination Protocol Info
6 0.011727 192.168.17.1 192.168.17.2 HTTP HTTP/1.0 200 OK

Frame 6 (232 bytes on wire, 232 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 1, Ack: 110, Len: 166
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
7 0.011739 192.168.17.2 192.168.17.1 TCP 33121 > www [ACK] Seq=110 Ack=167 Win=5840 Len=0 TSV=17286432 TSER=407518

Frame 7 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33121 (33121), Dst Port: www (80), Seq: 110, Ack: 167, Len: 0

No. Time Source Destination Protocol Info
8 0.012111 192.168.17.1 192.168.17.2 HTTP Continuation or non-HTTP traffic

Frame 8 (368 bytes on wire, 368 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 167, Ack: 110, Len: 302
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
9 0.012122 192.168.17.2 192.168.17.1 TCP 33121 > www [ACK] Seq=110 Ack=469 Win=6912 Len=0 TSV=17286433 TSER=407518

Frame 9 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33121 (33121), Dst Port: www (80), Seq: 110, Ack: 469, Len: 0

No. Time Source Destination Protocol Info
10 0.012602 192.168.17.1 192.168.17.2 TCP www > 33121 [FIN, ACK] Seq=469 Ack=110 Win=5792 Len=0 TSV=407518 TSER=17286433

Frame 10 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 469, Ack: 110, Len: 0

No. Time Source Destination Protocol Info
11 0.013488 192.168.17.2 192.168.17.1 TCP 33121 > www [FIN, ACK] Seq=110 Ack=470 Win=6912 Len=0 TSV=17286434 TSER=407518

Frame 11 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:11:25:42:7c:06, Dst: 00:12:ca:01:00:03
Internet Protocol, Src Addr: 192.168.17.2 (192.168.17.2), Dst Addr: 192.168.17.1 (192.168.17.1)
Transmission Control Protocol, Src Port: 33123 (33121), Dst Port: www (80), Seq: 110, Ack: 470, Len: 0

No. Time Source Destination Protocol Info
12 0.013850 192.168.17.1 192.168.17.2 TCP www > 33121 [ACK] Seq=470 Ack=111 Win=5792 Len=0 TSV=407518 TSER=17286434

Frame 12 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:12:ca:01:00:03, Dst: 00:11:25:42:7c:06
Internet Protocol, Src Addr: 192.168.17.1 (192.168.17.1), Dst Addr: 192.168.17.2 (192.168.17.2)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33121 (33121), Seq: 470, Ack: 111, Len: 0





Og nu output fra det, der fejler: wget http://10.0.0.1/index.html:

No. Time Source Destination Protocol Info
1 0.000000 10.0.0.44 10.0.0.1 TCP 33126 > www [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=17639641 TSER=0 WS=2

Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 0, Ack: 0, Len: 0

No. Time Source Destination Protocol Info
2 0.002959 10.0.0.1 10.0.0.44 TCP www > 33126 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=442799 TSER=17639641 WS=0

Frame 2 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:0f:cb:c3:58:20, Dst: 00:0c:f6:11:87:31
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.44 (10.0.0.44)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33126 (33126), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
3 0.003014 10.0.0.44 10.0.0.1 TCP 33126 > www [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=17639644 TSER=442799

Frame 3 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
4 0.004287 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 4 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
5 0.006700 10.0.0.1 10.0.0.44 TCP www > 33126 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=442800 TSER=17639641 WS=0

Frame 5 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:0f:cb:c3:58:20, Dst: 00:0c:f6:11:87:31
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.44 (10.0.0.44)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33126 (33126), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
6 0.006723 10.0.0.44 10.0.0.1 TCP 33126 > www [ACK] Seq=106 Ack=1 Win=5840 Len=0 TSV=17639647 TSER=442800 SLE=0 SRE=1

Frame 6 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 106, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
7 0.008200 10.0.0.1 10.0.0.44 TCP www > 33126 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=442800 TSER=17639641 WS=0

Frame 7 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:0f:cb:c3:58:20, Dst: 00:0c:f6:11:87:31
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.44 (10.0.0.44)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33126 (33126), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
8 0.008222 10.0.0.44 10.0.0.1 TCP 33126 > www [ACK] Seq=106 Ack=1 Win=5840 Len=0 TSV=17639649 TSER=442800 SLE=0 SRE=1

Frame 8 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 106, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
9 0.010951 10.0.0.1 10.0.0.44 TCP www > 33126 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=442800 TSER=17639641 WS=0

Frame 9 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:0f:cb:c3:58:20, Dst: 00:0c:f6:11:87:31
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.44 (10.0.0.44)
Transmission Control Protocol, Src Port: www (80), Dst Port: 33126 (33126), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
10 0.010967 10.0.0.44 10.0.0.1 TCP 33126 > www [ACK] Seq=106 Ack=1 Win=5840 Len=0 TSV=17639652 TSER=442800 SLE=0 SRE=1

Frame 10 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 106, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
11 0.206730 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 11 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
12 0.612687 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 12 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
13 1.424569 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 13 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
14 3.048337 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 14 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
15 6.295826 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 15 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
16 12.790837 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 16 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
17 25.780863 10.0.0.44 10.0.0.1 HTTP GET /index.html HTTP/1.0

Frame 17 (171 bytes on wire, 171 bytes captured)
Ethernet II, Src: aa:aa:03:00:00:00, Dst: 00:0f:cb:c3:58:20
Internet Protocol, Src Addr: 10.0.0.44 (10.0.0.44), Dst Addr: 10.0.0.1 (10.0.0.1)
Transmission Control Protocol, Src Port: 33126 (33126), Dst Port: www (80), Seq: 1, Ack: 1, Len: 105
Hypertext Transfer Protocol



--
Stephan Henningsen

Kasper Dupont (04-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 04-06-05 21:02

Stephan Henningsen wrote:
>
> Ethereal ser super fedt ud. Jeg har nogle output her, som du måske kan
> hjælpe med at tolke på; jeg er ikke så skarp i tcp =)

Starten ser jo god nok ud. Klienten sender en SYN
pakke, serveren svarer med en SYN ACK pakke, og
klienten afslutter handshake med en ACK pakke.

Men serveren modtager tilsyneladende aldrig ACK
pakken (eller også forstår serveren ikke ACK pakken).
I hvert fald bliver serveren ved med at sende SYN
ACK pakker.

Så nu foreslår jeg, at du kører tcpdump på serveren
(hvis jeg forstår dig ret er det ARM boksen, der er
server). Det eneste du i første omgang skal kigge
efter er, om ACK pakkerne når frem.

Hvis du kører tcpdump over en netforbindelse skal
du passe på, at den ikke holder øje den trafik,
den selv genererer.

Du kan få tcpdump til at holde øje med et enkelt
interface ved at taste f.eks.:

tcpdump -ni wlan0

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Stephan Henningsen (06-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 06-06-05 09:28

Kasper Dupont wrote:
> Stephan Henningsen wrote:
>
> Starten ser jo god nok ud. Klienten sender en SYN
> pakke, serveren svarer med en SYN ACK pakke, og
> klienten afslutter handshake med en ACK pakke.
>
> Men serveren modtager tilsyneladende aldrig ACK
> pakken (eller også forstår serveren ikke ACK pakken).
> I hvert fald bliver serveren ved med at sende SYN
> ACK pakker.
>
> Så nu foreslår jeg, at du kører tcpdump på serveren
> (hvis jeg forstår dig ret er det ARM boksen, der er
> server). Det eneste du i første omgang skal kigge
> efter er, om ACK pakkerne når frem.

tcpdump på serverens (yes, ARM'ens) wlan0-device mens wget kører på klienten.
Jeg har verificeret at begge de MAC-adresse, der på et tidspunkt forespørges
og får at vide, passer; så det er ikke dér, problemet ligget. Nederst i loggen
ses, at der sendes nogle ARP-pakker umiddlebart efter, at jeg har trykket ^C på
klienten. Efter at have forsøgt nogle gange, kan jeg se, at det ikke er denne
terminering, der udløser ARP-snakken -- bare lige, så du ved det =). ARP-snakken
synes at komme ret spontant..

Jeg har kigget lidt i man-siden til tcpdump. For mig ser det ud som om,
at serveren modtager SYN, og svarer med en SYN ACK, som aldrig når frem;
fordi klienten bliver ved med at sende SYN. Men jeg kan nemt tage fejl..



root@au1901000039# tcpdump -n -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 68 bytes

20:48:33.437923 IP 10.0.0.44.33402 > 10.0.0.1.80: S 1802960693:1802960693(0) win 5840 <mss 1460,sackOK,timestamp 260369060[|tcp]>
20:48:33.438380 IP 10.0.0.1.80 > 10.0.0.44.33402: S 2942051466:2942051466(0) ack 1802960694 win 5792 <mss 1460,sackOK,timestamp 200523[|tcp]>
20:48:33.441981 IP 10.0.0.44.33402 > 10.0.0.1.80: S 1802960693:1802960693(0) win 5840 <mss 1460,sackOK,timestamp 260369060[|tcp]>
20:48:33.442347 IP 10.0.0.1.80 > 10.0.0.44.33402: S 2942051466:2942051466(0) ack 1802960694 win 5792 <mss 1460,sackOK,timestamp 200524[|tcp]>
20:48:33.443080 IP 10.0.0.44.33402 > 10.0.0.1.80: S 1802960693:1802960693(0) win 5840 <mss 1460,sackOK,timestamp 260369060[|tcp]>
20:48:33.443476 IP 10.0.0.1.80 > 10.0.0.44.33402: S 2942051466:2942051466(0) ack 1802960694 win 5792 <mss 1460,sackOK,timestamp 200524[|tcp]>
20:48:33.445979 IP 10.0.0.44.33402 > 10.0.0.1.80: S 1802960693:1802960693(0) win 5840 <mss 1460,sackOK,timestamp 260369060[|tcp]>
20:48:33.446314 IP 10.0.0.1.80 > 10.0.0.44.33402: S 2942051466:2942051466(0) ack 1802960694 win 5792 <mss 1460,sackOK,timestamp 200524[|tcp]>
20:48:33.447993 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369063 200523>
20:48:33.452021 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369063 200523>
20:48:33.452967 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369063 200523>
20:48:33.454981 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369063 200523>
20:48:33.457971 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369064 200523>
20:48:33.460931 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369064 200523>
20:48:33.463067 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369064 200523>
20:48:33.465997 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369064 200523>
20:48:33.468987 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369067 200524,nop,nop,[|tcp]>
20:48:33.471947 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369067 200524,nop,nop,[|tcp]>
20:48:33.472985 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369067 200524,nop,nop,[|tcp]>
20:48:33.474938 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369067 200524,nop,nop,[|tcp]>
20:48:33.476982 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369068 200524,nop,nop,[|tcp]>
20:48:33.479942 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369068 200524,nop,nop,[|tcp]>
20:48:33.481071 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369068 200524,nop,nop,[|tcp]>
20:48:33.483970 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369068 200524,nop,nop,[|tcp]>
20:48:33.485954 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369071 200524,nop,nop,[|tcp]>
20:48:33.487998 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369071 200524,nop,nop,[|tcp]>
20:48:33.489982 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369071 200524,nop,nop,[|tcp]>
20:48:33.491996 IP 10.0.0.44.33402 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 260369071 200524,nop,nop,[|tcp]>
20:48:33.644694 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369267 200524>
20:48:33.647776 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369267 200524>
20:48:33.649790 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369267 200524>
20:48:33.652781 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369267 200524>
20:48:34.050303 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369673 200524>
20:48:34.053354 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369673 200524>
20:48:34.056314 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369673 200524>
20:48:34.058298 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260369673 200524>
20:48:34.862283 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260370485 200524>
20:48:34.865304 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260370485 200524>
20:48:34.867379 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260370485 200524>
20:48:34.870339 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260370485 200524>
20:48:36.486396 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260372109 200524>
20:48:36.489447 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260372109 200524>
20:48:36.491431 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260372109 200524>
20:48:36.495428 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260372109 200524>
20:48:39.732546 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260375357 200524>
20:48:39.736574 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260375357 200524>
20:48:39.738588 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260375357 200524>
20:48:39.741579 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260375357 200524>
20:48:46.226892 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260381853 200524>
20:48:46.230920 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260381853 200524>
20:48:46.232903 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260381853 200524>
20:48:46.235924 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260381853 200524>
20:48:59.216560 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260394845 200524>
20:48:59.219581 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260394845 200524>
20:48:59.221625 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260394845 200524>
20:48:59.224616 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260394845 200524>
20:49:04.214682 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:04.214865 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:04.218741 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:04.218924 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:04.220694 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:04.220877 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:04.222677 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:04.222860 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:25.194950 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260420829 200524>
20:49:25.197971 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260420829 200524>
20:49:25.200015 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260420829 200524>
20:49:25.202975 IP 10.0.0.44.33402 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 260420829 200524>

# wget afbrydes med ^C på klienten.

20:49:30.194018 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:30.194232 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:30.197070 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:30.197314 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:30.198107 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:30.198382 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:30.200060 arp who-has 10.0.0.1 tell 10.0.0.44
20:49:30.200213 arp reply 10.0.0.1 is-at 00:0f:cb:c3:58:20
20:49:30.214067 IP 10.0.0.44.33402 > 10.0.0.1.80: F 106:106(0) ack 1 win 1460 <nop,nop,timestamp 260425849 200524>
20:49:30.214647 IP 10.0.0.1.80 > 10.0.0.44.33402: . ack 1 win 5792 <nop,nop,timestamp 206196 260369063,nop,nop,[|tcp]>
20:49:30.218064 IP 10.0.0.44.33402 > 10.0.0.1.80: F 106:106(0) ack 1 win 1460 <nop,nop,timestamp 260425849 200524>
20:49:30.219132 IP 10.0.0.1.80 > 10.0.0.44.33402: . ack 1 win 5792 <nop,nop,timestamp 206196 260369063,nop,nop,[|tcp]>
20:49:30.219071 IP 10.0.0.44.33402 > 10.0.0.1.80: F 106:106(0) ack 1 win 1460 <nop,nop,timestamp 260425849 200524>
20:49:30.220078 IP 10.0.0.1.80 > 10.0.0.44.33402: . ack 1 win 5792 <nop,nop,timestamp 206196 260369063,nop,nop,[|tcp]>
20:49:30.222062 IP 10.0.0.44.33402 > 10.0.0.1.80: F 106:106(0) ack 1 win 1460 <nop,nop,timestamp 260425849 200524>
20:49:30.222694 IP 10.0.0.1.80 > 10.0.0.44.33402: . ack 1 win 5792 <nop,nop,timestamp 206196 260369063,nop,nop,[|tcp]>
20:49:35.217194 arp who-has 10.0.0.44 tell 10.0.0.1
20:49:35.219177 arp reply 10.0.0.44 is-at 00:0c:f6:11:87:31
20:49:35.222168 arp reply 10.0.0.44 is-at 00:0c:f6:11:87:31
20:49:35.224151 arp reply 10.0.0.44 is-at 00:0c:f6:11:87:31
20:49:35.225158 arp reply 10.0.0.44 is-at 00:0c:f6:11:87:31

# tcpdump afbrydes med ^C.


--
Stephan Henningsen

Kasper Dupont (09-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 09-06-05 15:29

Stephan Henningsen wrote:
>
> Nederst i loggen
> ses, at der sendes nogle ARP-pakker umiddlebart efter, at jeg har trykket ^C på
> klienten. Efter at have forsøgt nogle gange, kan jeg se, at det ikke er denne
> terminering, der udløser ARP-snakken -- bare lige, så du ved det =). ARP-snakken
> synes at komme ret spontant..

Jeg tror nu alligevel, der er en eller anden form for
forbindelse. Men jeg tror ikke det er der, vi skal
lede efter årsagen til problemet.

Prøv evt. at checke outputtet af en "arp -n" kommando
på hver side.

>
> Jeg har kigget lidt i man-siden til tcpdump. For mig ser det ud som om,
> at serveren modtager SYN, og svarer med en SYN ACK, som aldrig når frem;
> fordi klienten bliver ved med at sende SYN. Men jeg kan nemt tage fejl..
>
> root@au1901000039# tcpdump -n -i wlan0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 68 bytes
>
> [...]

Sært, det ser ud som om hver eneste pakke fra klienten
til serveren kopieres præcist fire gange. Det burde gå
ud over performance, men det burde ikke helt forhindre
TCP forbindelsen i at virke.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Stephan Henningsen (06-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 06-06-05 09:59

Når jeg ping'er 10.0.0.1, så får jeg en masse DUPs. Kan det være det samme, der sker,
når jeg starter en http-forbindelse? Altså at der kommer en bunke requests og replies som
webserveren ikke kan hitte rede i? wget og firefox opfører sig ens, og webserveren er en
simpel httpd, så måske er den ikke så robust overfor den slags støj? Måske bør den ikke være det...

Jeg har lavet to dumps af wget op mod 10.0.0.1 (den mystiske wlan0) og 192.168.17.1 (fungerende eth0).
Og jeg synes, at de ligner hinanden i begyndelsen, bortset fra en masse ekko. Kunne ekkoerne muligvis
resultere i mudder?


sth@speedball$ wget http://192.168.17.1/index.html
-->
root@au1901000039# tcpdump -n -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
21:23:23.408211 IP 192.168.17.2.33529 > 192.168.17.1.80: S 3996008150:3996008150(0) win 5840 <mss 1460,sackOK,timestamp 262459503[|tcp]>
21:23:23.408485 IP 192.168.17.1.80 > 192.168.17.2.33529: S 773937561:773937561(0) ack 3996008151 win 5792 <mss 1460,sackOK,timestamp 409332[|tcp]>
21:23:23.408699 IP 192.168.17.2.33529 > 192.168.17.1.80: . ack 1 win 1460 <nop,nop,timestamp 262459503 409332>
21:23:23.412300 IP 192.168.17.2.33529 > 192.168.17.1.80: P 1:110(109) ack 1 win 1460 <nop,nop,timestamp 262459507 409332>
21:23:23.413063 IP 192.168.17.1.80 > 192.168.17.2.33529: . ack 110 win 5792 <nop,nop,timestamp 409333 262459507>
21:23:23.420997 IP 192.168.17.1.80 > 192.168.17.2.33529: P 1:167(166) ack 110 win 5792 <nop,nop,timestamp 409333 262459507>
21:23:23.421149 IP 192.168.17.2.33529 > 192.168.17.1.80: . ack 167 win 1460 <nop,nop,timestamp 262459516 409333>
21:23:23.421515 IP 192.168.17.1.80 > 192.168.17.2.33529: P 167:469(302) ack 110 win 5792 <nop,nop,timestamp 409334 262459516>
21:23:23.421668 IP 192.168.17.2.33529 > 192.168.17.1.80: . ack 469 win 1728 <nop,nop,timestamp 262459516 409334>
21:23:23.422065 IP 192.168.17.1.80 > 192.168.17.2.33529: F 469:469(0) ack 110 win 5792 <nop,nop,timestamp 409334 262459516>
21:23:23.437078 IP 192.168.17.2.33529 > 192.168.17.1.80: F 110:110(0) ack 470 win 1728 <nop,nop,timestamp 262459531 409334>
21:23:23.437292 IP 192.168.17.1.80 > 192.168.17.2.33529: . ack 111 win 5792 <nop,nop,timestamp 409335 262459531>







sth@speedball$ wget http://10.0.0.1/index.html
-->
root@au1901000039# tcpdump -n -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 68 bytes
21:21:53.268835 IP 10.0.0.44.33525 > 10.0.0.1.80: S 3907742917:3907742917(0) win 5840 <mss 1460,sackOK,timestamp 262369338[|tcp]>
21:21:53.269354 IP 10.0.0.1.80 > 10.0.0.44.33525: S 666803375:666803375(0) ack 3907742918 win 5792 <mss 1460,sackOK,timestamp 400326[|tcp]>
21:21:53.271795 IP 10.0.0.44.33525 > 10.0.0.1.80: S 3907742917:3907742917(0) win 5840 <mss 1460,sackOK,timestamp 262369338[|tcp]>
21:21:53.272131 IP 10.0.0.1.80 > 10.0.0.44.33525: S 666803375:666803375(0) ack 3907742918 win 5792 <mss 1460,sackOK,timestamp 400327[|tcp]>
21:21:53.273778 IP 10.0.0.44.33525 > 10.0.0.1.80: S 3907742917:3907742917(0) win 5840 <mss 1460,sackOK,timestamp 262369338[|tcp]>
21:21:53.274145 IP 10.0.0.1.80 > 10.0.0.44.33525: S 666803375:666803375(0) ack 3907742918 win 5792 <mss 1460,sackOK,timestamp 400327[|tcp]>
21:21:53.276769 IP 10.0.0.44.33525 > 10.0.0.1.80: S 3907742917:3907742917(0) win 5840 <mss 1460,sackOK,timestamp 262369338[|tcp]>
21:21:53.277135 IP 10.0.0.1.80 > 10.0.0.44.33525: S 666803375:666803375(0) ack 3907742918 win 5792 <mss 1460,sackOK,timestamp 400327[|tcp]>
21:21:53.278783 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369344 400326>
21:21:53.281804 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369344 400326>
21:21:53.283818 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369344 400326>
21:21:53.285832 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369344 400326>
21:21:53.287815 IP 10.0.0.44.33525 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 262369346 400326>
21:21:53.291813 IP 10.0.0.44.33525 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 262369346 400326>
21:21:53.293766 IP 10.0.0.44.33525 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 262369346 400326>
21:21:53.296787 IP 10.0.0.44.33525 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 262369346 400326>
21:21:53.298740 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369348 400327,nop,nop,[|tcp]>
21:21:53.301791 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369348 400327,nop,nop,[|tcp]>
21:21:53.302860 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369348 400327,nop,nop,[|tcp]>
21:21:53.304782 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369348 400327,nop,nop,[|tcp]>
21:21:53.306765 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369349 400327,nop,nop,[|tcp]>
21:21:53.309725 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369349 400327,nop,nop,[|tcp]>
21:21:53.310855 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369349 400327,nop,nop,[|tcp]>
21:21:53.312899 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369349 400327,nop,nop,[|tcp]>
21:21:53.314791 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369352 400327,nop,nop,[|tcp]>
21:21:53.318727 IP 10.0.0.44.33525 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 262369352 400327,nop,nop,[|tcp]


--
Stephan Henningsen

Stephan Henningsen (06-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 06-06-05 11:54

Ping virker (sådan da) men traceroute virker ikke. Hvad kan der være galt?


sth@speedball$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.97 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=6.96 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=8.70 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=10.0 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=2.47 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=6.96 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=8.58 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=11.2 ms (DUP!)

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.477/7.247/11.215/2.936 ms
sth@speedball$ traceroute -n 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
...



--
Stephan Henningsen

Kasper Dupont (08-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 08-06-05 07:27

Stephan Henningsen wrote:
>
> Ping virker (sådan da) men traceroute virker ikke. Hvad kan der være galt?
>
> sth@speedball$ ping 10.0.0.1
> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.97 ms
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=6.96 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=8.70 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=10.0 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=2.47 ms
> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=6.96 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=8.58 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=11.2 ms (DUP!)

Du er ikke tilfældigvis kommet til at sætte flere maskiner
op med samme IP adresse? Check også lige om MAC adresserne
er unikke, og alle maskiner på netværket har sat deres
broadcast adresse rigtigt.

>
> --- 10.0.0.1 ping statistics ---
> 2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 2.477/7.247/11.215/2.936 ms
> sth@speedball$ traceroute -n 10.0.0.1
> traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets
> 1 * * *
> 2 * * *

Som default bruger traceroute udp pakker. Hvis du giver en
-I option bruger den icmp echo request ligesom ping. Begge
dele burde selvfølgelig virke.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Stephan Henningsen (09-06-2005)
Kommentar
Fra : Stephan Henningsen


Dato : 09-06-05 11:06

Kasper Dupont wrote:
>
> Du er ikke tilfældigvis kommet til at sætte flere maskiner
> op med samme IP adresse? Check også lige om MAC adresserne
> er unikke, og alle maskiner på netværket har sat deres
> broadcast adresse rigtigt.

ifconfig viser forskellige MAC-adresser på alle interfaces.

Jeg har kun de to IP-adressre i sving: 10.0.0.44 på klienten, 10.0.0.1 på serveren.
Slukker jeg serveren, kan jeg ikke pinge den, så det må være beviset.

Broadcast-adressen har jeg ikke 100% styr på, hvordan skal se ud,
men en ser stadigvæk ud, som jeg har postet før:


På min klieten:

sth@speedball$ ifconfig -a
ath0 Link encap:Ethernet HWaddr 00:05:4E:4C:F2:80
inet addr:192.168.4.44 Bcast:192.168.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1047840 errors:859272 dropped:0 overruns:0 frame:859272
TX packets:1321601 errors:123 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:199
RX bytes:336097544 (320.5 MiB) TX bytes:1578182415 (1.4 GiB)
Interrupt:11 Memory:e09a0000-e09b0000

eth0 Link encap:Ethernet HWaddr 00:11:25:42:7C:06
inet addr:192.168.17.2 Bcast:192.168.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26647 errors:0 dropped:0 overruns:0 frame:0
TX packets:29616 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1979418 (1.8 MiB) TX bytes:12315048 (11.7 MiB)
Base address:0x8000 Memory:c0220000-c0240000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:239 errors:0 dropped:0 overruns:0 frame:0
TX packets:239 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:47416 (46.3 KiB) TX bytes:47416 (46.3 KiB)

wlan0 Link encap:Ethernet HWaddr 00:0C:F6:11:87:31
inet addr:10.0.0.44 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:7146 errors:0 dropped:0 overruns:0 frame:0
TX packets:4592 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:573352 (559.9 KiB) TX bytes:529817 (517.3 KiB)



Og på min embeddede server:

root@au1901000039# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:12:CA:01:00:03
inet addr:192.168.17.1 Bcast:192.168.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1342 errors:0 dropped:0 overruns:0 frame:0
TX packets:552 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:190239 (185.7 KiB) TX bytes:49437 (48.2 KiB)
Interrupt:24 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ppp0 Link encap:Point-Point Protocol
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr 00:0F:CB:C3:58:20
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1224 errors:0 dropped:0 overruns:0 frame:0
TX packets:351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:190875 (186.4 KiB) TX bytes:18384 (17.9 KiB)


> Som default bruger traceroute udp pakker. Hvis du giver en
> -I option bruger den icmp echo request ligesom ping. Begge
> dele burde selvfølgelig virke.

Det her virker sjovt nok:

   sth@speedball$ traceroute -I 10.0.0.1
   traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets
    1 10.0.0.1 (10.0.0.1) 1.988 ms 2.207 ms 2.565 ms

Og i dag er der ingen DUPs:

   sth@speedball$ ping 10.0.0.1
   PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
   64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.41 ms
   64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.83 ms
   64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=2.32 ms

Men wget virker stadig ikke:

   sth@speedball$ wget http://10.0.0.1/index.html
   --12:00:10-- http://10.0.0.1/index.html
    => `index.html'
   Connecting to 10.0.0.1:80... connected.
   HTTP request sent, awaiting response...

--
Stephan Henningsen

Kasper Dupont (09-06-2005)
Kommentar
Fra : Kasper Dupont


Dato : 09-06-05 15:18

Stephan Henningsen wrote:
>
> Broadcast-adressen har jeg ikke 100% styr på, hvordan skal se ud,
> men en ser stadigvæk ud, som jeg har postet før:

De ser fornuftige nok ud. Der er i hvert fald ikke nogen
af dem, jeg ville forvente problemer med. (Jeg har bare
tidligere set sære problemer forårsaget af en forkert
broadcast adresse. Det er ikke godt hvis man har en
broadcast adresse, der matcher en af de maskiner, der
skal kommunikere).

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408929
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste