[netwerk] Onbekend probleem

[TWBMS]

onbekend probleem denk je nu. ja een onbekend probleem.

Ben nu al 3 dagen bezig met een oplossing te vinden voor iets raars in mijn netwerk.
En iedere keer als ik denk een oorzaak te hebben gevonden spreekt iets dat tegen.

Enige waar ik nu nog aan kan denken is dat mijn switch stuk is.. maar je raad het al dat wordt ook al tegen gesproken door iets. namelijk door de systemen waar windows op draait. Die draaien zonder problemen.
Stomme is alle linux systemen hebben er last van behalve me router

Aangezien ik geen zin heb om nog een keer alles uit te moeten kauwen ( heb al dingen gevraagt in verschillende IRC channels en zitten googlen )

Op dit systeem waar ik mometeel op zit er laten we heb A64 noemen.
lekker makkelijk. Die start ik op met een knoppix cd ( versie 3.4 )
Start vrolijk op, krijgt een ip! en heeft vervolgens geen verbdinding.

Na zeg je Hardware stuk.. helaas voor jouw.. nee want ik zit nu op windows en alles werkt normaal. Daarbij zijn er 3 netwerk kaarten die hier in zitten momenteel.
En allemaal geven ze het zelfde probleem.
Zeg je dan is de cd niet in orde, dat kan .. maar ik heb nog een systeem waar mee ik knoppix opstart heeft precies zelfde probleem. Die noemen we maar LFS ( aangezien dat er op zit ).
Als ik die pc met LFS opstart heb ik de zelfde problemen als ik met de knoppix cd opstart.

raar.. ja.. wat gaat er fout..

Wel ik heb A64 systeem opgestart met knoppix 3.4 ( 2.6 kernel ) en zodra hij klaar was heb ik de console open gegooit tcpdump laten luisteren. naar alles op het netwerk en een ping naar de router ( IPcop, enige linux systeem die nergels last van heeft )
Het zelfde heb ik gedaan op de router. tcpdump aan en luisteren naar alles wat van het A64 systeem af moet komen.
Ik kijk op de A64 systeem.. ik zie tcpdump alleen maar ARP request doen om achter de MAC te komen voor routing. Alleen heen niks terug.
Kijk ik op de router dan zie ik tcpdump netjes de ARP request ontvangen en een reply sturen die dus nooit aan komt op de A64 systeem.

Dacht slim te zijn en handmatig de MAC adres in de ARP table te zetten.
Dit had tot gevolg dat het A64 systeem ging pingen ( dat zag je in venter van tcpdump ) maar hij kreeg geen replies.
Kijk ik op de router zie ik hem netjes de pingen ontvangen en een reply sturen.
die niet aan komen...

Stomme is als ik terug naar windows boot op de A64 systeem werkt alles normaal.

Enige verschil dat ik zo kan zien tussen windows pings en Linux pings is dat linux de "DF" flag mee geeft. ( staat voor "Don't frag" ) en windows doet dat niet.
maar als dat het probleem zou zijn dan moeten ze al nooit op de router aan komen.

Iemand nog ideeen? Of beter een oplossing..

[sjoerdb2]

Ik heb ooit een keer zelf UTP-kabels in elkaar geprutst en toen gaf ie wel een link lampje, hij kon ook zenden maar heel slecht ontvangen, hij kreeg net als bij jou wel een ip, maar verder niks. Misschien kun je daar iets mee?

[TWBMS]

sjoerdb schreef op 22 augustus 2004 @ 01:23:
Ik heb ooit een keer zelf UTP-kabels in elkaar geprutst en toen gaf ie wel een link lampje, hij kon ook zenden maar heel slecht ontvangen, hij kreeg net als bij jou wel een ip, maar verder niks. Misschien kun je daar iets mee?

ah vergeten te vertellen.
Ik heb kabels die zelf geknepen zijn maar die heb ik getest.
( aansluiten en internet werkt gewoon zo als het hoort )
Werkte zonder problemen.
Daarnaast heb ik ook kabels die kant en klaar zijn.
Maar die werken ook gewoon.

[Brahiewahiewa]

TWBMS schreef op 22 augustus 2004 @ 01:12:
...Enige verschil dat ik zo kan zien tussen windows pings en Linux pings is dat linux de "DF" flag mee geeft. ( staat voor "Don't frag" ) en windows doet dat niet.
...

En als je op je windows machien het DF vlaggetje aanzet (ping -f)?

[TWBMS]

Brahiewahiewa schreef op 22 augustus 2004 @ 01:54:
[...]
En als je op je windows machien het DF vlaggetje aanzet (ping -f)?

u vraagt "wij" draaien...

code:

C:\>ping -f 192.168.0.100

Pingen naar 192.168.0.100 met 32 byte gegevens:

Antwoord van 192.168.0.100: bytes=32 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=32 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=32 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=32 tijd<10 ms TTL=64

Ping-statistieken voor 192.168.0.100:
    Pakketten: verzonden = 4, ontvangen = 4, verloren = 0 (0% verlies),
Retourtijd bij benadering in milliseconden:
    Minimum = 0 ms, Maximum =  0 ms, Gemiddeld =  0 ms

[Brahiewahiewa]

Tja, een pakketje van 32 bytes groot niet fragmenteren is niet zo'n kunst
Misschien moet je eens experimenteel gaan vaststellen hoe groot de MTU op je netwerk is.
Doe je door achtereenvolgens

code:

ping -f -l 100 192.168.0.100
ping -f -l 200 192.168.0.100
ping -f -l 300 192.168.0.100
...
ping -f -l 1500 192.168.0.100

Als je òf time-out òf "need to fragment but DF bit set" als antwoord krijgt, ga je terug naar de vorige waarde en dan met stapjes van 10 omhoog. Daarna nog een keer met stapjes van 1. De waarde die je zo vindt, met 20 verhogen, dan vind je de MTU. Die MTU kun je vervolgens in je Knoppixje als parameter op je NIC opgeven en dan 's kijken oftie wel wil werken.
Achtergrond is dat Windows automatisch MTU detectie doet en misschien staat dat op jouw Linux distro's niet standaard aan

[jurri@n]

Welke netwerkkaart (merk/type) heb je? Het zou kunnen dat de ondersteuning van die kaart onder linux misschien brak is?

[TWBMS]

router: 2 x realtek
A64: 2 onboard 1 x "nvidia" en de 1GB is van intel en daarnaast heb ik een realtek gestopt voor het geval de onboard niet gezien worden.
LFS: Thunderlan ( TLAN ) onboard en realtek kaartje er naast.
alle realtek gebruiken de 8139too module, die zit of in de kernel of als module er bij.

En 1472 is grootste mogelijkheid anders zit ie te zeuren dat ie niet kan sturen zonder te fragmenteren.

code:

C:\>ping -f -l 1472 192.168.0.100

Pingen naar 192.168.0.100 met 1472 byte gegevens:

Antwoord van 192.168.0.100: bytes=1472 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=1472 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=1472 tijd<10 ms TTL=64
Antwoord van 192.168.0.100: bytes=1472 tijd=15 ms TTL=64

Ping-statistieken voor 192.168.0.100:
    Pakketten: verzonden = 4, ontvangen = 4, verloren = 0 (0% verlies),
Retourtijd bij benadering in milliseconden:
    Minimum = 0 ms, Maximum =  15 ms, Gemiddeld =  3 ms

stomme is voor ik naar CZ ging ( Campzone ) werkte alles goed.
op CZ werkte daar alles goed. En sinds ik thuis ben heb ik dit probleem.

"Ja instellingen na lopen"
Nope, dat is het probleem niet. Knoppix krijg netjes een IP toegewezen op beide systemen. Maar daar heb je ook geen connectie mee.
Daarbij zette ik handmatig het IP in de LFS systeem als die was opgestart met behulp van ifconfig eth0 add <ip>. Reboot en die instellingen zijn weg.
De instellingen van Windows systeem staan al goed anders had ik geen internet heh.

[ Voor 5% gewijzigd door TWBMS op 22-08-2004 13:45 ]

[Verwijderd]

ik heb wel een mooi programmatje die je internet settings reseten... en anders dingen waar je zelf niet bij kan... als je wil hebben moet je maar ff zeggen

[TWBMS]

Ik denk niet zo zeer dat het tooltje mijn problemen zal oplossen.
Daarbij zal het ongetwijfeld voor windows bedoelt zijn en mijn probleem ligt voornamelijk met Linux.

Persoonlijk denk ik dat het niet veel uit maakt.

Maar goed.. mail het maar naar mij. -> twbms at quicknet dotje nl
ben momenteel in stadium om alles te proberen

[CyBeR]

Autonegotiate 't zooitje wel goed met de linux-drivers? Schop eens wat rond met mii-diag en ethtool.

[TWBMS]

theoretish zou ik zeggen ja..
maar tot nu toe heb is mijn probleem onlogish geweest

Ik heb de source gedownload en zal kijken wat ik er mee kan doen.

[Verwijderd]

TWBMS schreef op 22 augustus 2004 @ 13:44:
En 1472 is grootste mogelijkheid anders zit ie te zeuren dat ie niet kan sturen zonder te fragmenteren.

Dat klinkt waarschijnlijk, want 1472 + 20 = 1492, wat een zeer gangbare waarde is voor MTU.

Doe nu eens wat Brahiewahiewa uitlegde - stel die 1492 handmatig in als MTU.

[TWBMS]

Wel heb net even gekeken op de Router en die staat op 1500.
De LFS systeem stond/staat op 16436 (mtu)
en A64 test ik zo even.

Maar dan nog.. ik heb al bewezen dat de packets van LFS of A64 aan komen op de router. Router geeft zelfs een reply. maar die wordt nooit ontvangen.

Ik heb de LFS naar 1492 gezet.. nog go.. heb hem ook naar 1500 gezet.. no go.
Ook als ik de router op 1492 zet maakt het niks uit.

argh vindt *** dat ik geen switch kan lenen.
Ken niemand in de beurt die hem even kan missen.
Hmm wacht ik ga zaterdag naar een lanparty, dat betekent andere switch..

*neemt knoppix cd mee*
Als jullie nog ideeen hebben hoor ik ze graag.
Jullie horen in elk geval hoe de kleine test gaat op de lan met knoppix cd.

edit:

Net A64 pc met knoppix op gestart en pakt 1500 mtu.
Zal morgen met die tools spelen die cyber noemde.

edit:

Wel ik heb mijn oorzaak gevonden, geloof het of niet, zodra ik mijn LFS systeem in het netwerk zet en hij "online" komt trap hij de A64* onderuit, en zorgde er voor dat beide geen verbinding meer hadden.
(* A64 draaide op dat moment knoppix )

Blijkbaar zit er dus een HardWare fout in dat systeem. :\
Mijn switch was dus gewoon stuk >_<

[ Voor 27% gewijzigd door TWBMS op 02-10-2004 20:05 . Reden: oplossing geedit ]