Forum » Omrežja in internet » Napaka pri TCP Hanshake-u
Napaka pri TCP Hanshake-u
Voluharr ::
Z AVR (Atmega32) + ENC28J60 poizkušam narediti telnet server.
Na internetu je precej knjižnic TCP/IP za enc28j60 vendar se mi nobena ne zdi uporabna. Vse knjižnice, ki sem jih našel cev paketek prenesejo v interni buffer, ki si ga ustvarijo v RAMu namesto, da bi ga po delih prebirali iz ENCa, res, da bi lahko vzel čip z več RAMa vendar to ni uporabno.
Imam naslednje omrežje:
AVR(10.0.0.180) < -- > SW1(stupid one) < -- > PC(10.0.0.130)
Na PCju imam zagnan WireShark s filtrom za host 10.0.0.180.
ARP in ICMP sem že stestiral in trenutno deluje brez težav.
Sedaj se lotevam TCPja in se ustavi pri Handshake-u.
TCP: (SYN) PC -> AVR OK
3 0.001152000 10.0.0.130 10.0.0.180 TCP 66 26288›23 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
0000 aa aa aa aa aa aa bb bb bb bb bb bb 08 00 45 00
0010 00 34 16 a1 40 00 80 06 ce ed 0a 00 00 82 0a 00 .4..@...........
0020 00 b4 66 b0 00 17 17 51 5d 70 00 00 00 00 80 02 ..f....Q]p......
0030 20 00 5e 58 00 00 02 04 05 b4 01 03 03 02 01 01 .^X............
0040 04 02 ..
TCP: (SYN ACK) AVR -> PC (Tukaj se ustavi)
4 0.002250000 10.0.0.180 10.0.0.130 TCP 60 23›26288 [SYN, ACK] Seq=0 Ack=1 Win=1408 Len=0 MSS=1408
0000 bb bb bb bb bb bb aa aa aa aa aa aa 08 00 45 00
0010 00 2c 00 00 00 00 80 06 04 a0 0a 00 00 b4 0a 00 .,..............
0020 00 82 00 17 66 b0 04 03 02 01 17 51 5d 71 60 12 ....f......Q]q`.
0030 05 80 9c 07 00 00 02 04 05 80 00 00 ............
IPji so pravi, Porti so pravi FLAGi so pravi, ACK = SEQ+1 tako, da ne vem kaj bi lahko bilo narobe.
Problem je namreč v tem, da računalnik namesto, da bi poslal ACK pošlje še enkrat SYN, kar verjetno pomeni neko napako pri sprejemu.
Če kdo ve kaj bi šlo lahko narobe se mu že vnaprej zahvaljujem za odgovor.
Na internetu je precej knjižnic TCP/IP za enc28j60 vendar se mi nobena ne zdi uporabna. Vse knjižnice, ki sem jih našel cev paketek prenesejo v interni buffer, ki si ga ustvarijo v RAMu namesto, da bi ga po delih prebirali iz ENCa, res, da bi lahko vzel čip z več RAMa vendar to ni uporabno.
Imam naslednje omrežje:
AVR(10.0.0.180) < -- > SW1(stupid one) < -- > PC(10.0.0.130)
Na PCju imam zagnan WireShark s filtrom za host 10.0.0.180.
ARP in ICMP sem že stestiral in trenutno deluje brez težav.
Sedaj se lotevam TCPja in se ustavi pri Handshake-u.
TCP: (SYN) PC -> AVR OK
3 0.001152000 10.0.0.130 10.0.0.180 TCP 66 26288›23 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
0000 aa aa aa aa aa aa bb bb bb bb bb bb 08 00 45 00
0010 00 34 16 a1 40 00 80 06 ce ed 0a 00 00 82 0a 00 .4..@...........
0020 00 b4 66 b0 00 17 17 51 5d 70 00 00 00 00 80 02 ..f....Q]p......
0030 20 00 5e 58 00 00 02 04 05 b4 01 03 03 02 01 01 .^X............
0040 04 02 ..
TCP: (SYN ACK) AVR -> PC (Tukaj se ustavi)
4 0.002250000 10.0.0.180 10.0.0.130 TCP 60 23›26288 [SYN, ACK] Seq=0 Ack=1 Win=1408 Len=0 MSS=1408
0000 bb bb bb bb bb bb aa aa aa aa aa aa 08 00 45 00
0010 00 2c 00 00 00 00 80 06 04 a0 0a 00 00 b4 0a 00 .,..............
0020 00 82 00 17 66 b0 04 03 02 01 17 51 5d 71 60 12 ....f......Q]q`.
0030 05 80 9c 07 00 00 02 04 05 80 00 00 ............
IPji so pravi, Porti so pravi FLAGi so pravi, ACK = SEQ+1 tako, da ne vem kaj bi lahko bilo narobe.
Problem je namreč v tem, da računalnik namesto, da bi poslal ACK pošlje še enkrat SYN, kar verjetno pomeni neko napako pri sprejemu.
Če kdo ve kaj bi šlo lahko narobe se mu že vnaprej zahvaljujem za odgovor.
Backup, VPS, kolokacija: https://reavisys.si
AndrejO ::
Voluharr ::
Sem MSS zmanjšal na 1024 in tudi poizkusil sem odstranit vse opcije v TCP headerju.
Še vedno dobim tole namesto ACK:
5 2.991693000 10.0.0.130 10.0.0.180 TCP 66 [TCP Spurious Retransmission] 44961->23 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
Še vedno dobim tole namesto ACK:
5 2.991693000 10.0.0.130 10.0.0.180 TCP 66 [TCP Spurious Retransmission] 44961->23 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
AndrejO ::
Spreminjanje MSS in odstranjevanje TCP opcij ti ne bo nič pomagalo, če ne boš popravil računanja kontrolne vsote v IPv4 glavi. Paket ti je zaradi tega odvržen stran še preden bo koda prišla do tega, da bi "pogledala" TCP glavo.
Voluharr ::
Hvala vsem za odgovore.
Napaka je bila res v kontrolni vsoti IPv4 glave.
Napaka se mi je pripetila, ko sem za IPv4 header pri TCPju uporabil drugo funkcijo za IPheader in pri tem nekaj zakvačkal pri računanju vsote.
Pomagalo bi tudi če bi v WireSharku vklopil preverjanje IPv4 kontrolne vsote.
Napaka je bila res v kontrolni vsoti IPv4 glave.
Napaka se mi je pripetila, ko sem za IPv4 header pri TCPju uporabil drugo funkcijo za IPheader in pri tem nekaj zakvačkal pri računanju vsote.
Pomagalo bi tudi če bi v WireSharku vklopil preverjanje IPv4 kontrolne vsote.
AndrejO ::
BTW, s tcpdump ti običajno precej jasno izpiše niz "[bad tcp cksum 0123!]".
Ne za IP napako ;) Ko si že ravno omenil TCP.
In za IP boš to videl samo, če boš dodal še -v, sicer aplikacija ne bo dovolj čebljava, da te bi opozorila na to napako.
Napaka se mi je pripetila, ko sem za IPv4 header pri TCPju uporabil drugo funkcijo za IPheader in pri tem nekaj zakvačkal pri računanju vsote.
Pomagalo bi tudi če bi v WireSharku vklopil preverjanje IPv4 kontrolne vsote.
Bi bil pripravljen popraviti še eno malenkost, ali te ne briga preveč glede morebitnih "čudnosti", ko/če bo paket potoval skozi kakšen usmerjevalnik?
Zgodovina sprememb…
- spremenil: AndrejO ()
AndrejO ::
Da. Manjkajoča DF zastavica v glavi IP v kombinaciji z vedno enako vrednostjo ID polja (ugibam, da je vedno enaka, ker ima vrednost 0) bo povzročila težave, če bo usmerjevalnik na poti želel paket razdrobiti.
Od tebe je odvisno, če boš začel nastavljati ID ali pa boš nastavil DF. Oboje bo boljše od sedanje variante, kjer se lahko začno dogajati zelo čudne stvari, če se bo kakšen usmerjevalnik na poti odločil, da mora paket razdrobiti. Ker verjetno ne boš implementiral celoten TCP/IP (del z odkrivanjem PMTU ti bo v tem primeru verjetno zagrenil življenje), ti bo verjetno lažje, če boš nastavljal ID in pustil DF ugasnjen.
Od tebe je odvisno, če boš začel nastavljati ID ali pa boš nastavil DF. Oboje bo boljše od sedanje variante, kjer se lahko začno dogajati zelo čudne stvari, če se bo kakšen usmerjevalnik na poti odločil, da mora paket razdrobiti. Ker verjetno ne boš implementiral celoten TCP/IP (del z odkrivanjem PMTU ti bo v tem primeru verjetno zagrenil življenje), ti bo verjetno lažje, če boš nastavljal ID in pustil DF ugasnjen.
Voluharr ::
ID je 0, ker imam začetno vrednost nastavljeno na 0. In ker je to prvi poslan IP paketek je to pač nič. DF sem si tudi že vključil. PMTUD je pa dodan na task listo.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | križanje paprikeOddelek: Loža | 1621 (1402) | Tarzan |
» | nf_conntrack in TIME_WAITOddelek: Pomoč in nasveti | 1075 (640) | jedateruk |
» | VMware Player - DNS server zmešanOddelek: Programska oprema | 5344 (4913) | AndrejO |
» | Testiranje SwitchaOddelek: Strojna oprema | 1960 (1616) | Goldee |
» | Siol optika - problem z web serverjemOddelek: Omrežja in internet | 1378 (1259) | Sumo |