Problemen met Linux (debian) router

[4ourty2]

Ik heb een alix PC-engine waar ik debian opgezet heb.
Ik wil hem eerst goed configureren als router en dan later andere functies toevoegen.
Nu heb ik alleen een aantal problemen en ik kan er niks over vinden op de diverse fora noch op google.
De pc engine alix is een mini pc met 3 eth poorten en een amd geode 500 MHz processor.
Ik gebruik poort eth0 als mijn WAN poort.
Met behulp van bridge utils heb ik van eth1 en eth2 een bridge gemaakt.
Ik gebruik DNS masquerade als dhcp server en dns forwarder.
Het probleem is alleen dat als ik een pagina wil bezoeken hij heel traag is met het opbouwen van de verbinding. Zodra de site gevonden is is de throughput wel goed. Ook geeft msn een verbindingsprobleem aan als ik de router er tussen stop (een gele melding bovenin het scherm ik kan dus wel inloggen). Ik had eerst ook een hoge latency maar dat heb ik opgelost door met ethtool autonegotiate uit te zetten. Spraak en webcam verbindingen zijn ook erg traag. Het duurt ook wel een minuut voor dat ik een connectie met de router opbouw van mijn pc. Ik zie dan in de logging dat eth1 (of eth2) dan in learning state gaat. Dit snap ik niet want spanning tree staat uit.

Ik zit dus met de handen in het haar bij wijze van spreken. Is er iemand die een idee heeft om te zorgen dat het net zo vlot gaat als dat ik rechtstreeks aan mijn modem hang.

[4ourty2]

Iemand?

offtopic:
Om 1 of andere reden heb ik altijd problemen waar niemand mee kan helpen

[Sendy]

Ik (en ik denk anderen ook) kan weinig met "hij is heel traag met het opbouwen van de verbinding, zodra de site gevonden is is de throughput wel goed". Kan je misschien met een netwerkscanner zoals Wireshark het verkeer eens scannen om te zien wat er nu precies traag is? Op je router kan je hetzelfde doen met tcpdump (en dat kan je ook weer inlezen in Wireshark). Als je zorgt dat de tijd op beide machines praktisch gelijk staat dan is dat ook handig.

[4ourty2]

Sendy schreef op woensdag 09 juli 2008 @ 16:34:
Ik (en ik denk anderen ook) kan weinig met "hij is heel traag met het opbouwen van de verbinding, zodra de site gevonden is is de throughput wel goed". Kan je misschien met een netwerkscanner zoals Wireshark het verkeer eens scannen om te zien wat er nu precies traag is? Op je router kan je hetzelfde doen met tcpdump (en dat kan je ook weer inlezen in Wireshark). Als je zorgt dat de tijd op beide machines praktisch gelijk staat dan is dat ook handig.

Het rare is dat tweakers gewoon snel is en google heel erg traag.
Ik heb tcpdump en wireshark aangezet en toen heb ik google geopent.
Hieronder de resultaten kan je hier wat mee?
De zwarte blokken zijn gewoon mijn private ip range.


desktop


router


router vervolg

[ Voor 11% gewijzigd door 4ourty2 op 10-07-2008 01:07 ]

[Verwijderd]

gaat downloaden via ftp / http wel snel? Als de throughoutput wel goed is maar het 'vinden van de site' traag, lijkt het me op een DNS probleem te duiden. En anders gaat er qua routing iets mis dat er schijnbaar eerst één moeten 'time-outen' en dat het via de back-up wel goed gaat - denk bijv aan een default-gateway die niet goed staat ingesteld. Post ook eens een traceroute met en zonder nameresolution. Gaat pingen naar ip-adressen wel direct lekker snel? Post ook eens

1. of vanaf je pc de router direct goed kunt benaderen (ping de router).
2. of je vanaf de router het ip-adres van tweakers.net direct kunt pingen.
3. of je vanaf de router het ip-adres van je eigen computer direct kunt pingen.
4. of je vanaf je pc het ip-adres van tweakers.net direct kunt pingen.

Ik vermoed dat er qua routing toch iets niet lekker loopt of dat er DNS problemen zijn (FIREWALL die DNS requests blokt? dat kan ook een timeout veroorzaken). Al die zaken kunnen veroorzaakt worden door een verkeerd geconfigureerde firewall. Zet die ook eens uit (of alles open) om te testen.

[ Voor 90% gewijzigd door Verwijderd op 09-07-2008 21:10 ]

[4ourty2]

Verwijderd schreef op woensdag 09 juli 2008 @ 21:04:
gaat downloaden via ftp / http wel snel? Als de throughoutput wel goed is maar het 'vinden van de site' traag, lijkt het me op een DNS probleem te duiden. En anders gaat er qua routing iets mis dat er schijnbaar eerst één moeten 'time-outen' en dat het via de back-up wel goed gaat - denk bijv aan een default-gateway die niet goed staat ingesteld. Post ook eens een traceroute met en zonder nameresolution. Gaat pingen naar ip-adressen wel direct lekker snel? Post ook eens

1. of vanaf je pc de router direct goed kunt benaderen (ping de router).
2. of je vanaf de router het ip-adres van tweakers.net direct kunt pingen.
3. of je vanaf de router het ip-adres van je eigen computer direct kunt pingen.
4. of je vanaf je pc het ip-adres van tweakers.net direct kunt pingen.

Ik vermoed dat er qua routing toch iets niet lekker loopt of dat er DNS problemen zijn (FIREWALL die DNS requests blokt? dat kan ook een timeout veroorzaken). Al die zaken kunnen veroorzaakt worden door een verkeerd geconfigureerde firewall. Zet die ook eens uit (of alles open) om te testen.

Dat pingen loopt allemaal lekker 9 ms naar tweakers vanaf mijn pc en vanaf mijn router ook 9 ms.
Ze zijn onderling ook pingbaar en gateways en dergerlijke staan zeker weten goed.
Google ping ik vanaf mijn pc in 14 ms.

Hier heb ik een traceroute


Ziet er ook allemaal wel goed uit.
Firewall heb ik nog niet geinstalleerd en ik een echt minimale debian geinstalled met debootstrap.
Ik wou eerst dit fixen voor ik uberhaupt aan een firewall ga beginnen. Morgen zal ik de bridge van eth1 en eth2 eens uitzetten kijken wat hij dan doet.

[AlterMann]

Waarom filter je btw je private IP adres en je username van windows eruit? Het is niet alsof iemand je op je 192.168.1.1 IP kan hacken ofzo..

Gooi er voor de grap ook nog eens een ipconfig /all bij?

[4ourty2]

AlterMann schreef op donderdag 10 juli 2008 @ 12:57:
Waarom filter je btw je private IP adres en je username van windows eruit? Het is niet alsof iemand je op je 192.168.1.1 IP kan hacken ofzo..

Gooi er voor de grap ook nog eens een ipconfig /all bij?

Bij deze:



Btw ik heb die dingen zwart gemaakt omdat mensen lokaal er wel wat mee kunnen

Dit is trouwens de eerste keer dat ik die tunnels zie en ik weet ook niet wat dat is

Edit:
ik kom er net achter dat ik vanaf mijn desktop (vista) geen shares op mijn laptop (arch linux of xp) kan beanaderen. Andersom kan wel alleen duurt 4 gig oversturen 2 uur.

[ Voor 18% gewijzigd door 4ourty2 op 11-07-2008 01:15 ]

[Bergen]

Als je de shares kunt benaderen zou dat betekenen dat de desbetreffende poorten open staan. Maar als het traag gaat is er toch iets aan de hand, misschien staan niet alle poorten open die voor SMB nodig zijn? Volgens samba.org:

Port 135/TCP - used by smbd
Port 137/UDP - used by nmbd
Port 138/UDP - used by nmbd
Port 139/TCP - used by smbd
Port 445/TCP - used by smbd

Btw, let op dat in screenshot 3 je externe IP staat. Je router doet een ARP-request de deur uit inclusief je eigen IP. Misschien even die regel blurren... [edit] Oh dat IP staat op nog wel meer plaatsen in die screenshot en misschien die anderen ook wel.. kijk maar ff. Beetje apart dat je je interne IP wel verwijdert maar je externe niet.

Btw ik heb die dingen zwart gemaakt omdat mensen lokaal er wel wat mee kunnen

Als iemand daar écht wat mee wil doen kan die je IP ook in een handomdraai onderscheppen met wat snifferij, dus zoveel zin heeft dat nou ook weer niet.

[ Voor 48% gewijzigd door Bergen op 11-07-2008 02:18 ]

[Sendy]

UlyssesNL schreef op woensdag 09 juli 2008 @ 21:01:
[...]


Het rare is dat tweakers gewoon snel is en google heel erg traag.
Ik heb tcpdump en wireshark aangezet en toen heb ik google geopent.
Hieronder de resultaten kan je hier wat mee?
De zwarte blokken zijn gewoon mijn private ip range.

desktop
[afbeelding]

router
[afbeelding]

router vervolg
[afbeelding]

Het gaat mij erom dat jij daar wat aan hebt

Als je nu uitzoekt welk verkeer interessant is en met een pennetje en papier de drie listings en tijden eens goed samenvatten. Je kan dan waarschijnlijk ontdekken wat er precies traag is.

Als ik zo snel even kijk zie ik allemaal invalid checksums en retransmissions die telkens enkele seconden duren. Dat lijkt me niet fijn. Ook die ICMP "Fragmentation needed" lijkt me niet goed. Zou dit iets te maken hebben met je MTU?

[ Voor 11% gewijzigd door Sendy op 11-07-2008 09:31 ]

[4ourty2]

Ik heb eindelijk het probleem opgelost.
Het bleek dat de vista tcp/ip window autotuning voor narigheid op mijn netwerk zorgde.
Voor de mensen die dit later ooit nog is nodig mochten hebben.
Dit schakel je uit door het volgende uit te voeren in je run.
"netsh interface tcp set global autotuninglevel=disabled" (zonder quotes)

[Bergen]

Hoe heb je dat nou weer weten te achterhalen?

[4ourty2]

Bergen schreef op zaterdag 12 juli 2008 @ 03:27:
Hoe heb je dat nou weer weten te achterhalen?

Een collega van mij zei tegen me "hey jij hebt toch vista kijk eens naar je tcp window scaling".

En over dat publieke ip adres.
Die verandert toch steeds

[ Voor 10% gewijzigd door 4ourty2 op 12-07-2008 10:08 ]

[Bergen]

Dat verschilt per provider... Bij sommige heb je misschien elke paar dagen een nieuwe, bij andere kun je best een jaar hetzelfde hebben.

[4ourty2]

Bergen schreef op zaterdag 12 juli 2008 @ 14:10:
Dat verschilt per provider... Bij sommige heb je misschien elke paar dagen een nieuwe, bij andere kun je best een jaar hetzelfde hebben.

Dat weet ik ook wel
Ik heb nu al 6 nieuwe in 6 maanden op dezelfde nic.
Als ik een andere nic pak (de router heeft er 3) heb ik ook weer een nieuwe.

[Bergen]

Oh sorry, ik dacht dat het een vraag was.

[Sendy]

Ik ben eigenlijk benieuwd of de verstuurde pakketjes er nu wel netter uitzien. Krijg je nu geen retransmissions meer, en geen foute checksums?

[4ourty2]

Sendy schreef op zaterdag 12 juli 2008 @ 20:57:
Ik ben eigenlijk benieuwd of de verstuurde pakketjes er nu wel netter uitzien. Krijg je nu geen retransmissions meer, en geen foute checksums?

Hmm ik heb toch nog enigzins last van vertragingen .
Bij onderstaand screenshot heb ik hetzelfde gedaan als bovenstaande. (google openen op mijn desktop en de pakketjes op mijn desktop scannen).