[TCP/HTTP]

[3V3RT]

Ik ben een webserver aan het programmeren in een AVR en nou ben ik al heel ver met de verbinding opzetten maar een dingetje wil niet lukken.

De TCP handshaking (SYN, SYNACK, ACK) wordt netjes voltooid. Daarna verstuurt de PC een HTTP GET packet. Ik ACK deze en stuur daarna mijn data op (HTTP/1.1 200 OK etc.). Dit pakketje wordt alleen niet ge acknowledged en dus niet verwerkt op de pc. Resultaat: geen webpagina.

Nou is mijn vraag: Waaraan moet mijn HTTP/TCP packet bij het versturen van mijn data aan voldoen om geacknowledged te worden? Sequence en ACK nummer staan ook goed. Flags staan ook goed.

(oeps! geen titel, kan een mod dit fixen?)

[ Voor 3% gewijzigd door 3V3RT op 30-03-2010 16:53 ]

[LuckY]

Komt het pakketje wel goed aan? wat geeft de client weer? Wordt het gediscard? klopt de FCS wel?
Gooi er eens een sniffer op de client tegen aan

[3V3RT]

Al mijn bevindingen haal ik uit wireshark
pakketje klopt (volgens mij) ook volledig. tcp checksum is goed.

Ben alleen benieuwd hoe een standaard opbouw van een tcp handshaking met versturen van http data eruit ziet.

[CyBeR]

Heb je een stukje van de pcap log?

[3V3RT]

jazeker.
De two way tcp handshaking gaat goed (Client reageert netjes) en wordt dan vervolgd door een HTTP get packet van de client.
Daarna stuur ik de volgende twee packets terug:

client ip is: 10.1.3.112
server ip is: 169.254.62.58

Acknowledgement op de HTTP GET van de client:

code:

No.     Time        Source                Destination           Protocol Info
      5 0.730389    169.254.62.58         10.1.3.112            TCP      http > isoipsigport-2 [ACK] Seq=1 Ack=395 Win=4080 Len=0

Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff), Dst: CadmusCo_50:a5:b8 (08:00:27:50:a5:b8)
Internet Protocol, Src: 169.254.62.58 (169.254.62.58), Dst: 10.1.3.112 (10.1.3.112)
Transmission Control Protocol, Src Port: http (80), Dst Port: isoipsigport-2 (1107), Seq: 1, Ack: 395, Len: 0
    Source port: http (80)
    Destination port: isoipsigport-2 (1107)
    [Stream index: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 395    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 4080
    Checksum: 0xeedb [correct]
    [SEQ/ACK analysis]

En dan vervolgens mijn HTTP/1.0 200 OK message met tegelijk een FIN om de TCP connectie af te sluiten.
Hier reageert hij dus niet op!:

code:

No.     Time        Source                Destination           Protocol Info
      6 1.441319    169.254.62.58         10.1.3.112            HTTP     HTTP/1.0 200 OK  (text/html)

Frame 6 (111 bytes on wire, 111 bytes captured)
Ethernet II, Src: CadmusCo_50:a5:b9 (08:00:27:50:a5:b9), Dst: CadmusCo_50:a5:b8 (08:00:27:50:a5:b8)
Internet Protocol, Src: 169.254.62.58 (169.254.62.58), Dst: 10.1.3.112 (10.1.3.112)
Transmission Control Protocol, Src Port: http (80), Dst Port: isoipsigport-2 (1107), Seq: 1, Ack: 395, Len: 57
    Source port: http (80)
    Destination port: isoipsigport-2 (1107)
    [Stream index: 0]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 58    (relative sequence number)]
    Acknowledgement number: 395    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 4080
    Checksum: 0x5f95 [correct]
    [SEQ/ACK analysis]
Hypertext Transfer Protocol
    HTTP/1.0 200 OK\r\n
    Content-Type: text/html\r\n
    \r\n
Line-based text data: text/html

[deandb]

Waarom heeft je server een APIPA adres?
Kan je de server geen adres uit dezelfde range geven als je client?
Of staat er een router tussen?

Want als er nu geen router tussen staat, kan er toch geen Layer 3 communicatie tot stand komen? Je server en je client zitten niet in hetzelfde netwerk...

[ Voor 10% gewijzigd door deandb op 31-03-2010 14:16 ]

[3V3RT]

Er zit op dit moment ook geen router tussen, de client heeft een directe link met de de AVR via een switch.

Waarom zou er geen layer 3 communicatie opgezet kunnen worden?

heb het ip adres veranderd naar een ip adres in dezelfde range. Windows XP reageert nog steeds niet op mijn 200 OK http message.

[ Voor 50% gewijzigd door 3V3RT op 31-03-2010 15:27 ]

[3V3RT]

Een webpagina opvragen ziet er als volgt uit:

code:

receive SYN
send SYN,ACK
receive ACK (the connection is now established)
receive ACK with HTTP GET command
send ACK
send FIN,ACK with HTTP data (e.g 200 OK)
receive FIN,ACK <-- Dit packet wordt niet verstuurd!
send ACK

Er gaat dus iets fout met de 2 pakketjes ervoor die niet goed worden geinterpreteerd. maar wat!

[deandb]

3V3RT schreef op woensdag 31 maart 2010 @ 14:49:
Er zit op dit moment ook geen router tussen, de client heeft een directe link met de de AVR via een switch.

Waarom zou er geen layer 3 communicatie opgezet kunnen worden?

heb het ip adres veranderd naar een ip adres in dezelfde range. Windows XP reageert nog steeds niet op mijn 200 OK http message.

Omdat windows alles die niet in hetzelfde netwerk zit, naar de default gateway stuurt.
jou pc zit/zat in het 10.1.3.x netwerk, dan redeneert hij dat hij niets kan bereiken op het 169.254.x.x zonder het te laten routeren, ook al zitten ze direct verbonden met elkaar op dezelfde switch.

Je default gateway zal op zijn beurt in zijn route tabel kijken hoe hij naar het 169.254 netwerk moet, en zal daar geen specifieke route voor hebben, dus gebruikt hij zijn default route. Dus stuurt hij alles naar je ISP, die het 169.254 netwerk ook niet kent...

Ben je zeker dat het je webserver is die ackt? en niet je routertje?

Wat zijn je IP's + subnet masks nu?

[Mijzelf]

Je HTTP 200 OK bericht bevat volgens jouw wireshark dump helemaal geen FIN.

[3V3RT]

klopt, heb ik naderhand toegevoegd. maakt geen verschil.
ip van client is nu 10.1.3.100. subnet mask is nu 255.255.255.0
ip van server is nog steeds 10.1.3.118
Kan het zijn dat ik iets met de option bytes verkeerd doe? of de window size?

[leuk_he]

Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff),

Huh broadcast? Apart, geen idee of dat mag buiten arp resolution.

Maar kun je de pcap file ergens hosten? (zondermeer is windows niet het meest simple doel platform, aangezien in in de tcp stack wat ongedocumenteneerde "security" features lijken te zitten)

[ Voor 34% gewijzigd door leuk_he op 01-04-2010 17:45 ]

[3V3RT]

pcap file: http://cl.ly/alS

zoals je ziet wordt er na de 200 OK geen ACK meer gegeven vanaf de client.

[Verwijderd]

Kan het zijn dat je in #6 je PSH flag bent vergeten te zetten?

[Kees]

3V3RT schreef op dinsdag 06 april 2010 @ 10:13:
pcap file: http://cl.ly/alS

zoals je ziet wordt er na de 200 OK geen ACK meer gegeven vanaf de client.

Omdat jij niet lang genoeg wacht.

Je doet in packet nr 4 een request, met een connection: keep-alive, de server antwoord je met een volledige pagina lijkt het (HTTP 200, wat headers, en dan een lege pagina; iig geen data, en ook geen connection: close header). Je browser sluit de connectie denk ik gewoon niet omdat hij hem openhoud voor eventuele vervolg requests.

Welke server gebruik je, en om eventuele fouten uit te sluiten, kun je ze in eenzelfde subnet zetten?

[3V3RT]

@onnoj: die heb ik vanwege het testen een paar keer wel en niet gebruikt.

@Kees: dat is het juist, de server ben ik. die close connection zou het best eens kunnen zijn. Dat ga ik morgen eens proberen. Aan de andere kant, de connection close hoort bij http en niet bij TCP dus ik zou denken dat de acknowledge wel zou moeten komen. Aan de andere kant, delayed acknowledgements kunnen ook een rol spelen. Ik ga het uitzoeken!

[3V3RT]

Ik heb de connection:close option toegevoegd maar het mocht niet baten. Ook de fin,psh,ack flags varieren maakte niks uit.

Ik heb trouwens de opbouw van de connectie van tuxgraphics.org (http://www.tuxgraphics.or...200611/article06111.shtml)

Op die site staat ook een pcap file met daarin een standaard opvraag van een http pagina. Die heb ik gevolgd en volgens de auteur zou die manier moeten werken. Dus of ik zie iets over het hoofd of het is iets anders!
Of heeft het iets met verplichte http headers te maken?

Misschien handig om te weten: firefox laat zien in de statusbalk: wachten op 10.1.3.118
Dat is dus het ip van de server. Misschien dat het iets met delayed acknowledgements te maken heeft? Dus dat hij pas na minimaal 2 segments een acknowledge stuurt?

[ Voor 19% gewijzigd door 3V3RT op 07-04-2010 13:27 . Reden: stukje over acknowledge toegevoegd ]

[leuk_he]

Als je op frame level naar hjouw pakketten kijkt zie ik vreemde dingen.

-Destination dat braodcast adress?
-Laatste pakket heeft als source opeens een heel ander Mac adress, wellicht stuurt browser het daarheen, maar is dat niet het adres van je PC? (ethernet level, niet tcp level dus)

code:

Ethernet II, Src: CadmusCo_50:a5:b9 (08:00:27:50:a5:b9), Dst: CadmusCo_50:a5:b8 (08:00:27:50:a5:b8)

-In jouw cap ontbreekt het arp pakket, die kan in een eerder sessie al bepaald zijn, echter, gezien het feit dat je een broadcast adress gebruikt vraag ik me af of dat zo de bedoeling is..

[ Voor 10% gewijzigd door leuk_he op 07-04-2010 13:59 ]

[3V3RT]

Klopt, de mac adressen zijn nu allemaal goed. en de ARP berichten worden netjes gereplied met het correcte MAC adres. Ik kwam er inderdaad ook achter dat het laatste pakket een andere source had (kleine hiccup van mijn kant) maar dat heb ik nu correct weten te krijgen.

ik heb voor de volledigheid een laatste dump gemaakt zoals het er nu voor staat (met ARP request/reply erbij)
pcap file: http://cl.ly/5f5

[ Voor 68% gewijzigd door 3V3RT op 08-04-2010 12:20 ]

[3V3RT]

update: Ik heb uitgevonden dat ik de tcp connectie wel netjes kan afsluiten door apart een FIN packet te sturen. De verbinding wordt dan (volgens netstat ) netjes afgesloten.
Als ik dan mijn http packet ertussen prop, dan wordt deze niet geacknowledged door het systeem. De enige acknowledge die van de client terugkomt is de acknowledge op het fin packet. Het aantal bytes van het http packet wordt dus niet geacknowledged. bizar!

[3V3RT]

Na lang zoeken ben ik er achter gekomen. het frame met de http data was goed op een puntje na: het total length field van de ip header telde consequent 2 bytes te veel .

[battler]

De aanhouder wint