hardware MAC-adres herstellen (intel i219-v NIC)

[Flumble]

Mijn moederbord is terug van een RMA, maar zowel de BIOS als windows zeggen nu dat het MAC-adres 88:88:88:88:87:88 is.
De sticker op de ethernetpoort heeft gelukkig wel het echte MAC-adres, beginnend met 1C:1B:0D.
Enig idee of en hoe ik het MAC-adres kan herstellen?

Het gaat om een GA-B150-HD3P, waar dus een I219-V nic in de chipset zit.

[nelizmastr]

Vraagje: hoe erg is het dat je deze MAC hebt?

[Nielson]

Dit bv al geprobeerd? http://blogs.interfacett....ess-intel-drivers-windows

[johnkeates]

nelizmastr schreef op zaterdag 06 augustus 2016 @ 19:18:
Vraagje: hoe erg is het dat je deze MAC hebt?

Heel erg. Weet je niet waar MAC adressen voor gebruikt worden?

Edit: iets genuanceerder, het is eigenlijk vooral erg dat alle board-data gewoon gewist is en je het bord terug krijgt, klinkt alsof iemand een vieze hack gedaan heeft om een bord terug te sturen in plaats van het goed op te lossen.

Nielson schreef op zaterdag 06 augustus 2016 @ 19:21:
Dit bv al geprobeerd? http://blogs.interfacett....ess-intel-drivers-windows

Dat is geen echte oplossing, het helpt ook niet met het onderliggende probleem.

Flumble schreef op zaterdag 06 augustus 2016 @ 17:09:
Mijn moederbord is terug van een RMA, maar zowel de BIOS als windows zeggen nu dat het MAC-adres 88:88:88:88:87:88 is.
De sticker op de ethernetpoort heeft gelukkig wel het echte MAC-adres, beginnend met 1C:1B:0D.
Enig idee of en hoe ik het MAC-adres kan herstellen?

Het gaat om een GA-B150-HD3P, waar dus een I219-V nic in de chipset zit.

Je kan dit herstellen met een BIOS update waarbij je de waardes herstelt. Je hebt op je moederbord misschien ook wel stickers/nummers met dingen als serienummer en UUID zitten, die kan je dan ook meteen instellen.

Ik weet niet waarvoor je RMA nodig was, maar het lijkt er op dat iemand je BIOS geflasht heeft en alle board-specific data gewist heeft.

[Voor 20% gewijzigd door johnkeates op 06-08-2016 19:43]

[Croga]

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:22:
Heel erg. Weet je niet waar MAC adressen voor gebruikt worden?

Zolang je achter een NAT router zit nagenoeg nergens voor. Zeker niet op een ethernet poort (op een Wifi NIC kan het uit maken als je WLAN MAC filtering gebruikt).

Ofwel; TS; waarom zou je het willen? Heb je je computer rechtstreeks aan het Internet hangen? Zo niet dan gaat het je geen drol uit maken.

[nelizmastr]

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:22:
[...]


Heel erg. Weet je niet waar MAC adressen voor gebruikt worden?


[...]

Niet zo bijdehand. De kans dat een ander ook die MAC heeft is bijzonder klein, dus het is niet per definitie erg, niet uit de hoogte gaan doen.

[Croga]

nelizmastr schreef op zaterdag 06 augustus 2016 @ 19:24:
Niet zo bijdehand. De kans dat een ander ook die MAC heeft is bijzonder klein, dus het is niet per definitie erg, niet uit de hoogte gaan doen.

En zelfs als iemand anders dat MAC wel heeft maakt het nog alleen maar uit wanneer je in hetzelfde netwerk zit. En die kans is nog vele malen minusculer.....

[johnkeates]

Voor het oplossen: je hebt firmware van AMI, je kan met een AMI tool het MAC adres (en ook andere gegevens) wijzigen. Een is AMIBCP, en een andere is AMITool. Voor sommige (oudere) firmwares kon het met AFU, maar dat is in dit geval waarschijnlijk niet meer zo.

Croga schreef op zaterdag 06 augustus 2016 @ 19:24:
[...]

Zolang je achter een NAT router zit nagenoeg nergens voor. Zeker niet op een ethernet poort (op een Wifi NIC kan het uit maken als je WLAN MAC filtering gebruikt).

Ofwel; TS; waarom zou je het willen? Heb je je computer rechtstreeks aan het Internet hangen? Zo niet dan gaat het je geen drol uit maken.

Een MAC adres is niet een random serie hexadecimale bytes, maar er zit een structuur met controlesom in. Zijn MAC adres bevind zich nu in een niet-bestaande range wat problemen oplevert zodra er ook maar 1 apparaat dat soort onzin-adressen niet accepteert. Het wordt ook door Windows gebruikt voor het genereren van het installatie ID. Daarnaast kan het zomaar zijn dat netwerksoftware (drivers, Windows zelf) het adres niet accepteert.

Een nuance: stel dat alles gewoon werkt, dan is er niks aan de hand. Maar om dat het dan non-standaard en non-supported is kan het in de toekomst alsnog stuk gaan...

[Voor 19% gewijzigd door johnkeates op 06-08-2016 19:45]

[Blokker_1999]

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:29:
[...]


Een MAC adres is niet een random serie hexadecimale bytes, maar er zit een structuur met controlesom in. Zijn MAC adres bevind zich nu in een niet-bestaande range wat problemen oplevert zodra er ook maar 1 apparaat dat soort onzin-adressen niet accepteert. Het wordt ook door Windows gebruikt voor het genereren van het installatie ID. Daarnaast kan het zomaar zijn dat netwerksoftware (drivers, Windows zelf) het adres niet accepteert.

Hoe kom je er bij dat er een checksum zou inzitten of in een range zit die niet bestaat? Een MAC bestaat uit 2 delen. De eerste 24 bits (OUI) identificeren de fabrikant, de andere 24 (interfice identifier) identificeren de kaart. Er is geen enkele reden om daar een checksum bij in te bouwen omdat het niet om dynamische maar statische informatie gaat of om bepaalde ranges te gaan excluden.

Bijkomend werkt een MAC adres van 88-88-88-88-87-88 perfect:



Het enige wat van belang is, is de tweede LSB van het eerste octet. Indien deze op 1 staat heb je in principe een globaal MAC adres (toegekend door de fabrikant), staat dit op 0 heb je een lokaal MAC adres, toegekend door de eindgebruiker. Niet iedereen respecteerd dat, maar in dit geval voldoe je ook aan die standaard. Ook de LSB van het eerste octet is een 0, ook dit is correct en komt overeen met een MAC adres voor unicast gebruik.

[johnkeates]

Blokker_1999 schreef op zaterdag 06 augustus 2016 @ 19:51:
[...]

Hoe kom je er bij dat er een checksum zou inzitten of in een range zit die niet bestaat? Een MAC bestaat uit 2 delen. De eerste 24 bits (OUI) identificeren de fabrikant, de andere 24 (interfice identifier) identificeren de kaart. Er is geen enkele reden om daar een checksum bij in te bouwen omdat het niet om dynamische maar statische informatie gaat of om bepaalde ranges te gaan excluden.

Bijkomend werkt een MAC adres van 88-88-88-88-87-88 perfect:

[afbeelding]

Het enige wat van belang is, is de tweede LSB van het eerste octet. Indien deze op 1 staat heb je in principe een globaal MAC adres (toegekend door de fabrikant), staat dit op 0 heb je een lokaal MAC adres, toegekend door de eindgebruiker. Niet iedereen respecteerd dat, maar in dit geval voldoe je ook aan die standaard. Ook de LSB van het eerste octet is een 0, ook dit is correct en komt overeen met een MAC adres voor unicast gebruik.

Er zit inderdaad geen checksum in, maar wel identifying bits, slechte vertaling. Komt er zoals je zelf schrijft op neer waar een MAC adres voor bedoeld is. De eerste serie bytes geven behalve de OUI ook aan of het überhaupt voor je lokale ethernet netwerk bedoeld is, of voor zaken als MPLS om maar wat te noemen. Hoewel het MAC adres niet totaal poep is, is het natuurlijk nog steeds een onzin adres.

Het lekker laten staan om dat het makkelijker is dan het goed te doen vind ik zelf geen reden om het niet te herstellen.

[PD2JK]

Laatst ook het MAC-adres moeten wijzigen van een ASRock bord vanwege een "mac address are invalid in both CMOS and Flash" error tijdens de POST.

Opstart DOS USB-stickje maken met Rufus.
Daarna met 'mac'-tool het MAC-adres wijzigen. Download

Even de Readme lezen in de *.zip welke parameters je moet opgeven.

[Croga]

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:55:
Er zit inderdaad geen checksum in, maar wel identifying bits, slechte vertaling. Komt er zoals je zelf schrijft op neer waar een MAC adres voor bedoeld is. De eerste serie bytes geven behalve de OUI ook aan of het überhaupt voor je lokale ethernet netwerk bedoeld is, of voor zaken als MPLS om maar wat te noemen. Hoewel het MAC adres niet totaal poep is, is het natuurlijk nog steeds een onzin adres.

Het is wel heel erg lang geleden dat ik zo'n reeks absolute onzin gelezen heb.......

Het MAC adres is niets anders dan een unieke identifier bedoelt om netwerk verkeer te routeren.
Ja, sommige fabrikanten hebben afspraken gemaakt over wie welke MAC adressen toekent aan hun NICs en daarvoor worden fabrikant-afhankelijke delen van het adres gebruikt. Maar in de praktijk zijn er veel meer die zich daar niet aan houden.

Zolang een MAC adres uniek is op het netwerk waar het zich bevindt maakt het verder geen ruk uit wat dat MAC adres is.

[Blokker_1999]

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:55:
[...]


Er zit inderdaad geen checksum in, maar wel identifying bits, slechte vertaling. Komt er zoals je zelf schrijft op neer waar een MAC adres voor bedoeld is. De eerste serie bytes geven behalve de OUI ook aan of het überhaupt voor je lokale ethernet netwerk bedoeld is, of voor zaken als MPLS om maar wat te noemen. Hoewel het MAC adres niet totaal poep is, is het natuurlijk nog steeds een onzin adres.

Het lekker laten staan om dat het makkelijker is dan het goed te doen vind ik zelf geen reden om het niet te herstellen.

Opnieuw fout. MPLS staat los van het MAC adres maar is een label dat voor de header word toegevoegd aan een datagram. De enige bits die in het MAC adres van belang kunnen zijn hebben te maken met het feit of het een lokaal of globaal MAC adres is (wat voor de werking van het IP protocol al niet van belang is) en of dat het om een unicast of multicast bericht gaat (waar dat het apparaat dan van mag kiezen wat het ermee doet als het multicast is). En ja, de eerste 24 bits zijn enkel en alleen de OUI ofwel voluit Organizationally Unique Identifier. Een identificatie van de organisatie die dat het MAC adres heeft toegekend aan de adapter.

Het is een onzin adres (de OUI bestaat niet), maar verder dan dat is er geen enkel probleem. Een MAC adres moet gewoon uniek zijn binnen het lokale netwerk. Dat is het enige wat belangrijk is.

[johnkeates]

Blokker_1999 schreef op zaterdag 06 augustus 2016 @ 20:44:
[...]

Opnieuw fout. MPLS staat los van het MAC adres maar is een label dat voor de header word toegevoegd aan een datagram. De enige bits die in het MAC adres van belang kunnen zijn hebben te maken met het feit of het een lokaal of globaal MAC adres is (wat voor de werking van het IP protocol al niet van belang is) en of dat het om een unicast of multicast bericht gaat (waar dat het apparaat dan van mag kiezen wat het ermee doet als het multicast is). En ja, de eerste 24 bits zijn enkel en alleen de OUI ofwel voluit Organizationally Unique Identifier. Een identificatie van de organisatie die dat het MAC adres heeft toegekend aan de adapter.

Het is een onzin adres (de OUI bestaat niet), maar verder dan dat is er geen enkel probleem. Een MAC adres moet gewoon uniek zijn binnen het lokale netwerk. Dat is het enige wat belangrijk is.

De laatste keer dat ik met MAC adressen aan de slag ging in low level netwerk software was het toch echt een probleem als je met onzin adressen aan kwam zetten. Als een MAC adres niet voor zou moeten komen forwarden we het frame gewoon niet en eindigt het bij de fysieke poort waar het binnen kwam. We hebben toen voornamelijk IANA's lijstjes aangehouden: http://www.iana.org/assig...rs/ethernet-numbers.xhtml

Als een poort geen MPLS mocht hebben ging alles tussen 80-00-00 en 8F-FF-FFgewoon de bak in. Natuurlijk was dat alleen als er een 01-00-5E prefix op zat, maar dan nog, MAC adressen zijn niet zomaar een eindeloze identifier die je lukraak kan gebruiken. Daar ging het voornamelijk om.

Dat het in een thuisnetwerk met thuissoftware en een thuissituatie misschien geen donder uit maakt doet daar niet aan af. Dat het voor dit topic niet relevant is kan kloppen.

[Microkid]

Eerste hit op Google: http://forum.giga-byte.co.uk/index.php?topic=16105.0

En hier een oplossing om via een bootable USB stick je Intel NIC van een nieuw mac adres te voorzien: https://forum-en.msi.com/index.php?topic=266441.0

[Voor 51% gewijzigd door Microkid op 06-08-2016 21:55]

[Flumble]

Bedankt voor de hulp zover!

nelizmastr schreef op zaterdag 06 augustus 2016 @ 19:18:
Vraagje: hoe erg is het dat je deze MAC hebt?

Dat hangt ervan af hoe grondig het spoofen van een MAC-adres is.
Voor programma's die lokaal draaien maakt het me niet uit welk MAC-adres ze zien (het ergste zou het heractiveren van windows zijn), maar het is in dit geval vrij belangrijk dat de computer een vast, uniek MAC-adres rapporteert aan het netwerk.
Als iemand kan bevestigen dat het instellen van een Network Address/Locally Administrated Address/Physical Address (waarom zou je het veld ook gewoon MAC-adres noemen⸮) in de adapterinstellingen daarvoor genoeg is, is dat voor nu een voldoende antwoord.

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:22:
[...]
Ik weet niet waarvoor je RMA nodig was, maar het lijkt er op dat iemand je BIOS geflasht heeft en alle board-specific data gewist heeft.

Voorheen deed het bord helemaal niks, dus het is een vooruitgang. Maar ik vrees dat ik geholpen ben door een incompetente vakantiekracht bij gigabyte, want hij is ook teruggekomen met franse handleiding en zonder I/O shield.

johnkeates schreef op zaterdag 06 augustus 2016 @ 19:29:
Voor het oplossen: je hebt firmware van AMI, je kan met een AMI tool het MAC adres (en ook andere gegevens) wijzigen. Een is AMIBCP, en een andere is AMITool. Voor sommige (oudere) firmwares kon het met AFU, maar dat is in dit geval waarschijnlijk niet meer zo.

AMIBCP accepteert mijn bios-dump helaas niet en voor AMITool vind ik alleen louche downloadsites (heb jij iets betrouwbaars?).
Nou kan ik met een hexeditor wel 888888888788 vervangen, maar het staat zowel op een offset van 0x1000 als 0x2000 en niet met een mooie beschrijving of documentatie dat er nog ergens een checksum aangepast moet worden.

[johnkeates]

Flumble schreef op zondag 07 augustus 2016 @ 16:42:
Bedankt voor de hulp zover!

[...]


AMIBCP accepteert mijn bios-dump helaas niet en voor AMITool vind ik alleen louche downloadsites (heb jij iets betrouwbaars?).
Nou kan ik met een hexeditor wel 888888888788 vervangen, maar het staat zowel op een offset van 0x1000 als 0x2000 en niet met een mooie beschrijving of documentatie dat er nog ergens een checksum aangepast moet worden.

BCP wil alleen met 'verse' images werken, een dump gaat 'm niet worden. Je kan een BIOS update bij Gigabyte downloaden en daar dan in AMIBCP de bewerkingen doen.

Voor de hex edits: er moet inderdaad een checksum aangepast worden, maar soms kan je ook zonder complete flash de data schrijven. AFUDOS kon het in elk geval, misschien dat je het beste een recente versie kan proberen?

Handleiding: https://www.bios-mods.com...ios-flash-tool-AFUDOS-EXE
er is een directe optie om beide adressen aan te passen (er zijn er twee, de bootblock heeft z'n eigen zodat je PXE boot kan doen terwijl je BIOS corrupt is waarom dat nodig was om te implementeren weet ik niet, maar het zit er dus in).

Een goed MAC adres instellen dat correleert met wat er op de sticker staat lijkt me vooral netjes. Lokaal een MAC spoofen via de driver kan ook wel, en zal in theorie zodra het OS opgestart is ook wel werken. Voor magic packets moet je dan weer je 'foute' adres gebruiken als je Wake-On-Lan wil doen.

[Voor 29% gewijzigd door johnkeates op 07-08-2016 16:51]

[Flumble]

johnkeates schreef op zondag 07 augustus 2016 @ 16:49:
BCP wil alleen met 'verse' images werken, een dump gaat 'm niet worden. Je kan een BIOS update bij Gigabyte downloaden en daar dan in AMIBCP de bewerkingen doen.

Helaas, AMIBCP 3.46 accepteert ook geen verse image.

Ik ben niet van plan wake-on-lan of andere netwerkfeatures zoals PXE te gebruiken tijdens het booten, dus als MAC-spoofen betrouwbaar werkt zodra het OS geladen is, laat ik het knoeien met de bios image (nu) voor wat het is.

[KrazyJay]

Even een dooddoener, maar wat zegt Gigabyte hiervan? 040-2902088.

[Flumble]

Goed, reactie van het netwerkbeheer is ook dat het spoofen van het MAC-adres zou moeten werken. En dat is (op dit moment i.i.g.) ook het geval.
Zodra ik wat minder afhankelijk ben van deze computer, zal ik AFUDOS proberen of nogmaals een RMA openen (dan komt hopelijk ook weer een I/O-shield terug).

Bedankt voor alle hulp!

KrazyJay schreef op zondag 07 augustus 2016 @ 18:58:
Even een dooddoener, maar wat zegt Gigabyte hiervan? 040-2902088.

Hmm, wat is de kans dat ik iemand met kennis van zaken aan de lijn krijg én dat het antwoord iets anders is dan "open een nieuwe RMA"?

[Hero of Time]

Flumble schreef op dinsdag 09 augustus 2016 @ 23:18:
[...]

Hmm, wat is de kans dat ik iemand met kennis van zaken aan de lijn krijg én dat het antwoord iets anders is dan "open een nieuwe RMA"?

Ik denk niet dat je die kans in hele procenten kan uitdrukken.

[KrazyJay]

Ik heb anders goede ervaringen met dat nummer. Soms moet je een beetje doordrammen, maar ik heb een probleem met een winkel op kunnen lossen door direct met Gigabyte via dat nummer te communiceren. Heb je het al geprobeerd?