You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 19, 2019. It is now read-only.
Hallo,
wir sollten die MAC Adressen Vergabe noch überdenken und verbessern.
Hier mein Vorschlag (getestet):
Für unsere "specialnodes" (mit IPv4 Adresse 10.80.y.z) bilden wir eine "primary_mac" der Form:
10:00:00:XX:YY:ZZ
mit XX = hex (80) also "50"
mit YY = hex von y
mit ZZ = hex von z
für z.B. IPv4 = 10.80.26.123
primary_mac = 10:00:00:50:1A:7B
für z.B. IPv4 = 10.80.0.15
primary_mac = 10:00:00:50:00:0F
Damit ist die MAC für das interface bat0 festgelegt!
Auch die "bridge" vor bat0 hat damit diese MAC.
Für das fastd interface:
-- (4, 0): mesh VPN
für z.B. IPv4 = 10.80.0.15
primary_mac = 10:00:00:50:00:0F
fastd_mac: (exakt nach gluon Bildungsregel)
10:00:00:50:00:0F
02 # LAA Bit setzen!
12:00:00:50:00:0F # LAA
+4 # im zweiten Byte 4 addieren (8 Bit), ggf wrap around.
12:04:00:50:00:0F # LAA ==> network.mesh_vpn.macaddr
Damit würden unsere "specialnodes" MAC betreffend genauso wie die normalen gluon nodes behandelt. ffmap u.ä. gehen dann ohne Probleme.
Servus
Christian
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hallo,
wir sollten die MAC Adressen Vergabe noch überdenken und verbessern.
Hier mein Vorschlag (getestet):
Damit würden unsere "specialnodes" MAC betreffend genauso wie die normalen gluon nodes behandelt. ffmap u.ä. gehen dann ohne Probleme.
Servus
Christian
The text was updated successfully, but these errors were encountered: