Vreemd gedrag bij verbinden met www.itu.int

Pagina: 1
Acties:
  • 149 views sinds 30-01-2008
  • Reageer

  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Enkele dagen geleden merkte ik dat mijn pc (Debian unstable, standaard ne2k-netwerkkaart met winbondchip, linux 2.6.8) nauwelijks verbinding kon maken met www.itu.int en ftp3.itu.int. In eerste instantie nam ik aan dat de site van de ITU gewoon traag was, maar anderen blijken er met zeer goede snelheden van te kunnen downloaden. De feiten:

• Van mijn pc naar ITU krijg ik wel verbinding, maar ontzettend traag
• Van mijn pc naar andere sites heb ik een uitstekende verbinding
• Andere pc's, zowel binnen het netwerk hier thuis als daarbuiten, kunnen zonder problemen de ITU-site bereiken en op volle snelheid (1MB/s of meer) downloaden.
• Mijn iptables-rules bevatten niets dat ook maar in de verte aan de ITU-servers gerelateerd kan zijn.

Een dump die ik met ethereal heb gemaakt ziet er uit als onderstaande - ik zie geen probleem:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
GET /av-arch/avc-site/2001-2004/0305_Gen/h323V5consented.zip HTTP/1.0 
User-Agent: Wget/1.9.1 
Host: ftp3.itu.int 
Accept: */* 
Connection: Keep-Alive 
 
HTTP/1.1 200 OK 
Date: Mon, 10 Jan 2005 15:41:05 GMT 
Server: Apache/1.3.26 (Unix) PHP/4.0.6 
Last-Modified: Fri, 13 Jun 2003 05:16:20 GMT 
ETag: "4cc4-1b734c-3ee95e24" 
Accept-Ranges: bytes 
Content-Length: 1798988 
Keep-Alive: timeout=15, max=100 
Connection: Keep-Alive 
Content-Type: application/zip 
 
PK.........f..y....r....A.....[binary data van het juiste bestand]

Het verschijnsel doet zich voor met zowel wget als willekeurige browsers, dus op dat niveau lijkt het niet te liggen. Als ik remote inlog op een andere machine dan gaat alles gewoon zoals het hoort. Ik kan de site niet pingen, maar dat kan ook niet vanaf andere hosts en is dus waarschijnlijk dichtgezet bij de ITU.

Als ik kijk hoe het verkeer binnendruppelt dan ziet dat er zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
No.     Time        Source                Destination           Protocol Info
     11 5.110484    localhost.localdomain ftp3.itu.ch           TCP      37035 > www [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=672194583 TSER=0 WS=7
     12 5.149234    ftp3.itu.ch           localhost.localdomain TCP      www > 37035 [SYN, ACK] Seq=0 Ack=1 Win=33580 Len=0 MSS=1460 WS=0
     13 5.149375    localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=1 Ack=1 Win=5888 Len=0
     14 5.150380    localhost.localdomain ftp3.itu.ch           HTTP     GET /av-arch/avc-site/2001-2004/0305_Gen/h323V5consented.zip HTTP/1.0
     15 5.205067    ftp3.itu.ch           localhost.localdomain HTTP     HTTP/1.1 200 OK (application/zip)
     16 5.205224    localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=1461 Win=8832 Len=0
     17 6.867194    ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     18 6.867323    localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=2921 Win=11776 Len=0
     19 10.455959   ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     20 10.456101   localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=4381 Win=14720 Len=0
     35 16.726689   ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     36 16.726819   localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=5841 Win=17536 Len=0
     54 29.279308   ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     55 29.279437   localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=7301 Win=20480 Len=0
     62 53.486642   ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     63 53.486775   localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=8761 Win=23424 Len=0
     95 101.902702  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
     96 101.902834  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=10221 Win=26368 Len=0
    134 166.508725  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
    135 166.508858  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=11681 Win=29312 Len=0
    161 230.638305  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
    162 230.638438  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=13141 Win=32128 Len=0
    222 295.190522  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
    223 295.190654  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=14601 Win=35072 Len=0
    265 359.839198  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
    266 359.839342  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=16061 Win=38016 Len=0
    292 424.296757  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
    293 424.296943  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=17521 Win=40960 Len=0
   6290 488.864036  ftp3.itu.ch           localhost.localdomain HTTP     Continuation
   6291 488.864166  localhost.localdomain ftp3.itu.ch           TCP      37035 > www [ACK] Seq=155 Ack=18981 Win=43904 Len=0

Let erop dat er de eerste paar seconden nog enigszins regelmatig packets binnenkomen, maar dat dat daarna steeds trager gaat en zich uiteindelijk stabiliseert op één packet per 65 seconden. Mijn pc stuurt zonder problemen snel een ACK. Aan de sequence nummers van de TCP-header zie ik ook niet veel fouts.

Op dit moment kan ik niet echt meer verzinnen waar het realistisch nog aan zou kunnen liggen:
• als het aan mijn driver, netwerkkaart of netwerkkabel lag dan zou ik het probleem ook op andere sites tegen moeten komen.
• als het aan de ITU-servers ligt dan zouden anderen er ook last van moeten hebben.
• als het de inrichting van ons netwerk hier thuis ligt dan zouden andere pc's hier binnen het netwerk er ook last van moeten hebben.

Zijn er nog mensen met lumineuze ideeën waar dit soort netwerkproblemen door veroorzaakt kunnen worden?

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 14:52
dingen als MTU en ECN? Sommige routers kunnen daar behoorlijk van over de zeik gaan. Zo heb ik meegemaakt dat het hele @home netwerk een hele IP reeks niet kon bereiken vanwege dat soort grapjes. Ik vraag me af of die het ooit hebben opgelost, want ze snapten mijn melding niet helemaal en gingen het bij de 2e melding doorsturen naar de technicus :P

  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Ik heb geen ECN aanstaan (en analyse van de IP-headers laat zien dat het ook niet gebruikt wordt, door geen van beide partijen) en als het ergens op het pad lag tussen mijn netwerk en de ITU-servers dan zouden andere pc's in het netwerk hier er ook last van moeten hebben. Ik heb met traceroute/mtr al gecontroleerd dat die dezelfde route volgen en dat doen ze, zonder daarbij problemen te ondervinden.

Voor de MTU lijkt me hetzelfde te gelden. Ik zie dat mijn ethernetpackets 1514 bytes groot zijn (met headers, zonder CRC) en dat is een normale waarde. Als er ergens op een later punt kleinere packets vereist zouden zijn dan zouden andere hosts er ook last van moeten hebben, en dat is dus niet zo. Ik zie dus ook niet hoe ik daar iets zou kunnen doen om het te verhelpen, helaas.

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.


  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Heeft er iemand enig idee? Ik heb nog altijd geen flauw idee waar ik het moet zoeken en dat irriteert me mateloos :).

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.


  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Nog een laatste schop voor dit topic definitief naar de diepte zakt: is er iemand van de honderden mensen die hier in NOS lezen die een idee heeft waar het probleem zou kunnen zitten en eventueel hoe ik een oplossing kan implementeren?

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.


  • Gondor
  • Registratie: September 2003
  • Laatst online: 10:17
Ik heb geen idee of het wat zal op leveren maar probeer eens een traceroute en tracepath naar www.itu.int

Ik heb geen probleem met die site . Maar tracepath lukt niet traceroute ook niet. Alle twee gaan tot hop nummer 11, daarna geen reply.

Wat ik zie is dat www-main.itu.ch hetzelfde site is.
Probeer www-main.itu.ch eens, misschien gaat het zo wel goed.

En, bij mij staat mtu op 1500.

"Peace cannot be kept by force. It can only be achieved by understanding"-Albert Einstein-


  • serkoon
  • Registratie: April 2000
  • Niet online

serkoon

mekker.

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

?

  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Gondor schreef op donderdag 13 januari 2005 @ 20:12:
Ik heb geen idee of het wat zal op leveren maar probeer eens een traceroute en tracepath naar www.itu.int

Ik heb geen probleem met die site . Maar tracepath lukt niet traceroute ook niet. Alle twee gaan tot hop nummer 11, daarna geen reply.

Wat ik zie is dat www-main.itu.ch hetzelfde site is.
Probeer www-main.itu.ch eens, misschien gaat het zo wel goed.

En, bij mij staat mtu op 1500.
Een traceroute had ik al geprobeerd - die loopt inderdaad vlak voor het einddoel dood, waarschijnlijk omdat de servers van de ITU ingesteld zijn om geen replies te geven op de UDP- en ICMP-packets die tools als ping en traceroute gebruiken.
serkoon schreef op donderdag 13 januari 2005 @ 20:15:
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

?
Dat werkt! Ik had niet verwacht dat ik nog een oplossing zou vinden, bedankt :). Nu nog uitzoeken waarom die site niet met variabele windows om kan gaan - dat zit toch al sinds jaar en dag in de tcp-standaard? - maar in ieder geval kan ik er nu bij :).

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.


  • serkoon
  • Registratie: April 2000
  • Niet online

serkoon

mekker.

Nou, het valt nogal tegen... Ik ken in ieder geval 1 site waarbij het bij mij stuk gaat, en dat is een FreeBSD-doos met pf die scrubbing doet.

Misschien dat het in die hoek (alsin: pf/scrub) te zoeken is, maar echt veel zin om het uit te proberen heb ik in ieder geval nog niet gehad ;)

  • odysseus
  • Registratie: Augustus 2000
  • Nu online

odysseus

Debian GNU/Linux Sid

Topicstarter
Nee, het probleem lijkt te liggen bij routers die aan bits zitten die met window scaling te maken hebben terwijl ze daar vanaf moeten blijven. Firewalls kunnen iets dergelijks in principe ook doen, verwacht ik (ben daar wel een verhaal over tegengekomen, geloof ik). Hoewel het probleem bij de router ligt en er in linux niet omheen gewerkt zal worden, is er wel een patch geweest in 2.6.9 die als bijwerking heeft dat het probleem een stuk minder erg is - zie over het probleem hier en over de patch die het deels oplost hier. Het probleem zit dus ergens op een router of firewall tussen hier en de ITU. Overigens is meteen verklaard waarom andere pc's in huis er geen last van hadden: die draaiden linux 2.6.9 of OS X :).

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.

Pagina: 1