Duplicate Mac adressen

bart2740 · 10 dec 2016, 21:23

Beste,

Ik heb een vraagje omtrent een situatie die ik met een klasgenoot niet uitgeklaard kreeg:

De situatie is als 't volgt.
Windows Hotspot -> 2 telefoons met het zelfde MAC adres. de 2 toestellen kunnen op het internet zonder enig probleem.
Maar wanneer ik een static IP meegeef aan 1 van de 2 toestellen kan 1 van de 2 niet meer internetten. Hoe komt dit?
Het eerste verklaar ik doordat de forwarding table snel wordt geupdate zodat elk IP TOCH de pakketten toegezonden krijgt. Maar het eerste kan ik niet verklaren.

Hopelijk kan iemand mij dit gedrag verklaren

ubremoved_539 · 10 dec 2016, 22:11

Kijk eens wat er in je ARP tabel zit... al zou static of dynamic niet mogen uitmaken.

Een systeem kan tevens multi-homed zijn dus daar zit ook geen probleem.

Het verbaast me alléén dat je geen conflicten krijgt op de dubbele MAC adressen.

FlashBlue · 10 dec 2016, 22:19

Static of dynamic zou idd geen verschil moeten maken.
Tenzij natuurlijk de netwerkstack van die telefoons rare dingen doet door de combo fix ip icm duplicate mac...

Maar ik volg r2504 in zijn verbazing dat het allemaal gewoon werkt met duplicate mac adressen.
Dat is gedrag dat ik alleen zou verwachten bij wired devices op een hub, omdat je packets dan sowieso bij beide devices zullen belanden.

(hoe ben je er trouwens in geslaagd om 2 telefoons een duplicate mac te bezorgen, daarvoor moet je al gaan prutsen in firmware bij de meeste devices. Tenzij je aan het foefelen bent in een virtuele lab omgeving? )

bart2740 · 10 dec 2016, 22:39

Eerst waren de entry's in de ARP tabel van Windows op die desbetreffende adapter static. Waneer ik namelijk het ip naar static ingeef in de Android telefoon wordt er een dynamic entry aangemaakt.
Het spijtige is dat ik niets kan sniffen met WireShark aangezien die desbetreffende adapter na het activeren ervan ook niet in de Wireshark device list verschijnt

Wat betreft het mac aan te passen in de Android telefoon, in dit geval de OnePlus one, koud kunsje.. Aangezien de Windows Phone een ander verhaal was heb ik het maar met de Android phone gedaan.. File opzoeken waar het MAC adres instaat, aanpassen, vliegtuigstand activeren, daarna deactiveren en het MAC adres is veranderd. Toestel kun je daarna gewoon herstarten zodat hij het initiële MAC adres terug krijgt. Of het daadwerkelijk veranderd is kun je natuurlijk verifiëren in de Android Phone zelf, of op Windows..

CCatalyst · 10 dec 2016, 22:55

MAC adres aanpassen is meestal vrij eenvoudig.

Hoe dat kan: beiden pikken gewoon steeds de wireless frames op die de hotspot naar 1 van de 2 stuurt, gezien ze op dezelfde mac luisteren (en hetzelfde IP indien DHCP)? En als ene bezig is zal de andere die vreemde responspackets die hij krijgt gewoon zitten te discarden op application level (zonder errors of ICMP drama te maken) omdat hij die niet thuis kan brengen, I guess. OP geeft te weinig info om dit met zekerheid te stellen.

Reden dat met statisch IP niet werkt is omdat je dan 2 verschillende IP's hebt en hotspot niet zal weten welk MAC aan dat statisch IP (of omgekeerd) gekoppeld is omdat die MAC al aan een ander IP gekoppeld zit, en dan discard hij gewoon. Je kan eventueel testen als je wel outbound raakt (vb ping naar een IP waar je de ping kan zien toekomen) maar niet inbound of dat het allebei niet werkt.

bart2740 · 10 dec 2016, 23:10

Er is inderdaad één toestel (Windows Phone) die idd een gewoon DHCP adres krijgt van de Windows Homespot .. Maar dat verduidelijkt inderdaad al veel!
Enkel degene met een statisch adres kreeg nog toegang tot internet en degene zonder statisch adres (dus door DHCP) kreeg geen toegang meer tot internet.

Het hele vreemde is dat wanneer Windows Phone zijn wifi interface uitgeschakeld, de Android telefoon nog steeds ''verbonden'' denkt te zijn. Zelfs wanneer je probeert te surfen blijft hij gewoon laden tot hij uiteraard op een time-out botst. Maar je moet wel degelijk zelf de wifi uitschakelen. Heel leuke test case

11 dec 2016, 00:59

Het verbaast mij al dat die toestellen hetzelfde mac adres hebben. Dat kán toch gewoon niet, tenzij er ofwel een serieuze productiefout gebeurd is, ofwel het mac adres softwarematig aangepast werd.

Maar verder verbaast het me idd ook dat dit werkt. Je lokale traffiek is puur layer 2 (ethernet) gebaseerd, en dus "geroute" (verkeerde term, maar ik ben de naam van de layer 2 "routing" effe vergeten). Je arp tables zouden direct conflicteren en de frames zouden verkeerd terecht komen.

CCatalyst · 11 dec 2016, 01:48

Het zijn toestellen van verschillende fabrikanten, dus productiefout zou wel zeer straf zijn. Nee, het werd handmatig aangepast uiteraard, zie 3 posts hierboven.

Het woord dat je zoekt is "switching".

Beide devices hebben hetzelfde MAC en hetzelfde IP en hangen wat de eerste switch upstream betreft ook aan dezelfde interface, dus die ziet geen conflict en denkt dat het om 1 en hetzelfde toestel gaat.

ubremoved_539 · 11 dec 2016, 12:10

bart2740 schreef:Het spijtige is dat ik niets kan sniffen met WireShark aangezien die desbetreffende adapter na het activeren ervan ook niet in de Wireshark device list verschijnt

Heb je Wireshark als Administrator gestart ?

CCatalyst schreef:Beide devices hebben hetzelfde MAC en hetzelfde IP en hangen wat de eerste switch upstream betreft ook aan dezelfde interface, dus die ziet geen conflict en denkt dat het om 1 en hetzelfde toestel gaat.

Voor de switch wel... maar beide telefoons zien ook elkaar en zouden dus conflicten moeten geven.

bart2740 · 11 dec 2016, 15:11

Wireshark is inderdaad gestart als Administrator..

CCatalyst · 11 dec 2016, 16:11

r2504 schreef: Voor de switch wel... maar beide telefoons zien ook elkaar en zouden dus conflicten moeten geven.

Ja, maar we zitten hier redelijk op niet-gedefinieerd gebied.

Wat (volgens mij) gebeurt is dat beide telefoons alles ontvangen dat enerzijds voor zichzelf bedoeld is maar ook hetgeen voor de andere telefoon bedoeld is. Want de switch (en downstream de hotspot) denkt dat er maar 1 toestel is en stuurt dus gewoon door, toch zolang beide telefoons ook onder hetzelfde IP zitten en aan dezelfde hotspot hangen.

Normaal zou dit moeten leiden tot ICMP errors vanuit de niet-bedoelde telefoon, want die krijgt "junk" binnen die hij totaal niet kan thuisbrengen, maar blijkbaar leidt dit hier niet tot problemen. Misschien zitten ze gewoon stilletjes te discarden en sturen ze geen ICMP errors, of ze sturen die wel maar ze worden upstream ergens gefilterd. De andere telefoon ziet die ICMP errors sowieso niet, want als die uitgestuurd worden, worden die geadresseerd aan de hotspot.

Maar je gaat inderdaad een wiretap nodig hebben om met zekerheid uitspraken te gaan doen.

11 dec 2016, 16:49

Wireshark (in tegenstelling tot zijn voorloper Ethereal) moet je net niet als admin starten. Zijn capture services, indien goed geinstalleerd, zullen de echte capturing doen, en zijn de enigen die de admin rechten nodig hebben.

Een switch stuurt normaal maar naar 1 poort, omdat hij in zijn arp tables gaat kijken welk toestel waar hangt. Het zou me verbazen dat die gewoon hub gaat spelen op de poorten waar dezelfde mac adressen aan hangen. Wss is die switch wat verward en weet hij de klepel ook niet goed meer hangen, met dus onverwachte resultaten tot gevolg.

Aangezien de mac adressen niet identiek *kunnen* zijn (iemand hier sprak over verschillende fabrikanten?), en dus manueel veranderd moeten zijn, lijkt de oplossing hier dus ze softwarematig terug instellen op hun defaults.

bart2740 · 11 dec 2016, 19:11

De Mac adressen zijn wel degelijk software matig ingesteld, maar deze wijziging is ook zichtbaar moest ik een gewone Wireshark doen op pakketjes die ik stuur naar men pc. Dus dat hij software matig met het MAC-adres gaat spelen kan ik mij niet voorstellen. Deze wijziging wordt uiteindelijk ook pas uitgevoerd wanneer de radio van wifi/gsm/etc wordt ingelezen, zie 'de vliegtuigstand' die ik hierboven had aangehaald.

Het naar default terug zetten vereist het herstarten van het toestel of handmatig terug het default adres in te geven, waarop weer de vliegtuigstand moet ingeschakeld worden en daarna uitgeschakeld worden.

ubremoved_539 · 11 dec 2016, 19:33

ITnetadmin schreef:Een switch stuurt normaal maar naar 1 poort, omdat hij in zijn arp tables gaat kijken welk toestel waar hangt.

Die switch gaat z'n forwarding tables ook gewoon updaten hoor... maar geen idee wat het effect zal zijn indien dit constant switched van de ene poort naar de andere (ik zou verwachten dat communicatie dan niet mogelijk is, maar dat is hier de test case alvast niet, wel via wireless en daar is de situatie anders).

bart2740 · 11 dec 2016, 19:42

Heb r2504 & CCatalyst voorzien van een Wireshark trace. Uiteindelijk tot mijn verbazing kwam de adapter wel tevoorschijn na een update gisterenavond. In het KB Stond niets over de Windows Homespot maargoed...

Aan allen ondertussen al heel hartelijk bedankt om mee te denken!

11 dec 2016, 22:32

r2504 schreef:
ITnetadmin schreef:Een switch stuurt normaal maar naar 1 poort, omdat hij in zijn arp tables gaat kijken welk toestel waar hangt.
Die switch gaat z'n forwarding tables ook gewoon updaten hoor... maar geen idee wat het effect zal zijn indien dit constant switched van de ene poort naar de andere (ik zou verwachten dat communicatie dan niet mogelijk is, maar dat is hier de test case alvast niet, wel via wireless en daar is de situatie anders).

Ja, maar of die software nog weet wat gedaan als dat meerdere keren per seconde heen en weer springt weet ik niet. Dat zal een beetje van de implementatie afhangen; mss negeert ie gewoon updates gedurende x seconden na de nieuwste update.

ubremoved_539 · 12 dec 2016, 09:10

bart2740 schreef:Heb r2504 & CCatalyst voorzien van een Wireshark trace.

Bedankt... maar ik hoop dat je begrijpt dat ik hier geen tijd ga insteken (iets dergelijks troubleshooten waar je zelfs niet kan terugvallen op het MAC adres is haast onmogelijk en vraagt veel tijd - en heeft trouwens geen enkel nut omdat je normaal geen duplicate MAC adres mag hebben).

Je situatie is dus geen correcte configuratie dus ik begrijp ook niet meteen in welke context je bewust een duplicate MAC adres aanmaakt ?

Blijf gewoon van die dingen af en alles zal prima werken.

bart2740 · 12 dec 2016, 10:08

r2504, snap ik hoor

Toch bedankt dat je mee hebt gedacht!
We kunnen met de traces ook niet echt een duidelijk beeld krijgen dus ik denk dat ik ermee ga ophouden ..

Toch bedankt aan iedereen om mee te denken!!

ubremoved_539 · 12 dec 2016, 11:46

bart2740 schreef:We kunnen met de traces ook niet echt een duidelijk beeld krijgen dus ik denk dat ik ermee ga ophouden ..

De vraag blijft wat je bedoeling van dit alles is ? Waarom steek je tijd in iets wat in de realiteit niet (zou mogen) voorkomen ?

bart2740 · 12 dec 2016, 11:59

Had dit als testcase in gedachte met een medecursist. Maar zo te zien met de tools die beschikbaar zijn kan ik niet mijn theorie staven. Dus zal een andere testcase moeten uitdenken...

ubremoved_539 · 12 dec 2016, 14:25

Prima voor educatieve doeleinden al is volgens mij het enige juiste antwoord "duplicate MAC address" in die context (maar eigenlijk moet je dan ook de tools voorzien om wireless te sniffen en niet louter het wired gedeelte achter de AP).

Waarom het al dan niet werkt is een zinloze discussie omdat het niet hoort te werken op die manier.