Raspberry pi onbereikbaar, verkeerd MAC adres in de router

[Pater91]

ik heb hier een behoorlijk vreemd probleempje.

Ik heb 4 raspberry pi 3's aan een netwerk hangen. Deze lezen sensoren uit en sturen deze data door naar een externe server.
Tot zover werkt dat allemaal.
De 4 pi's hangen allemaal aan dezelfde 'domme' switch.

Echter, 2 van de pi's zijn niet te benaderen via SSH, terwijl ze allemaal op exact dezelfde image draaien.
In de router hebben 2 van de pi's het juiste mac adres wat je zou verwachten van de pi, maar de andere 2 dus niet: deze hebben een mac adres wat hoort bij teltonika routers. Vandaar dat ik ze dus ook niet kan benaderen, want dat klopt simpelweg niet.

In eerste instantie waren deze 2 niet benaderbare pi's aangesloten op dezelfde switch, maar dan met een teltonika router ertussen. Op de een of andere manier krijg ik dit niet meer gereset.
Wel kunnen de pi's naar buiten communiceren, maar dat is logisch voor zover ik weet.

Netwerkopstelling nu:
Draytek router <> tp link switch <> pi's

De draytek blijft het verkeerde mac adres aangeven, wat ik ook doe. Op de tp link geven ze ook een oranje ledje bij de poort, ipv een groene zoals bij de wel werkende pi's.

Wat ik geprobeerd heb:
- dhcp range ophogen zodat ze nieuwe ip adressen krijgen > zelfde probleem

- arp cache op de draytek legen > zelfde probleem

- poorten switchen <> zelfde probleem

- het gehele netwerk opnieuw opstarten > zelfde probleem

- netwerkkabels omwisselen van de pi's > zelfde probleem

Wat helemaal vreemd is: zelfs als ze een nieuw ip adres toegewezen krijgen, blijft het verkeerde mac adres zichtbaar in de draytek...

Morgen gaan we de pi's voorzien van een verse image, in de hoop dat dat het probleem fixt. Ik zou alleen wel enorm graag willen weten wat hier nu mis gaat, want het lijkt intussen echt op een software fout aan de kant van de routers.

Heeft iemand enig, maar dan ook enig idee waar ik nog meer naar kan kijken?

[DataGhost]

Lijkt alsof die switch geen switch was maar een router en dat je ergens DHCP/static IP's verkloot hebt. Wat zijn de MAC-adressen voor alle vier de RPi's? Wat is het MAC-adres van die teltonika-router? Dat teltonika-ding krijgt nu zelfs geen stroom meer en zit op geen enkele manier aan je netwerk aangesloten? Heb je iets als "static IP's via DHCP" ingesteld op de Draytek?

[ Voor 9% gewijzigd door DataGhost op 13-08-2020 16:40 ]

[Pater91]

DataGhost schreef op donderdag 13 augustus 2020 @ 16:39:
Lijkt alsof die switch geen switch was maar een router en dat je ergens DHCP/static IP's verkloot hebt. Wat zijn de MAC-adressen voor alle vier de RPi's? Wat is het MAC-adres van die teltonika-router? Dat teltonika-ding krijgt nu zelfs geen stroom meer en zit op geen enkele manier aan je netwerk aangesloten?

De teltonika hangt niet meer aan het netwerk e staat tevens uit.
De switch heb ik voor de zekerheid nagecheckt, maar deze is dus echt volledig unmanaged.
Ook zijn er geen statische ip adressen ingesteld, en ook geen mac > ip bind op de draytek.

Mac adressen:
1: b8:27:eb:f3:f6:98 > werkt
2: b8:27:eb:b3:ea:22 > werkt
3: 00:1e:42:2b:2d:f2 > teltonika mac, onbereikbaar
4: 00:1e:42:2f:22:96 > teltonika mac, onbereikbaar

De optie 'static ips via dhcp' kan ik niet vinden. Het lijkt mij dat dit uitstaat, maar waar zou ik dit ergens kunnen vinden? In de dhcp instellingen staat er niets wat in de buurt komt.

Overigens, de host ID is ook leeg in de draytek voor deze adressen. Lijkt me opzich logisch, maar misschien het vermelden waard.

[ Voor 15% gewijzigd door Pater91 op 13-08-2020 16:55 ]

[ewoutw]

Oranje led op tp-link geeft volgens mij aan dat die op 10/100mbps draait. Kan de Raspberry pi 1gb aan (persoonlijk dacht ik van wel)

Omdat de trltonika uitstaat zijn ze onbereikbaar... logies. Staan de pi’s wel op DHCP? Had je nog iets bijzonders gedaan om die pi’s berijdbaar te maken achter de 2e router?

[DataGhost]

MAC-adressen kunnen we helemaal niks mee, ze verlaten sowieso je netwerk niet eens dus die hoef je niet krampachtig te censureren. Het kan handig zijn om te weten wat XX is, alsmede het (de) MAC-adres(sen) van die teltonika (en type?) en kijken in hoeverre die overeen komen. Nu is het iig zaak om te kijken wat de echte MACs van 3 en 4 zijn, dus monitor+toetsenbord aansluiten en kijken hoe het zit. Dan zie je ook direct wat voor IP ze wel hebben.

[Pater91]

ewoutw schreef op donderdag 13 augustus 2020 @ 16:52:
Oranje led op tp-link geeft volgens mij aan dat die op 10/100mbps draait. Kan de Raspberry pi 1gb aan (persoonlijk dacht ik van wel)

Omdat de trltonika uitstaat zijn ze onbereikbaar... logies. Staan de pi’s wel op DHCP? Had je nog iets bijzonders gedaan om die pi’s berijdbaar te maken achter de 2e router?

Dat is inderdaad 10/100, terwijl het toch echt raspberry pi 3's zijn, stuk voor stuk.
Ik heb al met wat kabels geswitcht, maar deze 2 apparaten blijven 10/100 aangeven, wat ik ook doe. Misschien heeft dit te maken met een handshake verhaaltje o.i.d. wat nu fout loopt omdat ook de router geen contact kan maken met de pi over dit verkeerde mac adres?

De pi's staan op dhcp, en krijgen netjes een ip adres toegewezen.
Voor de rest heb ik niets gedaan om ze bereikbaar te maken achter de 2de router, dat was in eerste instantie niet nodig. Nu moet ik helaas even een aanpassing maken via SSH, maar nu kan ik er dus niet meer bij

DataGhost schreef op donderdag 13 augustus 2020 @ 16:52:
MAC-adressen kunnen we helemaal niks mee, ze verlaten sowieso je netwerk niet eens dus die hoef je niet krampachtig te censureren. Het kan handig zijn om te weten wat XX is, alsmede het (de) MAC-adres(sen) van die teltonika (en type?) en kijken in hoeverre die overeen komen. Nu is het iig zaak om te kijken wat de echte MACs van 3 en 4 zijn, dus monitor+toetsenbord aansluiten en kijken hoe het zit. Dan zie je ook direct wat voor IP ze wel hebben.

Daar heb je inderdaad gelijk in, maar ik ben soms een beetje paranoia met die zaken dus ik censureer wel meer dingen waar je in feite weinig aan hebt Een beetje een lastige tik, maar nu staan ze er dus in, uncensored.

Het ip adres van de Raspberries weet ik trouwens gewoon, en ik kan ze ook gewoon pingen zonder problemen. Zodra ik echter verbinding probeer te maken, dan weigert de hele boel. Zelfs een poortscan op die poorten geeft aan dat alles potdicht zit, terwijl dit 100% zeker niet zo is.

Het MAC adres van de teltonika kan ik nu even niet achterhalen, omdat ik morgen pas weer thuis ben.

[ Voor 8% gewijzigd door Pater91 op 13-08-2020 17:02 ]

[DataGhost]

Pater91 schreef op donderdag 13 augustus 2020 @ 17:01:
[...]

Het ip adres van de Raspberries weet ik trouwens gewoon, en ik kan ze ook gewoon pingen zonder problemen. Zodra ik echter verbinding probeer te maken, dan weigert de hele boel. Zelfs een poortscan op die poorten geeft aan dat alles potdicht zit, terwijl dit 100% zeker niet zo is.

Dan moet je toch echt op de Pi's kijken waarom het dicht staat en ook of ze inderdaad die MAC's hebben en ook die IP's. Je zal niet de eerste zijn die achteraf nog andere apparaten op zijn netwerk blijkt te hebben.

[Pater91]

DataGhost schreef op donderdag 13 augustus 2020 @ 17:04:
[...]

Dan moet je toch echt op de Pi's kijken waarom het dicht staat en ook of ze inderdaad die MAC's hebben en ook die IP's. Je zal niet de eerste zijn die achteraf nog andere apparaten op zijn netwerk blijkt te hebben.

Ik snap je opmerking, maar ik doe dit al langer dan vandaag en geloof me: deze images zijn 100% identiek aan elkaar, op 1 config.txt bestandje na Die poorten staan open, de pi is simpelweg niet bereikbaar omdat de router het ip adres aan het verkeerde mac adres heeft gekoppeld. En aangezien ik dus via de router verbinding moet maken met die apparaten, stuurt hij me continu door naar een verkeerd, momenteel niet bestaand mac adres.
Ik zie in de session control ook daadwerkelijk dat de niet benaderbare ip adressen verbinding hebben met de hoofdserver, en netjes hun data doorsturen.

Verder zijn er dus dus ook echt geen andere apparaten op het netwerk aangesloten die storing kunnen veroorzaken ( routers, slimme switches etc ) dus daar kan het echt niet aan liggen lijkt mij.
Ik denk zelf echt dat de fout ergens in de caching van de Draytek zit. Als ik echter de ARP cache leeg mikker, zijn ze binnen 1 seconde weer terug met hetzelfde, oude, verkeerde mac adres.
Misschien morgen maar eens met wireshark kijken wat de communicatie tussen de pi en de router nu precies doet.

[ Voor 17% gewijzigd door Pater91 op 13-08-2020 17:13 ]

[DataGhost]

Dat kan niet. That is, dan zal je op je lokale machine moeten kijken in je ARP-table of daar dezelfde "verkeerde" MAC's staan. MAC staat via ARP tot IP zoals IP via DNS (e.a.) tot hostname staat. Als jij een ping naar een lokaal IP doet, gaat je computer eerst via ARP opzoeken welk MAC daarbij hoort. Het ping-packet wordt vervolgens naar dat MAC-adres gestuurd en op de machine zelf wordt die pas uitgepakt en gekeken of het IP bij een interface daarop hoort. Als jij dus een reply terugkrijgt betekent dat dat er in je netwerk een device actief is wat ook daadwerkelijk dat "foutieve" MAC-adres heeft, anders komt er geen antwoord. Bovendien moet het IP erbij ook op dat dezelfde device ingesteld staan, anders komt er ook geen antwoord. Ergo: als jij een response krijgt betekent dat dat je een device hebt met dat MAC+IP. Of het je Raspberry Pi is kan je zien door de kabel eruit te trekken en daarna geen response meer te krijgen, of door te kijken op de Pi wat voor MAC+IP daaraan hangen en waarom je SSH-service (kennelijk) niet draait.

ARP gaat verder via broadcast, daar heeft je Draytek helemaal niks mee te maken behalve het niet droppen ervan. Je computer vraagt letterlijk "Wie heeft IP X?" en het device met dat IP zegt "Hoi, dat ben ik!". Er wordt niks toegewezen a la DHCP en is geen centrale "database" zoals DNS dat wel heeft, het enige wat daarbij in de buurt komt is een ARP-cache en die is voor elk device lokaal. Je Draytek kan nog zo hard zeggen (in de web-interface) dat er een device op IP 10.2.3.4 met MAC 12:34:56:78:9a:bc is maar daar heeft jouw PC geen enkele boodschap aan als jij ping 10.2.3.4 intypt. Zeker als je je ARP-cache leeggooit is het mega-waarschijnlijk (lees: 100%) dat de entries die daar een seconde later weer in verschijnen gewoon kloppen, maar dat ze niet zijn zoals jij het graag gezien had.


Merk op hoe de synergy-packets (TCP) met IP's werken en de ARP-packets niet, en hoe er geen enkele tussencommunicatie met mijn router (niet Wistron en ook niet Gigabyte) is. edit: ander voorbeeld met onbekend IP (uit ARP-table gegooid) dus broadcast ARP

[ Voor 14% gewijzigd door DataGhost op 13-08-2020 17:33 ]

[GlowMouse]

DataGhost schreef op donderdag 13 augustus 2020 @ 17:21:
Als jij dus een reply terugkrijgt betekent dat dat er in je netwerk een device actief is wat ook daadwerkelijk dat "foutieve" MAC-adres heeft, anders komt er geen antwoord. Bovendien moet het IP erbij ook op dat dezelfde device ingesteld staan, anders komt er ook geen antwoord. Ergo: als jij een response krijgt betekent dat dat je een device hebt met dat MAC+IP.

Tenzij er toch nog een router tussenzit, maar dan zouden beide MAC-adressen overeen moeten komen (en dat komen ze niet).

[DataGhost]

GlowMouse schreef op donderdag 13 augustus 2020 @ 17:32:
[...]

Tenzij er toch nog een router tussenzit, maar dan zouden beide MAC-adressen overeen moeten komen (en dat komen ze niet).

Ja en nee, de netwerk-setup is dan wel behoorlijk gaar maar hetzelfde MAC hoeft niet per se. Is wel logisch maar geen vereiste. Feit is nu in ieder geval dat TS een of meerdere actieve devices in zijn netwerk heeft met die IP's en "foutieve" MAC's en het is nog niet zeker of dat daadwerkelijk de RPi's zijn en if so, of er überhaupt services op draaien.

[BCC]

Zit er nog een router tussen? Want hoe kom je Aan die Mac adressen?

[Pater91]

DataGhost schreef op donderdag 13 augustus 2020 @ 17:35:
[...]

Ja en nee, de netwerk-setup is dan wel behoorlijk gaar maar hetzelfde MAC hoeft niet per se. Is wel logisch maar geen vereiste. Feit is nu in ieder geval dat TS een of meerdere actieve devices in zijn netwerk heeft met die IP's en "foutieve" MAC's en het is nog niet zeker of dat daadwerkelijk de RPi's zijn en if so, of er überhaupt services op draaien.

Die apparaten zijn daadwerkelijk de RPI's. Ik zie namelijk in de session table van de Draytek netjes dat er 4 apparaten naar buiten gaan, richting dezelfde ip:poort locatie. En de data komt ook gewoon netjes aan bij de eindserver. Via deze session table kan ik dus zien dat de ip adressen waarmee ik probeer te verbinden, daadwerkelijk de RPI's zijn.
2 stuks bereikbaar, 2 stuks onbereikbaar. En het enige verschil is dat de 2 onbereikbare RPI's in eerste instantie verbonden waren middels een teltonika routertje.
Overigens, de software die een open poort verzorgt ( 3000 ) zorgt ook voor het versturen van de data. Deze poort is vreemd genoeg dus niet zichtbaar op deze 2 apparaten, maar ze communiceren wel naar buiten dus het is 100% zeker dat de service draait. Daarnaast, de RPI's sturen via dit script ook informatie uit naar de hoofdserver over de status van de SSH server en de python scripts, en ook daar zie ik dat alles netjes draait.

BCC schreef op donderdag 13 augustus 2020 @ 17:37:
Zit er nog een router tussen? Want hoe kom je Aan die Mac adressen?

Ik kom aan de mac adressen via de hoofdrouter, een draytek vigor 3900. Al zie ik nu, dat wanneer ik succesvol ( ! ) ping vanaf mijn machine naar de onbereikbare RPI's, hier ook hetzelfde vreemde teltonika mac adres in mijn ARP table staat. Ik snap er echt geen pepernoot meer van

DataGhost schreef op donderdag 13 augustus 2020 @ 17:21:
Dat kan niet. That is, dan zal je op je lokale machine moeten kijken in je ARP-table of daar dezelfde "verkeerde" MAC's staan. MAC staat via ARP tot IP zoals IP via DNS (e.a.) tot hostname staat. Als jij een ping naar een IP doet, gaat je computer eerst via ARP opzoeken welk MAC daarbij hoort. Het ping-packet wordt vervolgens naar dat MAC-adres gestuurd en op de machine zelf wordt die pas uitgepakt en gekeken of het IP bij een interface daarop hoort. Als jij dus een reply terugkrijgt betekent dat dat er in je netwerk een device actief is wat ook daadwerkelijk dat "foutieve" MAC-adres heeft, anders komt er geen antwoord. Bovendien moet het IP erbij ook op dat dezelfde device ingesteld staan, anders komt er ook geen antwoord. Ergo: als jij een response krijgt betekent dat dat je een device hebt met dat MAC+IP. Of het je Raspberry Pi is kan je zien door de kabel eruit te trekken en daarna geen response meer te krijgen, of door te kijken op de Pi wat voor MAC+IP daaraan hangen en waarom je SSH-service (kennelijk) niet draait.

ARP gaat verder via broadcast, daar heeft je Draytek helemaal niks mee te maken behalve het niet droppen ervan. Je computer vraagt letterlijk "Wie heeft IP X?" en het device met dat IP zegt "Hoi, dat ben ik!". Er is geen centrale "database" zoals DNS dat wel heeft, het enige wat daarbij in de buurt komt is een ARP-cache en die is voor elk device lokaal. Je Draytek kan nog zo hard zeggen (in de web-interface) dat er een device op IP 10.2.3.4 met MAC 12:34:56:78:9a:bc is maar daar heeft jouw PC geen enkele boodschap aan als jij ping 10.2.3.4 intypt. Zeker als je je ARP-cache leeggooit is het mega-waarschijnlijk (lees: 100%) dat de entries die daar een seconde later weer in verschijnen gewoon kloppen, maar dat ze niet zijn zoals jij het graag gezien had.

[Afbeelding]
Merk op hoe de synergy-packets (TCP) met IP's werken en de ARP-packets niet, en hoe er geen enkele tussencommunicatie met mijn router (niet Wistron en ook niet Gigabyte) is. edit: ander voorbeeld met onbekend IP (uit ARP-table gegooid) dus broadcast ARP

Ik was inderdaad even vergeten dat de ARP cache van de draytek niets doorgeeft aan mijn verbonden apparaten, dus die verklaring is inderdaad niet geldig. Weer wat geleerd

De arp test heb ik even gedaan vanuit een pi die wel benaderbaar is:

- Gepingt naar het ip wat onbereikbaar is > werkt.
- arp gerunt: en ja hoor, hetzelfde, niet kloppende, totaal onlogische, teltonika mac adres..

Als ik hetzelfde doe bij de andere bereikbare pi, dan krijg ik wel het logische mac adres terug… Ik snap er echt geen pepernoot meer van. Hoe kan dit? Hoe kan het in godsnaam zo zijn dat de pi blijkbaar dit mac adres heeft aangenomen? Ik heb een standaard Raspbian image genomen, mijn scripts ( simpele python meuk ) toegevoegt, er een image van getrokken, en deze dus op 4 nieuwe apparaten geknikkert.
2 stuks eerst aan een teltonika gehangen, 2 stuks rechtstreeks aangesloten, en alles werkte. Ik heb geen idee of ze toen benaderbaar waren, want dat was nog niet nodig. De data kwam door en dat was prima.
Daarna heb ik de 2 pi's uitgeschakeld, en bij de andere 2 pi's gelegd en rechtstreeks aangesloten op de switch. Ze kunnen nog wel naar buiten praten, maar reageren op mijn ssh connectie ho-maar.... Ook de management poort waarvoor ik zelf een script heb draaien reageert niet.

De PI gaat toch niet zomaar mac adressen gaan 'clonen' vanuit een standaard Raspbian installatie?
Ik begin echt langzamerhand gek te worden… hoe kan dit in godsnaam

[ Voor 19% gewijzigd door Pater91 op 13-08-2020 17:51 ]

[Ben(V)]

Dat mac adres komt gewoon uit de ARP tabel van die Tp-link switch en heeft verder niets met die twee pi's te maken.
Die blijft hij gewoon onthouden tot er op die poort iets anders wordt aangesloten.

Dit klinkt simpelweg als dat die twee pi's geen connectie hebben met die tp-link en dus ziet die Draytek ze niet.

Dus of kabel, of RJ25 connectors, of defecte poorten of verkeerd gepatched.
Het feit dat die tp-link denkt dat het een Gbps verbinding is klinkt alsof er iets anders aan hangt of dat hij defect is.

Test een met z'n pi rechtstreeks aan die Draytek

[ Voor 8% gewijzigd door Ben(V) op 13-08-2020 17:56 ]

[Pater91]

Ben(V) schreef op donderdag 13 augustus 2020 @ 17:55:
Dat mac adres komt gewoon uit de ARP tabel van die Tp-link switch en heeft verder niets met die twee pi's te maken.
Die blijft hij gewoon onthouden tot er op die poort iets anders wordt aangesloten.

Dit klinkt simpelweg als dat die twee pi's geen connectie hebben met die tp-link en dus ziet die Draytek ze niet.

Dus of kabel, of RJ25 connectors, of defecte poorten of verkeerd gepatched.
Het feit dat die tp-link denkt dat het een Gbps verbinding is klinkt alsof er iets anders aan hangt of dat hij defect is.

Test een met z'n pi rechtstreeks aan die Draytek

Dat dacht ik dus ook. Het feit dat ze 10/100 aangeven ipv gbit vind ik ook verdacht.. maar als ik dus de werkende pi's aansluit op dezelfde kabel en poort als een niet werkende pi, dan heb ik nog steeds dezelfde situatie. Ik heb intussen inderdaad het vermoeden dat de tp link roet in het eten gooit, zal er morgen eens een nieuwe tussen hangen. Maar de arp table van de tp link heeft toch niet te maken met mijn pc? Zoals @DataGhost aangaf, mijn pc stuurt zelf een broadcast uit, en de pi reageert daar op. Of zit er toch een harde cache tussen op de tp link? Want zelfs na een powerloss van meerdere minuten krijg ik hetzelfde probleem terug.

By the way: het zijn raspberry pi 3b+ modellen, dus ze hebben allemaal netjes een gigabit poort. De volledige snelheid haal je er nooit op ivm gebrek aan rekenkracht, maar de linkspeed is wel 1000Mbit.

Tevens hebben ze wel degelijk verbinding, want ze sturen netjes data uit naar de hoofdserver.

[ Voor 6% gewijzigd door Pater91 op 13-08-2020 18:03 ]

[DataGhost]

Inderdaad, dus afgezien van de lampjes lijkt je netwerk gewoon te werken en moet er iets op de RPi's fout staan (of een firewall in een van de switches maar daar hoort een switch zich niet mee bezig te houden).

[Ben(V)]

Netwerkpoort van de pi kan ook defecf zijn.

Weet niet precies wat je bedoelt met "mijn pc stuurt een broadcasrpt uit" en ziet dan de mac adressen van de pi.

Zo werkt het niet.
Als de pi opstart zal hij via een auto negotiate een snelheid onderhandelen met de switch, als dat gedaan is heeft die switch het macadres van die pi geleerd en slaat die op in z'n Arp tabel zodat hij weet aan welke poort die pi hangt.
Daarna stuurt die pi een Dhcp request het netwerk op en de Dhcp server zal die beantwoorden en een ipadres toekennen.
Bij een unmanaged switch worden die Arp tabellen niet opgeschoond (geen Arp flush mogelijkheid), die verdwijnen pas als de poort waar dat macadres gezeten heeft aan een ander macadres wordt toegekend.

Je pc werkt verder gewoon met ip adressen en niet met macadressen.
Als je netwerk inventarisatie software gebruikt worden de Arp tabellen van alle devices uitgelezen en daardoor zie je oude macadressen nog.

Dus die twee pi's hebben hoe dan ook een netwerk probleem.

[ Voor 3% gewijzigd door Ben(V) op 13-08-2020 19:53 ]

[DataGhost]

Ben(V) schreef op donderdag 13 augustus 2020 @ 19:51:
Netwerkpoort van de pi kan ook defecf zijn.

Ze sturen nog wel data uit en reageren op pings, alleen inkomende verbindingen worden niet beantwoord.

Weet niet precies wat je bedoelt met "mijn pc stuurt een broadcasrpt uit" en ziet dan de mac adressen van de pi.

Zo werkt het niet.

Zo werkt ARP.

Als de pi opstart zal hij via een auto negotiate een snelheid onderhandelen met de switch, als dat gedaan is heeft die switch het macadres van die pi geleerd en slaat die op in z'n Arp tabel zodat hij weet aan welke poort die pi hangt.

Tijdens Autonegotiation wordt niks met het MAC-adres gedaan. Deze kan ook niet in de ARP-table gezet worden omdat daar het IP voor bekend moet zijn. Het MAC-adres wordt doorgaans pas opgeslagen in een lokale cache (niet ARP) zodra er op een poort een packet is langsgekomen met dat MAC als source. Tot die tijd zullen alle packets met dat MAC als destination gebroadcast moeten worden over alle poorten.

Daarna stuurt die pi een Dhcp request het netwerk op en de Dhcp server zal die beantwoorden en een ipadres toekennen.

Als de boel met DHCP staat ingesteld klopt dat inderdaad. In de praktijk zal een DHCPDISCOVER vrijwel direct na de autonegotiation plaatsvinden waardoor de switch weet dat dat MAC aan die poort zit zodat de all-port broadcast uit de vorige alinea nooit hoeft plaats te vinden (maar dat kan alsnog in bijvoorbeeld een netwerk met statische IP's en een andere host die constant packets stuurt naar het MAC van de net nieuw aangesloten host).

Bij een unmanaged switch worden die Arp tabellen niet opgeschoond (geen Arp flush mogelijkheid), die verdwijnen pas als de poort waar dat macadres gezeten heeft aan een ander macadres wordt toegekend.

Een switch zal gewoon doen waar 'ie voor geprogrammeerd is. Meestal houdt dat in dat een entry na verloop van tijd (geen packets) vanzelf uit een lookup-tabel verdwijnt en dat bij het down gaan van de link (kabel eruit bijv) alle MACs van die poort worden vergeten. Je kan namelijk prima een andere switch aan een poort hangen waarmee je een aantal MAC-adressen aan dezelfde poort hebt hangen maar waarvan je niet kan zien wanneer er eentje verdwijnt of bij komt. Dat kan overigens ook zonder switch, een netwerkinterface kan prima reageren op meerdere MAC-adressen (bijvoorbeeld virtuele netwerkadapters op een fysieke). Je hebt een behoorlijke k**switch als 'ie maar 1 MAC per poort aankan. De manier waarop entries uit ARP- of MAC-caches verdwijnen is niet zwart/wit de ene manier voor unmanaged en de andere manier voor managed switches.

Je pc werkt verder gewoon met ip adressen en niet met macadressen.

Uh, jawel. Op Ethernet in ieder geval wel. Waar is ARP anders voor nodig en waarom doet je PC daar toch iets mee? Je hoeft ook geen IP te gebruiken op je netwerk, iets anders als IPX kan ook en gebruikt fysiek gewoon MACs om te kunnen communiceren. IP is niet hetzelfde als Ethernet, Ethernet is niet hetzelfde als IP.

Als je netwerk inventarisatie software gebruikt worden de Arp tabellen van alle devices uitgelezen en daardoor zie je oude macadressen nog.

Op veel devices zijn die niet remote uit te lezen, doorgaans wordt gewoon de lokale ARP-tabel gebruikt die aangevuld kan worden met een hele stapel ARP-requests voor alle IP's in de range, of dmv broadcast pings.

Dus die twee pi's hebben hoe dan ook een netwerk probleem.

Ja dat ben ik wel met je eens.

[Ben(V)]

Zo werkt een switch niet echt en ik zei dat na de autonegition de switch het macadres weet, dat heeft natuurlijk niets met dat proces te maken en dat gebeurd echt lang voor er een ip adres uitgedeeld wordt.
Een switch is een laag 2 device en weet niets van ip adressen.

[ Voor 7% gewijzigd door Ben(V) op 13-08-2020 20:54 ]

[DataGhost]

Waarom heb je het dan over ARP-tabellen in een switch? Ben trouwens benieuwd op welk punt een switch dan anders werkt dan ik zei.

[ Voor 40% gewijzigd door DataGhost op 13-08-2020 21:03 ]

[ewoutw]

Alle 4 de Raspberry pi werken gewoon. Ze kunnen pingen en met een server communiceren.

Laag 1 en 2 van het OSI-model zijn dus werkzaam.
Het probleem is dus dat ze niet op een andere manier te bereiken zijn. Aannemelijk is SSH maar TS heeft daar niets over gezegd. Verder ziet die vreemde mac-adressen in zijn router.

Kan je ook zien welke IP adressen er aan die vreemde Mac-adressen hangen?

Heb je al een beeldscherm/toetsenbord aan de pi gehangen? Welk ip geeft die. Zijn die het zelfde?
Meschien is TS wel vergeten om naast de image het SSH bestand te zetten die nodig is voor een headless installatie van de pi. Daarnaast zaten de pi’s eerst achter een router. Ander broadcast domein. Kan het zijn dat er router of nat regels zijn waar die vreemde mac-adressen Vandaankomen?


Overigens doet switch niets met ip-adressen. Die kijkt alleen welk Mac-adres er in het frame zit en stuur het naar de juiste Port.
Daarvoor hout die een ARP-tabel bij met Mac: x = Port:1 Mac: y = Port: 2
Je PC houd een ARP-tabel bij met ip-adres = Mac-adres

[Ben(V)]

DataGhost schreef op donderdag 13 augustus 2020 @ 21:02:
Waarom heb je het dan over ARP-tabellen in een switch? Ben trouwens benieuwd op welk punt een switch dan anders werkt dan ik zei.

Omdat in een switch een tabel bijgehouden wordt welke mac adressen aangesloten zijn (geweest), dit heet mac adres learning en de tabel wordt een Arp tabel genoemd.

Als je argumenteerd dat die benaming niet helemaal de correct is en ietswat anders is dan de Arp tabellen in een layer 3 device heb je gelijk, maar ze worden nu eenmaal zo genoemd.

In een switch is het een mac naar port translation in plaats van een ip naar mac translation zoals in een layer 3 device.
De verwarring komt doordat als je in de wat meer professionele apparatuur komt, veel switches ook layer 3 functionaliteit hebben vermoed ik.


Edit:
Zie net dat dat dit ook al door @ewoutw geschreven was.

[ Voor 22% gewijzigd door Ben(V) op 14-08-2020 00:01 ]

[DataGhost]

Ben(V) schreef op donderdag 13 augustus 2020 @ 23:52:
[...]


Omdat in een switch een tabel bijgehouden wordt welke mac adressen aangesloten zijn (geweest), dit heet mac adres learning en de tabel wordt een Arp tabel genoemd.

Dus eigenlijk precies wat ik zei, met als verschil dat het geen ARP-tabel/cache genoemd hoort te worden omdat

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address.

De MAC-table/cache (zoals ik hem dan maar noem) gaat over link-layer naar physical dus dat is iets heel anders.

Als je argumenteerd dat die benaming niet helemaal de correct is en ietswat anders is dan de Arp tabellen in een layer 3 device heb je gelijk, maar ze worden nu eenmaal zo genoemd.

In een switch is het een mac naar port translation in plaats van een ip naar mac translation zoals in een layer 3 device.
De verwarring komt doordat als je in de wat meer professionele apparatuur komt, veel switches ook layer 3 functionaliteit hebben vermoed ik.

Dat beargumenteer ik inderdaad en als dat daadwerkelijk zo is in professionele apparatuur is dat jammer, tenzij ze dingen met L3 doen en het daar op slaat. Bij een voor de admin zichtbare tabel met een mapping van MAC naar poort verwacht ik een andere naam dan "ARP-table". Jij was echter degene die claimde dat bij autonegotiation het MAC-adres bekend wordt (en niet pas na het eerstverzonden packet) en dat PC's niks met MAC-adressen doen (dat doen ze wel binnen hetzelfde subnet). Ik vind het fijn als onderbouwd wordt waarom "zo werkt het niet" als ik zelfs daarvoor een Wireshark-screenshot geplaatst heb waarin het wel zo werkt, zodat mocht ik het mis hebben dan kan ik er tenminste nog wat van leren.

[chaoscontrol]

Pater91 schreef op donderdag 13 augustus 2020 @ 17:09:
[...]


Ik snap je opmerking, maar ik doe dit al langer dan vandaag en geloof me: deze images zijn 100% identiek aan elkaar, op 1 config.txt bestandje na

Wissel de SD eens met een werkende Pi. Is het dan anders?

[Wim-Bart]

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address.

Maar gedeeltelijk waar. MAC adres is gewoon laag 2 en heeft niks te maken met IPv4 an sich. MAC adres zorgt er voor dat er op laag 2 gecommuniceerd kan worden en dat in de huidige wereld IPv4 verkeer over een verbinding gaat waaraan een MAC adres is gekoppeld is gewoon doordat we dit medium gebruiken.

Een netwerk kan op IPX protocol hebben, of oude NETBUI protocol, ARP zelf is een protocol net zoals IPv4 en IPv6, of wat dacht je van CDP of STP. Allemaal gebruiken sturen ze pakketen over een medium wat MAC adressen gebruikt om het aan te laten komen.

Iedere poort op een willekeurig device heeft een MAC tabel. Ook wel bekend als ARP tabel, dit is niks anders, op laag 2, waarin een device weet welke devices, geïdentificeerd worden met een MAC adressen, zijn verbinden aan die poort.

Ongeacht de configuratie, uitgaande van een standaard netwerk, met 1 of meer routers (default gateway en statische routes werkt het als volgt) voor IPv4:

Neem bijvoorbeeld het volgende netwerk:

Interne range: 192.168.0.0/24, default gateway 192.168.0.1
Tweede range: 192.168.1.1/24, default gateway 192.168.1.1

In de reeks 192.168.0.0/.24 zitten de volgende systemen:
192.168.0.1 INTERNETGW
192.168.0.2 HOSTA
192.168.0.3 HOSTB
192.168.0.4 PC
192.168.0.5 GW2 (Poort 1 van GW2)

In de reeks 192.168.1.0/24 zitten de volgende systemen:
192.168.1.1 GW2 (poort 2 van GW2)
192.168.1.2 HOSTC
192.168.1.3 HOSTD

Op de router (192.168.0.1) is een statische route aangebracht welke de volgende configuratie heeft:
192.168.1.0/24 Gateway: 192.168.0.5

Een aantal scenario's - GEEN RIP, OSPF en MAC-helpers:
Vanaf "PC" 192.168.0.4 doe ik een ping naar 192.168.0.2
- Op netwerk komt een broadcast: Whois 192.168.0.2 naar het IP adres 192.168.0.255 (Broadcast adres voor 192.168.0.0/24)
- 192.168.0.2 zal antwoorden met zijn MAC adres rechtstreeks naar 192.168.0.4
- Wanneer 192.168.0.2 geen netwerk verbinding heeft dan zal er niemand anders antwoorden.

Vanaf "PC" 192.168.0.4 doe ik een ping naar 8.8.8.8
- Op netwerk komt een broadcast: Whois 8.8.8.8 naar het IP adres 192.168.0.1 (Omdat het een adres is buiten de range van de PC gaat het naar de default gateway)
- 192.168.0.1 zal antwoorden met zijn MAC adres rechtstreeks naar 192.168.0.4
- Wanneer 192.168.0.1 geen netwerk verbinding heeft dan zal er niemand anders antwoorden.

Vanaf "PC" 192.168.0.4 doe ik een ping naar 192.168.1.2
- Op netwerk komt een broadcast: Whois 192.168.1.2 naar het IP adres 192.168.0.1(Omdat het een adres is buiten de range van de PC gaat het naar de default gateway)
- 192.168.0.1 weet dat 192.168.1.2 ergens achter 192.168.0.5 zit en stuurt een ARP request naar 192.168.0.5
- 192.168.0.5 geeft zijn MAC adres terug aan 192.168.0.1, en 192.168.0.1 zal het MAC adres doorgeven aan 192.168.0.4
- Wanneer 192.168.0.1 geen netwerk verbinding heeft dan zal er niemand anders antwoorden.
- Wanneer 192.168.0.5 geen netwerk verbinding heeft dan zal er niemand anders antwoorden.

De switch is hierin dan ook geen enkele factor anders dan dat de switch een vervuilde MAC tabel heet. Zet je de switch uit, dan is de tabel leeg.

Wat kan er fout gaan:
- SELinux: Wanneer je een image maakt en die zet je op ander systeem dan werkt het maar half, doordat MAC adres en SELinux met elkaar verbonden zijn.
- MAC adres spoofing in OS. MAC adres is hard gecodeerd in eth config.
- Static ARP tabellen, je kan in een router en in Linux en in Windows met static ARP tabellen werken. Deze overleven een reboot.

[DataGhost]

Wim-Bart schreef op vrijdag 14 augustus 2020 @ 02:12:
[...]

Maar gedeeltelijk waar. MAC adres is gewoon laag 2 en heeft niks te maken met IPv4 an sich. MAC adres zorgt er voor dat er op laag 2 gecommuniceerd kan worden en dat in de huidige wereld IPv4 verkeer over een verbinding gaat waaraan een MAC adres is gekoppeld is gewoon doordat we dit medium gebruiken.

Een netwerk kan op IPX protocol hebben, of oude NETBUI protocol, ARP zelf is een protocol net zoals IPv4 en IPv6, of wat dacht je van CDP of STP. Allemaal gebruiken sturen ze pakketen over een medium wat MAC adressen gebruikt om het aan te laten komen.

Iedere poort op een willekeurig device heeft een MAC tabel. Ook wel bekend als ARP tabel, dit is niks anders, op laag 2, waarin een device weet welke devices, geïdentificeerd worden met een MAC adressen, zijn verbinden aan die poort.

Daarom ook de dikgedrukte stukjes in mijn quote en doelde ik niet op de rest ertussen. IPX heb ik ook al genoemd als voorbeeld hier, juist om de onafhankelijkheid met IP aan te geven. Het gaat bij ARP inderdaad om link- naar netwerk-layer (2 naar 3), maar dus niet physical (1). Dus een switch heeft inderdaad niks met ARP te maken en zal gewoon werken ook in afwezigheid van ARP-packets (bijv. als alle devices behalve de switch static ARP-tables hebben). Wel kan het zo zijn dat een device "onbereikbaar" wordt als je hem in een andere poort stopt en dat device uit zichzelf geen packets stuurt (static IP, alleen listeners). Je kan dan een gratuitous ARP uitsturen wat eigenlijk niet meer of minder is dan een broadcast-packet, waardoor de switch de mapping kan aanpassen naar een andere poort. Dat het toevallig ARP heet boeit de switch verder niets, een willekeurig ander packet uitsturen had hetzelfde effect gehad, maar deze heeft als bijkomend voordeel dat alle hosts direct zien dat de host aanwezig is en kunnen eventueel direct IP-conflicten opgespoord worden.

[...Voorbeelden, beetje uitgebreid...]
Vanaf "PC" 192.168.0.4 doe ik een ping naar 8.8.8.8
- Op netwerk komt een broadcast: Whois 8.8.8.8 naar het IP adres 192.168.0.1 (Omdat het een adres is buiten de range van de PC gaat het naar de default gateway)
- 192.168.0.1 zal antwoorden met zijn MAC adres rechtstreeks naar 192.168.0.4

Vanaf "PC" 192.168.0.4 doe ik een ping naar 192.168.1.2
- Op netwerk komt een broadcast: Whois 192.168.1.2 naar het IP adres 192.168.0.1(Omdat het een adres is buiten de range van de PC gaat het naar de default gateway)
- 192.168.0.1 weet dat 192.168.1.2 ergens achter 192.168.0.5 zit en stuurt een ARP request naar 192.168.0.5
- 192.168.0.5 geeft zijn MAC adres terug aan 192.168.0.1, en 192.168.0.1 zal het MAC adres doorgeven aan 192.168.0.4

Kleine correctie: als de source weet dat het IP wat 'ie wil bereiken buiten zijn subnet zit moet het sowieso over een gateway gaan. De route-tabel zal dus geraadpleegd worden om te kijken welke gateway dat moet zijn (je kan naast een default gateway nog prima tig andere gateways hebben) en dan zal voor het IP van de gateway een ARP-request gedaan worden (als die nog niet in de cache zit), niet voor het doel-IP. Dat laatste kan ook helemaal niet, aangezien de gewenste gateway helemaal niet kan weten dat hij de gewenste gateway is dus die zal of op alle broadcasts voor een ander dan zijn eigen IP('s) moeten reageren (puinhoop) of op geen een. Pas op het moment dat je aankomt bij een hop die in het doel-subnet zit zal die een ARP sturen. Het MAC-adres van de doelmachine wordt dus nooit bekend bij de bron als er een hop tussen zit. Dat zou voor de routering ook erg naar zijn, aangezien daar (MAC) geen regels voor zijn.

[_root]

Wim-Bart schreef op vrijdag 14 augustus 2020 @ 02:12:
[...]

Iedere poort op een willekeurig device heeft een MAC tabel. Ook wel bekend als ARP tabel, dit is niks anders, op laag 2, waarin een device weet welke devices, geïdentificeerd worden met een MAC adressen, zijn verbinden aan die poort.

Niet waar, een MAC table is de opsomming van de verschillende L2 adressen, een ARP tabel is de relatie tussen deze L2 adressen en L3 adressen. Op een echte laag 2 switch kom je dus geen ARP tabel tegen.

[ Voor 5% gewijzigd door _root op 14-08-2020 04:25 ]

[laurens0619]

Kun je lokaal niet bij of vanaf de buitenkant?
En heb je (cross) kabel direct in pc gebprobeerd zonder switch?
Of verbinding van een andere verse computer? Of als je die niet hebt, geef ie pc een nieuw op. Wie weet staat je management ip wel in een fail2ban oid.

[ Voor 111% gewijzigd door laurens0619 op 14-08-2020 07:30 ]

[SniperGuy]

Een tekening zou helpen, typenummers van de netwerk hardware ook

Kan je lokaal wel van de ene (wel werkende) rpi naar de niet werkende rpi's ssh en?
Als je niet van WAN naar LAN kan connecten zit het probleem in de draytek
Als je lokaal ook niet kan SSH'en dan zit het probleem lokaal. Heb je echt niet stiekum ergens nog wat Powerline adapters, routers of WIFI bridge in het netwerk hangen waar die niet werkende rpi's achter zitten?

[ Voor 54% gewijzigd door SniperGuy op 14-08-2020 08:19 ]

[Pater91]

Zojuist dit gevonden, exact hetzelfde probleem:

https://www.raspberrypi.org/forums/viewtopic.php?t=241329

Lang verhaal kort: De eerste 3 items van het mac adres zijn blijkbaar 'overruled' door de teltonika.
Verder nog geen oplossing, maar dus wel een verklaring

[DataGhost]

Raar verhaal, enorm lelijk. Range extenders zijn sowieso lelijke dingen, en dat zou het een soort router maken ipv een simpele switch. Verklaart nog niet helemaal waarom je dan wel outgoing verkeer hebt, ik gok dat dat TCP is en daarvoor heb je toch echt responses nodig. Hoe dan ook zou het met het loskoppelen en uitschakelen van dat teltonika ding weer terug naar normaal moeten zijn. Wat in dat topic beschreven wordt is een rewrite door de router, niet door het bron-device (RPi) zelf.

Maar ik heb het nu al een paar keer gevraagd en ik ben ondertussen niet de enige meer: wat zeggen de verschillende netwerktools over je MAC's en IP's als je een toetsenbord en beeldscherm aansluit, wat is de status van je SSH-service, iptables en fail2ban-achtigen en wat zeggen je logs en dmesg erover? Mijn RPi3 heeft gewoon HDMI en USB dus ik had al wel verwacht dat je dit gedaan zou hebben.

[sh4d0wman]

Wat is er in je Draytek te zien over de Pi's? Daar zou je probleem imho moeten zitten.

Stap 1. Kijk eens onder Diagnostics -> View ARP Cache Table

Staan hier alle Pi's in?
Ook 2 met verkeerde MAC?

Stap 2 Kijk daarna eens onder LAN -> Bind IP To Mac

Is de ARP Table hetzelfde?
Zit er iets in de IP Bind List? Bijvoorbeeld je Pi's met juiste IP aan verkeerde MAC

(menu opties komen uit google rollen, geen idee hoe het overeenkomt met de Draytek die je hebt staan)

[Ben(V)]

Pater91 schreef op vrijdag 14 augustus 2020 @ 14:30:
Zojuist dit gevonden, exact hetzelfde probleem:

https://www.raspberrypi.org/forums/viewtopic.php?t=241329

Lang verhaal kort: De eerste 3 items van het mac adres zijn blijkbaar 'overruled' door de teltonika.
Verder nog geen oplossing, maar dus wel een verklaring

Volkomen onzin verhaal.
Als dat waar zou zijn werkt geen enkel netwerk meer.

Er gaat gewoon iets niet goed tussen die switch en die pi's, anders kan die switch port nooit in 1GBps mode staan want een pi 3 kan maar 100Mbps aan.

Zal wel een pi issue zijn die dingen hebben altijd al een knullige netwerk poort gehad met een netwerk naar usb converter er tussen geprutst.
Is pas opgelost met de pi 4.