1043 v4 MAC Adressen

Tim Niemeyer tim at tn-x.org
Fr Feb 10 10:26:22 CET 2017


Hi

Am 10. Februar 2017 10:16:42 MEZ schrieb Christian Dresel <fff at chrisi01.de>:
>Hi
>
>On 10.02.2017 09:55, Tim Niemeyer wrote:
>> Hi
>> 
>> Am 10. Februar 2017 08:28:12 MEZ schrieb Christian Dresel
><fff at chrisi01.de>:
>>> Hi
>>>
>>> On 09.02.2017 22:09, Tim Niemeyer wrote:
>>>> Hi
>>>>
>>>> Am Montag, den 06.02.2017, 10:27 +0100 schrieb Christian Dresel:
>>>>> Hi
>>>>>
>>>>> ich hab jetzt grade mal ein nacktes LEDE geflasht, da zeigt sich
>das
>>>>> ganze so:
>>>>>
>>>>> br-lan, eth0 und eth0.1 sowie ein angelegtes WLAN (wlan0) haben
>alle
>>> die
>>>>> gleiche MAC, nämlich die, die hinten drauf steht, in meinen Fall:
>>>>> 84:16:F9:5B:86:A8
>>>>>
>>>>> eth0.2, also der WAN Port hat dann die MAC +1 am Ende also in
>meinen
>>> Fall:
>>>>> 84:16:F9:5B:86:A9
>>>>
>>>> Ich hab mir das grad im LEDE angeschaut. Die MAC fürs WAN holt der
>>> sich
>>>> aus dem Flash (config Bereich vom Router-Hersteller).
>>>
>>> und wie komm ich mit unserer Firmware an die MAC ran? Ich find kein
>>> Script das die bei uns irgendwo überschreibt, sie wird einfach nur
>> 
>> mtd_get_mac_binary config 0x1017c
>> 
>> Siehe lede: target/linux/ar71xx/base-files/etc/board.d/02_network.sh
>
>woher du das Zeug immer nur weißt... ich bin erstaunt:
>
>root at 1043v4test:/tmp# cat test
>#!/bin/sh
>. /lib/functions/system.sh
>. /lib/functions/uci-defaults.sh
>. /lib/ar71xx.sh
>
>wan_mac=$(mtd_get_mac_binary config 0x1017c)
>echo $wan_mac
>root at 1043v4test:/tmp# ./test
>84:16:f9:5b:86:a9
>root at 1043v4test:/tmp#
>
>ist das dann ok, wenn ich mir die MAC mit so einen "Miniscript" raus
>hole und das dann irgendwo (wo genau muss ich erst noch gucken)
>reinbastel?


Ich befürchte, dass das aktuell die einzige Lösung is, welche wir uns leisten können. Richtig schön isses ned, aber wir haben eh noch schlimmere Verbrechen in unserem Krams. Und wir können ja auch ned das ganze OpenWRT neu erfinden.

Tim


>mfg
>
>Christian
>
>> 
>> 
>> 
>>> keinen Interface zugewiesen daher hab ich sie auch nicht zur
>Verfügung.
>>> Da ich jetzt weiß das sie am Ende +1 ist, könnte ich sie daraus
>>> generieren aber ist das schön?
>> 
>> Nein, weil es keine Garantie gibt, dass das immer so ist.
>> 
>> Tim
>> 
>>>
>>>>
>>>> So wie es aussieht hast du also zwei echte MACs. Bei beiden kann
>man
>>>> noch das Private Bit Kippen. Also hast du vier! :) Das reicht
>>>> eigentlich, oder?
>>>> - ethmesh (muss im batman und l2 Netz eindeutig sein)
>>>> - adhoc (muss im batman und l2 Netz eindeutig sein)
>>>> - br-mesh (ich glaub die muss auch eindeutig sein, weil l2 Netz?)
>>>> - ethclient (steckt in br-mesh, ansonsten dumm, daher irrelevant)
>>>> - ap (steckt in br-mesh, ansonsten dumm, daher irrelevant)
>>>> - wan (kann doppelt vergeben werden, steckt nur im vpn [ist andere
>l2
>>>> Netz])
>>>> - vpn (wird gewürfelt)
>>>> - bat (wird gewürfelt)
>>>>
>>>> Hab ich was vergessen oder verdreht?
>>>>
>>>> Daraus ergibt sich, dass du drei MACs brauchst:
>>>> - ethmesh
>>>> - adhoc
>>>> - br-mesh
>>>
>>> sicher das ich 3 brauche? Aktuell hab ich es mit den 2 Adressen die
>ich
>>> habe (die wo unten drauf steht und diese mit gekippten Bit) so
>gelöst:
>>>
>>> root at 1043v4test:~# ifconfig | grep 84:16:F9:5B:86:A8
>>> br-mesh   Link encap:Ethernet  HWaddr 84:16:F9:5B:86:A8
>>> eth0      Link encap:Ethernet  HWaddr 84:16:F9:5B:86:A8
>>> eth0.1    Link encap:Ethernet  HWaddr 84:16:F9:5B:86:A8
>>> eth0.2    Link encap:Ethernet  HWaddr 84:16:F9:5B:86:A8
>>> w2mesh    Link encap:Ethernet  HWaddr 84:16:F9:5B:86:A8
>>> root at 1043v4test:~# ifconfig | grep 86:16:F9:5B:86:A8
>>> eth0.3    Link encap:Ethernet  HWaddr 86:16:F9:5B:86:A8
>>> w2ap      Link encap:Ethernet  HWaddr 86:16:F9:5B:86:A8
>>> root at 1043v4test:~#
>>> (was hier fehlt wird sowieso generiert)
>>>
>>> ich muss nochmal alles intensiv testen bisher hab ich das ganze nur
>>> recht oberflächig getestet. Aber du hast natürlich recht, wenn ne 2.
>>> MAC
>>> zur Verfügung steht, sollte man die nutzen wenn ich weiß wie ich an
>die
>>> ran komme ;)
>>>
>>> mfg
>>>
>>> Christian
>>>
>>>>
>>>> Tim
>>>>
>>>>>
>>>>> Ist das bei den anderen 1043er (v2 und v3) ebenso oder ist der v4
>da
>>> was
>>>>> "spezielles"? Warum ich frage ist, weil ich LEDE nie auf den 1043
>>> v2/v3
>>>>> gesehen habe. Mir stellt sich nun die Frage, ist der 1043 v4 da
>>> anders
>>>>> als der v2/v3 oder wurde mit dem LEDE was an den MACs geändert?
>>>>> Im ersteren Fall muss ich das ganze halt irgendwie anpassen, im 2.
>>> Fall
>>>>> sollten wir LEDE dringend mal auf einen v2/v3 testen, nicht das da
>>> was
>>>>> dann nicht mehr passt.
>>>>>
>>>>> mfg
>>>>>
>>>>> Christian
>>>>>
>>>>> On 18.01.2017 09:45, Christian Dresel wrote:
>>>>>> Hallo zusammen
>>>>>>
>>>>>> brauch mal kurz Rat in Sachen MACs. Ich bastel grad am 1043 v4
>mit
>>> LEDE
>>>>>> (Danke @ RedDog fürs RFC und die Arbeit) herum. Anscheinend
>fehlen
>>> mir
>>>>>> hier eine MAC Adresse.
>>>>>>
>>>>>> Wenn ich mir den 1043 v3 angucken hat er anscheinend 2 MACs die
>>> jeweils
>>>>>> noch gekippt (privat gemacht?) werden können. Beispiel:
>>>>>>
>>>>>>
>>>
>https://monitoring.freifunk-franken.de/routers/57aefede9369c31f138d7c68
>>>>>>
>>>>>> hat:
>>>>>> a4:2b:b0:ad:a4:4d & a4:2b:b0:ad:a4:4c
>>>>>> bzw. jeweills mit a6 am Anfang gekippt.
>>>>>>
>>>>>> Mein 1043 v4 hat aber anscheinend nur eine Beispiel:
>>>>>>
>>>>>>
>>>
>https://monitoring.freifunk-franken.de/routers/587dd38c9369c3063d5975d2
>>>>>>
>>>>>> hat:
>>>>>> 84:16:f9:5b:86:a8
>>>>>> bzw. mit 86 am Anfang gekippt.
>>>>>>
>>>>>> Es gibt kein a7 oder a9 am ende, es ist einfach nie erschienen.
>>> Dadurch
>>>>>> hatte w2mesh und eth0.3 die gleiche MAC (84:16:f9:5b:86:a8) was
>>>>>> natürlich gar nicht funktioniert hat. Ich hab jetzt
>ETHMESHMAC=w2ap
>>>>>> gesetzt. Somit wurde eth0.3 durch die MAC von w2ap ersetzt
>>> (gekippte
>>>>>> MAC) und hat nun eine andere MAC als w2mesh.
>>>>>>
>>>>>> Jetzt hat aber br-mesh und eth0.1 noch die gleiche MAC, dies
>>> scheint
>>>>>> aber auch beim 841 v9 der Fall zu sein (Beispiel:
>>>>>>
>>>
>https://monitoring.freifunk-franken.de/routers/5870a7249369c30650c8282b
>>>>>> war auch bei OpenWRT schon so, hab ich vor dem flashen extra
>>>>>> kontrolliert). Ich geh also mal davon aus das dies kein Problem
>>>>>> darstellt oder?
>>>>>> Wie sieht es mit:
>>>>>> w2ap <-> eth0.3 bzw
>>>>>> w2mesh <-> eth0.1 aus? (ist z.b. hier der Fall, daher geh ich
>davon
>>> aus
>>>>>> ist ok?
>>>>>>
>>>
>https://monitoring.freifunk-franken.de/routers/5821d8169369c3370e441cdf
>>> )
>>>>>> Die dürfen gleich sein?
>>>>>>
>>>>>> Demnach würde der 1043 v4 jetzt so passen wie er ist oder gibt es
>>> Einwände?
>>>>>>
>>>>>> mfg
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> franken-dev mailing list
>>>>> franken-dev at freifunk.net
>>>>>
>http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>>>>


Mehr Informationen über die Mailingliste franken-dev