Debian lenny:Regelmatige netwerk disconnects bij statisch ip

[hokitoki]

Ik heb een oude Athlon 2500+ opgetuigd om mijn huidige server in de meterkast te vervangen. Ik heb hierop Debian Lenny geinstalleerd met een softwarematige RAID 0. Na een tijdje kwam ik erachter dat mijn netwerk steeds wegvalt. Als ik een SSH connectie op heb staan dan valt deze na een paar minuten weg en het duurt vaak een tijd voordat ik weer een verbinding op kan bouwen. Met samba heb ik hetzelfde probleem. Als ik een grote file ga versturen dan valt na een tijdje de verbinding weg. Ik heb kunnen traceren dat dit gebeurd zodra ik een statisch IP adres gebruik. Als ik DHCP gebruik heb ik het probleem niet maar aangezien deze bak juist de IP adressen uit moet gaan delen is dat geen optie.

Ik heb ondertussen het hele internet al afgespeurd maar ik kan geen oplossing vinding voor dit enorm irritante probleem. Ik hoop dat een van jullie een oplossing weet.

Ik heb de machine ondertussen al opnieuw geinstalleerd met alleen de basis software erop. De log files waarvan ik het bestaan weet zeggen ook niks. Heb zelfs geprobeerd de SSH logging op DEBUG3 te zetten. Het lijkt erop dat SSH niet eens door heeft dat de verbinding wegvalt.

Mijn interfaces file ziet er trouwens als volgt uit:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 10.0.0.241
netmask 255.255.255.0
gateway 10.0.0.240

[benoni]

De 'allow-hotplug' instelling is meer voor laptops die wisselen tussen WiFi en draad, wellicht werkt 'auto' beter.

En benader je de router via wireless? Goedkope WiFi routers willen nog wel eens de verbinding droppen.

[hokitoki]

Ik ga de auto optie nu even proberen. Het netwerk is trouwens volledig UTP. De kabels heb ik ook gecheckt dus daar ligt het probleem niet (had ik er wel even bij kunnen zetten )

De auto optie lost heb probleem helaas niet op. Ik heb ook nog eens geprobeerd vanaf mijn oude server een SSH verbinding open te houden. Die klapte er ook uit op hetzelfde moment

[ Voor 34% gewijzigd door hokitoki op 16-06-2010 22:24 ]

[Bastien]

Komt er geen melding naar boven met dmesg? En klopt je gateway, is dat het IP van de router?

[benoni]

En als je toch door je dmesg neust... welke chip zit er in de NIC?
Oja, in het geval dat het een rtl8139 is, welke kerneldriver wordt ervoor geladen (lsmod), 8139cp of 8139too?

[DeKaerften]

Een probleem dat ik weleens tegengekomen ben is dat je /etc/network/interfaces geedit is, maar vervolgens network manager niet opnieuw geladen is (install and forget werkt pas na het configureren!). Probeer eens een ifdown eth0 en dan ifup eth0 (als dit het probleem is geeft je bak bij de ifdown ook al aan "eth0 not configured"). Hiervoor moet je dus wel even je bak lokaal benaderen (via ssh ifdown/up doen werkt maar voor de helft )

[hokitoki]

benoni schreef op donderdag 17 juni 2010 @ 00:02:
En als je toch door je dmesg neust... welke chip zit er in de NIC?
Oja, in het geval dat het een rtl8139 is, welke kerneldriver wordt ervoor geladen (lsmod), 8139cp of 8139too?

Ik had in het begin twee netwerk kaarten. Een ervan is inderdaad een rl8139 met de 8139too driver. Het probleem deed zich voor op beide kaarten. Ik heb toen deze kaart eruit gehaald om te kijken of het probleem daardoor veroorzaakt werd (blijkbaar niet dus). Ik gebruik nu alleen nog de interne netwerk kaart van mijn nForce2 N400 chipset. Ik weet zo niet uit mijn hoofd welke driver daarvoor gebruikt wordt, kan ik vanavond even uitzoeken als het nodig is.

Een probleem dat ik weleens tegengekomen ben is dat je /etc/network/interfaces geedit is, maar vervolgens network manager niet opnieuw geladen is (install and forget werkt pas na het configureren!). Probeer eens een ifdown eth0 en dan ifup eth0 (als dit het probleem is geeft je bak bij de ifdown ook al aan "eth0 not configured"). Hiervoor moet je dus wel even je bak lokaal benaderen (via ssh ifdown/up doen werkt maar voor de helft )

Dit ga ik vanavond nog even checken. Ik heb al eerder ifups en ifdowns gedaan zonder de melding "eth0 not configured" dus ik denk niet echt dat dit helpt maar ik ga het vanavond toch nog even proberen.

[benoni]

GuitarWeed schreef op donderdag 17 juni 2010 @ 02:55:
Hiervoor moet je dus wel even je bak lokaal benaderen (via ssh ifdown/up doen werkt maar voor de helft )

ifdown eth0 && ifup eth0

Of desnoods:

ifdown eth0 && sleep 2 && ifup eth0 

Wel even goed nakijken wat je intikt, mij is het wel eens gebeurd dat ik mij vertikte, waarna de remote server volgde. Hiep hoi voor m'n provider die in remote controlled power strips had voorzien

[sam.vimes]

benoni schreef op donderdag 17 juni 2010 @ 09:04:
[...]

ifdown eth0 && sleep 2 && ifup eth0 

Als je op de remote machine ook nog "screen" (http://packages.debian.org/lenny/screen) installeert (en gebruikt ) blijft je remote terminalsessie bestaan als de connectie wordt verbroken. Als je dan later weer inlogt, kun je met

screen -R

de terminalsessie weer oppakken op het punt waar je gebleven was.

[benoni]

sam.vimes schreef op donderdag 17 juni 2010 @ 10:09:
(en gebruikt )

Inderdaad, dat kon me op de zaak wel eens overkomen, dat de bewaker het pand wilde sluiten en dat ik op dat moment eigenlijk wel een commando zou willen hebben om een lopend proces alsnog in een screen sessie te hangen

[hokitoki]

Ik heb vandaag eindelijk weer iets aan dit onderwerp kunnen doen. Ik heb dus het ifup/ifdown trucje geprobeerd. Helaas zonder resultaat. Beide commando's worden zonder problemen uitgevoerd zowel op het moment dat ik geen verbinding kan maken als op het moment dat alles wel gewoon werkt. De interface lijkt dus prima te werken.

Ik heb nog een ander stukje diognostiek loggelaten op mijn server. Ik heb wireshark gedraaid. Wireshark laat een heel raar beeld zien. Op de momenten dat ik geen verbinding kan krijgen zie ik dat de server direct na het opzetten van de verbinding een tcp pakket met RST (reset) vlag stuurt. Dit zorgt er natuurlijk voor dat Putty het voor gezien houd. Gek genoeg wordt er even later toch een SSH pakket gestuurd naar de client maar die verwacht dat natuurlijk niet meer.

Deze observatie geeft mij het vermoeden dat er een ander proces is dat de verbinding loopt te verprutsen zonder dat de SSH daemon het door heeft. Ik heb alleen geen flauw idee hoe ik erachter kan komen welk process het om welke rede doet. Iptables is natuurlijk een waarschijnlijke dader maar de input, forward and output chains staan alledrie simpelweg op accept en iptables zou geen willekeurig gedrag moeten vertonen zoals ik dat heb.

Ik hoop dat jullie nog wat goede ideeën hebben

[hokitoki]

Ik heb het probleem gevonden. Ik heb nog eens wat beter in de Wireshark capture gekeken en zag daar dat er twee systemen op de ARP berichten reageerden waarmee het ip adres word geresolved. Ik bleek dus een ip adres conflict te hebben met een ander apparaat (een router die ik gebruik als switch/access point) die ik helemaal vergeten ben omdat er nooit direct naar connect. Wel een beetje jammer dat linux dus nergens aangeeft dat je een ip conflict hebt

Bedankt voor de hulp mensen

[benoni]

Mooi!

Je geeft zelf nog de beste analyse Topic kan nog veel mensen van pas komen zo