Connectie probleem vanuit Windows naar Linux

[CronoS76]

Mijn vraag
Ik gebruik een Raspberry Pi voor iOT doeleinden. Nu heb ik deze pas geleden opnieuw ingericht aangezien de SDCard gecrashed was (nu loopt die via een USB stick) en is deze gekoppeld via Wi-Fi. Ik heb nu het probleem dat voor Windows systemen de Raspberry Pi ineens niet meer gevonden kan worden op het netwerk. Ping faalt; andere protocollen ook. Het vreemde is alleen dat het voor andere Linux systemen (Heb nog een RPB en een Synology) de Raspberry Pi prima prima werkt en geen problemen geeft. Dit impliceert dat de Wi-Fi verbinding verder OK is.
Ik heb twee Windows systemen en twee andere Linux systemen, deze geven hetzelfde resultaat als ik de Raspberry Pi probeer te benaderen. Vanuit Linux heb ik dus geen probleem en kan ik pingen en de Raspberry Pi benaderen voor de diensten. Voor een Windows ping werkt het in principe even na reboot van de PI; maar waarom is dit gedrag anders dan als ik vanuit een Linux systeem zou pingen ontgaat mij. De volgende dag is er dus geen connectiviteit meer vanuit Windows. Ik vind dit zo vaag; dat ik besloot om het eens aan de community te vragen wat dit kan zijn?


Relevante software en hardware die ik gebruik
Ik heb Unifi Accesspoints, Unifi switches en de Unifi Dream Router, waarbij geen extra Firewall's in place zijn. Alles in hetzelfde subnet; overige communicatie over de accesspoints en switches gaan goed.


Wat ik al gevonden of geprobeerd heb
Een reboot van de Pi helpt even. Ook heb ik een keer geluk gehad toen ik de TCP IP stack van Windows gereset had; daarna kon ik ook pingen, maar dat is een keertje geweest..

Iemand enig idee in welke hoek ik dit moet zoeken? Ik zou zelf zeggen dat het iets op de Pi is; ik zou alleen niet weten wat.

[ Voor 7% gewijzigd door CronoS76 op 10-10-2023 10:13 ]

[True]

Kun je 'm wanneer ping (ICMP) niet meer werkt vanaf een Windows machine nog wel vanuit die machine benaderen met SSH?

[DeMolT.]

Zoiets heb ik ook wel eens meegemaakt, maar toen had ik per ongeluk twee devices op hetzelfde IP gezet.

[CronoS76]

True schreef op dinsdag 10 oktober 2023 @ 10:13:
Kun je 'm wanneer ping (ICMP) niet meer werkt vanaf een Windows machine nog wel vanuit die machine benaderen met SSH?

Nee, dat kan ik helaas niet. SSH werkt ook niet. Als ik SSH doe vanuit mijn Synology naar de Raspberry Pi dat gaat Prima. Dus Linux clients werken OK. De windows clients niet.

Duplicate IP lijkt mij niet, aangezien al mijn static IP adressen ook vanuit UniFi komen als reservering. Binnen Unifi krijg ik verder geen melding en lijkt het de RPB gewoon online te zijn verder.

Echt vaag dit..

[True]

Ik zou 'm voor het idee inderdaad even op een ander IPtje zetten. En heb je één of meerdere Windows clients waarop je 'm niet meer kunt bereiken na x-tijd?

[CronoS76]

True schreef op dinsdag 10 oktober 2023 @ 10:32:
Ik zou 'm voor het idee inderdaad even op een ander IPtje zetten. En heb je één of meerdere Windows clients waarop je 'm niet meer kunt bereiken na x-tijd?

Even op een ander IP adres gezet; kijken wat dat geeft.. dat had ik nog niet geprobeerd. Even kijken wat die morgen dan doet..

[True]

CronoS76 schreef op dinsdag 10 oktober 2023 @ 15:22:
[...]

Even op een ander IP adres gezet; kijken wat dat geeft.. dat had ik nog niet geprobeerd. Even kijken wat die morgen dan doet..

Voor het volledige idee, ook even herstarten (je RPi en je Windowsmachine) en ook je router herstarten dan ben je ook af van leases waar dat van toepassing is.

[CronoS76]

Bedankt. Ik heb een ander IP adres gegeven, maar helaas stopte deze ook na een uur of 5. De Router gereboot daarna, waarbij de RPB ook Wi-Fi verbonden aan was. Toen werkte het ook weer eventjes tot vandaag.

Nu heb ik iets verder zitten kijken. Als ik vanaf mijn NAS ping naar de RPB dan is dit ongeveer 4 ms.. dat lijkt me voor Wi-Fi OK. Gebruik ik vervolgens PSPing van Sysinternals, dan krijg ik wel een reply... Alleen dat reply is dan 3000 miliseconde zegt die.. Als ik PING met de -w optie gebruik binnen Windows, dan krijg ik geen reply. Lijkt er dus op dat de verbinding voor Windows tergend traag is, waardoor windows zegt dat deze niet bestaat.. terwijl in werkelijkheid de RPB ook snel respond... Waarom is dit voor Windows anders dan voor Linux clients.Alles pingt verder gewoon snel. Iemand een idee?

[aawe mwan]

Hoe ik je vraag lees is dat je zegt dat je:

• direct na een reboot vanuit Linux en vanuit Windows kunt pingen met je RaspberryPi;
• maar dat een een uur of 5 later, het pingen vanaf Windows computers niet meer werkt, terwijl pingen vanaf Linux computers gewoon blijft werken.

Wat je zou kunnen doen, is controleren waar je precies IPv4 gebruikt en waar IPv6.

Bij IPv6 is het namelijk gebruikelijk dat de computer na een aantal uur automatisch een ander IP-adres krijgt. Bij mijn Raspberry Pi ervaar ik een bug dat de Pi na een aantal uur niet meer bereikbaar is per IPv6 (dus als het adres verandert) en dat na de volgende reboot IPv6 wel weer gaat werken. IPv4 blijft wel gewoon werken.

Dus misschien gebruiken jouw Linux systemen nog IPv4 of expliciet het vast ingestelde IPv4-adres, terwijl jouw Windows computers (automatisch/default) proberen een IPv6 verbinding te leggen.

[CronoS76]

aawe mwan schreef op woensdag 11 oktober 2023 @ 19:47:
Hoe ik je vraag lees is dat je zegt dat je:

• direct na een reboot vanuit Linux en vanuit Windows kunt pingen met je RaspberryPi;
• maar dat een een uur of 5 later, het pingen vanaf Windows computers niet meer werkt, terwijl pingen vanaf Linux computers gewoon blijft werken.

Wat je zou kunnen doen, is controleren waar je precies IPv4 gebruikt en waar IPv6.

Bij IPv6 is het namelijk gebruikelijk dat de computer na een aantal uur automatisch een ander IP-adres krijgt. Bij mijn Raspberry Pi ervaar ik een bug dat de Pi na een aantal uur niet meer bereikbaar is per IPv6 (dus als het adres verandert) en dat na de volgende reboot IPv6 wel weer gaat werken. IPv4 blijft wel gewoon werken.

Dus misschien gebruiken jouw Linux systemen nog IPv4 of expliciet het vast ingestelde IPv4-adres, terwijl jouw Windows computers (automatisch/default) proberen een IPv6 verbinding te leggen.

Bedankt voor het antwoord. Maar het lijkt mij dat alles op basis van IPV4 gaat. Ik ping het IP adres van IPV4.. Ik had op de RPB ook IPV6 uitgezet, stond ergens inderdaad dat het daar iets mee kan zijn.

[CronoS76]

Erg vaag.. Ik test nog even verder, maar ergens lijkt het erop dat het de Windows firewall is die er iets van vind...
Als laatste test; Windows kan de RPB client niet pingen, ik zet de Windows Firewall open (aangezien icmp verkeer uitstaat lijkt me), doe een ping vanaf de RPB naar Windows. Die komt netjes aan.. Vervolgens werkt de Windows client ook meteen als ik dan de RPB ook weer ping..

Vanaf Linux naar Linux werkt het altijd OK..

[CronoS76]

Als ik een ping open vanaf de RPB naar Windows, ook al staat de Windows Firewall dicht en ik dus geen replies zie op de RPB, dan kan ik hierna ook meteen weer de RPB benaderen vanaf Windows. De vraag is dus wie filtert nu dit verkeer.. Windows?.

Linux naar de RPB geeft geen problemen, ik doe zelfs een SSH naar mijn Synology om vervolgens een SSH verbinden te maken naar de RPB om die Ping te starten, ik heb geen monitor aan de RPB hangen...dus dit is wat makkelijker.

[c-nan]

Lijkt iets met arp. Doe eens een tcpdump op je Linux host, komt het verkeer überhaupt aan?

tcpdump -i any icmp -nn

Draai vervolgens een ping vanuit je Windows host

[deHakkelaar]

code:

dmesg -T | grep -i voltage

code:

sudo zgrep -i voltage /var/log/syslog*

code:

vcgencmd get_throttled

???

[CronoS76]

deHakkelaar schreef op vrijdag 20 oktober 2023 @ 15:14:

code:

dmesg -T | grep -i voltage

code:

sudo zgrep -i voltage /var/log/syslog*

code:

vcgencmd get_throttled

???

code:

dmesg -T | grep -i voltage

This one didn't give me any results

code:

sudo zgrep -i voltage /var/log/syslog*

Here I see some old undervoltage messages, these ones are not recent. I saw this when I reinstalled the RPB last month.. Bought a new RPB adapter afterwards then the messages went away...

code:

vcgencmd get_throttled

The output says: throttled=0x0

[CronoS76]

c-nan schreef op vrijdag 20 oktober 2023 @ 11:02:
Lijkt iets met arp. Doe eens een tcpdump op je Linux host, komt het verkeer überhaupt aan?

tcpdump -i any icmp -nn

Draai vervolgens een ping vanuit je Windows host

Duurde even aangezien tcpdump niet standaard op de RPB staat. In elk geval, als ik een ping open vanaf Windows dan komt er geen ICMP verkeer aan als ik dat controleer met TCPdump. Open ik simultaan een ping naar Windows vanaf de RPB, dan begint ping weer te lopen en ook TCPDump ziet vervolgens ook meteen het ICMP verkeer van Windows, zonder dat ik daar iets veranderd heb...

Ik moet dus toch iets triggeren op de RPB zodat Windows ping aankomt... Denk toch iets met de netwerk adapter van RPB ... maar waarom dan zo selectief alleen vanaf windows..

Groetjes,
Robbin

[CronoS76]

I used Sysinternals PSPing64 to ping from Windows to RPB... I see that there is a connection with 3000 m.s. latency in this ping... Therefore the normal TCP connections does not work. From Linux to RPB there is a normal latency.
When I initiate the ping from RPB to Windows, then the connection is restored and latency is back normal..But why is the latency so high after some time.. I also don't suspect my Unifi setup because then Linux to RPB should also be so high...

[Merethil]

Misschien vanaf Windows even 'tracert {ipadres rbp}' doen als het weer voorkomt; kijken of je netwerk/Windows zelf het op de één of andere manier lastig vindt het ipadres te vinden?

[CronoS76]

Merethil schreef op zondag 22 oktober 2023 @ 09:27:
Misschien vanaf Windows even 'tracert {ipadres rbp}' doen als het weer voorkomt; kijken of je netwerk/Windows zelf het op de één of andere manier lastig vindt het ipadres te vinden?

Dit geeft hetzelfde resultaat als ping; meteen een faal op de eerste hop. Psping is het enige wat iets van antwoord geeft..