Gluon und die WAN-MAC

Das mit dem nicht schlucken von nicht allen MAC Adressen sollte doch auch kein Problem sein wenn die MAC bei bestehenden Geräten in der Config mit abgespeichert wird. Wenn keine MAC in der Config hinterlegt ist, z.B. bei Neugeräten kann dann ja nach dem neuen Verfahren die MAC generiert werden. So sollten doch alt Geräte keine neue bekommen und Neugeräte nicht mit dem alten Problem betroffen sein.

Richtig? So würde ich es machen.

Genau das ist die aktuelle Überlegung. Problem nur: von 0.7.4/0.7.5 auf 0.8.x (bzw. 0.7.9 als 0.8-Beta) ändert sich schon die WAN-MAC, und bislang hat keine Firmware die benutzte WAN-MAC weggeschrieben. Für 0.7.4 könnte ich ein Vor-Update-Update rausschicken, welches die atuelle MAC in die Config schreibt, und in 0.7.9/0.8.x würde diese dann in Config- und Normalmodus benutzt (bzw., falls nicht vorhanden, die verwendete ebenfalls für spätere Nutzung weggeschrieben).

Problem nur: die Entwicklungsversion von 0.7.4 ist ca. 100 Builds neuer als die zuletzt als Stable ausgerollte — und für Knoten auf 0.5.x (2) und 0.7.5 ("'n paar") geht das nicht (keine Build-Umgebung mehr).

Aber es scheint die beste aller schlechten Lösungen zu sein :wink:

Ja,

und die Frage ist wie viel von den alten Knoten währen betroffen von einen Problem durch MAC Adressänderung?

Das ist unbekannt. Ich weiß von mind. 1 Autohaus, ggf. Ketten (Bäckereien, Schenke, …) und Verwaltungen, IT-affine Privatleute, …

Die 0.7.5 gerade gezählt sind 56 schon arg viel; hmm …

Aber das vor Update für 0.7.4 währe kein Problem meinst du.

Naja, es stellte sich heraus, eine Kiste bei Hetzner ist völlig überlastet (daher auch die Ausfälle an der Müritz heute morgen und die sporadische Unerreichbarkeit des Forums), halt die, die das Build-System “für 0.7.4” beherbergt :frowning:

(2 GB-VMs fressen 6 GB RAM, das ist “etwas” doof, wenn man die 16 GB anhand des zugewiesenen Speichers verplant hat => Server hat 6-8 GB auf Platte ausgelagert, auf zwei IDE-Platten im Software-RAID-1, um genau zu sein, entsprechend rottig ist die Performance :frowning: Wohl mal Zeit für Kernel- bzw. gar Distributionsupdate dort — nach 539 Tagen auch an der Zeit.)

Ja, 0.7.5 war die Zwischenversion für den 841v10 (+ v11?). Basiert, wie die kommende 0.8, auf OpenWRT Chaos Calmer (statt, wie 0.7.4, auf OpenWRT Barrier Breaker, der Vorgängerversion). Sysupgrade von neuerer auf ältere OpenWRT-Basis geht nicht, daher blieb 0.7.5 stehen.

0.7.4~215 hat entsprechende Patches drin, die (auf 0.7.9er Testknoten) funktionierten:

root@33332-Testknoten-81ec:~# uci show network.wan
network.wan=interface
network.wan.ifname='eth1'
network.wan.multicast_querier='0'
network.wan.peerdns='0'
network.wan.auto='1'
network.wan.type='bridge'
network.wan.proto='dhcp'
network.wan.macaddr='e8:94:f6:90:81:ed'
root@33332-Testknoten-81ec:~# echo $(lua -e 'print(require("gluon.util").generate_mac(0))')
7e:1d:c4:3c:df:10
root@33332-Testknoten-81ec:~# /lib/gluon/upgrade/999-save-wan-mac.sh
root@33332-Testknoten-81ec:~# echo $(lua -e 'print(require("gluon.util").generate_mac(0))')
e8:94:f6:90:81:ed

Wäre toll, wenn jemand das mal ausprobieren könnte mit einem 0.7.4er Knoten, der die stable drauf hat. Nach dem sysugrade sollten dann in Normal- wie Config-Mode nur noch die zum Installationszeitpunkt generierte WAN-MAC verwendet werden, ebenso sollte diese nach einem Upgrade auf 0.7.9 identisch bleiben. (Und, Kür, eine andere sein als bei Neuinstallation jenes Knotens mit 0.7.9; aber auch dort sollte die einmal generierte in Config- und Normalmode nicht mehr wechseln.)

Werde es vermutlich Donnerstag erst richtig durchtesten können.

Gibt es überhaupt eben Befehl um ein spezielles Image einzuspielen? Oder muss man immer über das Web Interface im Configuration Mode gehen?

Gibt es überhaupt eben Befehl um ein spezielles Image einzuspielen? Oder muss man immer über das Web Interface im Configuration Mode gehen?

Klar. Auf den Knoten per ssh gehen und dann:

cd /tmp
wget http://firmware.4830.org/rawhide/sysupgrade/gluon-ffgt-VERSION-$(lua -e 'print(require("platform_info").get_image_name())')-sysupgrade.bin
sysupgrade -v gluon-<TAB>

“VERSION” durch die Wunschversion ersetzen, also z. B. “0.7.4~215”. Alternativ direkt den kompletten Pfad für wget von firmware.4830.org per cut&paste übernehmen :wink:

Habe gerade einen Knoten akualisisiert, der schon die 0.7.4~210 drauf hate. Sollte doch prinzipell auch kein Problem sein oder?

Update lief druch, MAC ist auch geblieben. habe dann per SSH in den Config Mode gebootet. Hier hat er mich dann ausgesperrt. Kann ihn nicht mehr anpingen, kein SSH und kein Webinterface, scheinbar auch laut FritzBox eine andere MAC genommen.

Siehe

Vorher:
PC-192-168-XXX-167 192.168.XXX.167 C4:6E:1F:7A:AC:4D

Nachher
PC-192-168-XXX-135 192.168.XXX.135 C6:6F:1F:63:0E:F0

weiter kann ich gerade leider nicht schauen, da ich zu dem Standort von hier aus nur einen VPN Zugang habe.

Was zu den Knoten noch zu sagen ist, er hat die Option gesetzt LAN Ports mit WAN Ports bridgen. Evtl. zickt deshalb der Config Mode. (Evtl. könnte man einen automatischen Reboot einbauen im Configmode nach 1 Std.; länger sollte man ihn ja eigentlich nicht brauchen)


OK, war mal mutig, habe den zweiten Knoten der kein Bridge zwischen WAN und LAN Ports hat auch geupdatet und im Config Mode gesetzt. Selbe spielchen. In der FritzBox gibt es eine andere MAC und IP zu sehen, wieder C4:… Drauf kommen tue ich auch wieder nicht. Da muss ich morgen wohl mal rebooten.

Was noch interessant ist,

echo $(lua -e ‘print(require(“gluon.util”).generate_mac(0))’)
lua: error loading module ‘gluon.util’ from file ‘/usr/lib/lua/gluon/util.lua’:
/usr/lib/lua/gluon/util.lua:73: ‘end’ expected (to close ‘if’ at line 71) near 'if’
stack traceback:
[C]: ?
[C]: in function ‘require’
(command line):1: in main chunk
[C]: ?

Habe den Befehl von dir direkt nach dem Update eingeben. Da hätte ja eigentlich eine MAC ausgegeben werden müssen, oder?

Yepp. Und da die Funktion im Config-Mode aufgerufen wird, geht’s da evtl. nicht weiter.

Fsck, im 0.7.4er Tree fehlte tatsächlich ein “end”, das im 0.7.9er da ist :frowning: Sorry.

  OS: Barrier Breaker, r46287             FW: 0.7.4~210                       
  HW: Westmere E56xx/L56xx/X56xx (Nehalem-C)                              
root@33332-FWTest-f26e:~# cd /tmp
root@33332-FWTest-f26e:/tmp# wget http://firmware.4830.org/rawhide/sysupgrade/gluon-ffgt-0.7.4~215-x86-kvm-sysupgrade.img.gz
Connecting to firmware.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
gluon-ffgt-0.7.4~215 100% |*******************************|  4210k  0:00:00 ETA
root@33332-FWTest-f26e:/tmp# head -6 /etc/config/system 

config system
        option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option hostname '33332-FWTest-f26e'

config timeserver 'ntp'
root@33332-FWTest-f26e:/tmp# sysupgrade -v gluon-ffgt-0.7.4~215-x86-kvm-sysupgrade.img.gz 

Reboot:

root@33332-FWTest-f26e:~# head -6 /etc/config/system

config system
        option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option hostname '33332-FWTest-f26e'
        option staticwanmac '52:55:00:14:f2:6e'

Aber:

root@33332-FWTest-f26e:~# echo $(lua -e 'print(require("gluon.util").generate_mac(0))')
lua: error loading module 'gluon.util' from file '/usr/lib/lua/gluon/util.lua':
        /usr/lib/lua/gluon/util.lua:73: 'end' expected (to close 'if' at line 71) near 'if'
stack traceback:
        [C]: ?
        [C]: in function 'require'
        (command line):1: in main chunk
        [C]: ?

Wie berichtet und somit erwartet :frowning:

root@33332-FWTest-f26e:~# uci get gluon-setup-mode.@setup_mode[0].enabled
0
root@33332-FWTest-f26e:~# uci set gluon-setup-mode.@setup_mode[0].enabled=1
root@33332-FWTest-f26e:~# uci commit
root@33332-FWTest-f26e:~# uci get gluon-setup-mode.@setup_mode[0].enabled
1
root@33332-FWTest-f26e:~# reboot

Der Knoten kommt im Config-Modus zwar hoch (Zugriff per http/telnet möglich), wenn Du aber im Web von der Geolocate-Seite wegwillst, kracht es:

/usr/lib/lua/luci/dispatcher.lua:190: Failed to execute cbi dispatcher target for entry '/gluon-config-mode/wizard'.
The called action terminated with an exception:
/usr/lib/lua/luci/ccache.lua:22: error loading module 'gluon.util' from file '/usr/lib/lua/gluon/util.lua':
	/usr/lib/lua/gluon/util.lua:73: 'end' expected (to close 'if' at line 71) near 'if'
stack traceback:
	[C]: in function 'assert'
	/usr/lib/lua/luci/dispatcher.lua:190: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:63: in function </usr/lib/lua/luci/dispatcher.lua:63>

Sorry; ohne telnet auf den Knoten kommste da nicht weiter. Wenn Du auf dem Knoten bist …

vi /usr/lib/lua/gluon/util.lua
:73<RETURN>
iend<RETURN>
<ESC>ZZ

… eingeben.

Das sollte dann so aussehen (vor ESC + ZZ zum speichern):

   if f==1 and i==0 then
    if staticwanmac then
      return staticwanmac
    end
if wan_mac_static == '1' then
      return(generate_mac_2014_3(f, i))
    end
    -- Hardcoded for now, FIXME. Doesn't even work :(
    if string.match(hostname, 'HolidayInnExpress') then

Alternativ einfach rebooten (“reboot” bzw. Power-Cycle). Knoten sollten dann wieder unter alter IP hochkommen (zumindest meine VM tat das) und dann …

root@33332-FWTest-f26e:~# cd /tmp
root@33332-FWTest-f26e:/tmp# wget http://firmware.4830.org/rawhide/sysupgrade/gluon-ffgt-0.7.4~216-x86-kvm-sysupgrade.img.gz
Connecting to firmware.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
gluon-ffgt-0.7.4~216 100% |*******************************|  4210k  0:00:00 ETA
root@33332-FWTest-f26e:/tmp# sysupgrade -v gluon-ffgt-0.7.4~216-x86-kvm-sysupgrade.img.gz 

… bzw. natürlich Image das für Dein Gerät.

Gegenprobe (FW 0.7.4/Gluon v2015.1 nutzt zwei Argumente bei “generate_mac()”):

root@33332-FWTest-f26e:~# echo $(lua -e 'print(require("gluon.util").generate_mac(1,0))')
52:55:00:14:f2:6e

Und auch im Config-Mode wird die MAC nun beibehalten:

root@33332-FWTest-f26e:~# uci set gluon-setup-mode.@setup_mode[0].enabled=1
root@33332-FWTest-f26e:~# uci commit
root@33332-FWTest-f26e:~# reboot ; exit
Connection to 192.168.122.218 closed.
wusel@ysabell:~$ ping 192.168.122.218
PING 192.168.122.218 (192.168.122.218) 56(84) bytes of data.
64 bytes from 192.168.122.218: icmp_seq=9 ttl=64 time=0.362 ms
64 bytes from 192.168.122.218: icmp_seq=10 ttl=64 time=0.162 ms
^C […]
wusel@ysabell:~$ telnet 192.168.122.218
Trying 192.168.122.218...
Connected to 192.168.122.218.
Escape character is '^]'.

… als auch wieder im Normalmodus:

root@33332-FWTest-f26e:/# 
telnet> close
Connection closed.
wusel@ysabell:~$ ping 192.168.122.218
PING 192.168.122.218 (192.168.122.218) 56(84) bytes of data.
64 bytes from 192.168.122.218: icmp_seq=9 ttl=64 time=0.382 ms
64 bytes from 192.168.122.218: icmp_seq=10 ttl=64 time=0.154 ms
64 bytes from 192.168.122.218: icmp_seq=11 ttl=64 time=0.242 ms
64 bytes from 192.168.122.218: icmp_seq=12 ttl=64 time=0.262 ms
64 bytes from 192.168.122.218: icmp_seq=13 ttl=64 time=0.267 ms
^C
--- 192.168.122.218 ping statistics ---
13 packets transmitted, 5 received, 61% packet loss, time 12061ms
rtt min/avg/max/mdev = 0.154/0.261/0.382/0.074 ms
wusel@ysabell:~$ ssh root@192.168.122.218 uptime
sh: /usr/bin/X11/xauth: not found
 23:56:06 up 0 min,  load average: 0.00, 0.00, 0.00

Sorry für den Ausfall :frowning:

[quote=“Thomas, post:19, topic:452”]
Update lief druch, MAC ist auch geblieben. habe dann per SSH in den Config Mode gebootet. Hier hat er mich dann ausgesperrt. [/quote]

Ja, siehe oben, denn die Übernahme der (schon gespeicherten) WAN-MAC klappt halt wegen des Fehlers nicht in 0.7.4~215 :frowning:

Im Setup-Mode sollte er per Telnet erreichbar sein; und per Web, aber beides eben unter der neuen IP.

Ich glaube, ich habe einen Weg gefunden, ohne »Interims-Update« auszukommen:

  OS:                                     FW: 0.7.4~118                       
  HW: Westmere E56xx/L56xx/X56xx (Nehalem-C)                              
root@33332-FWTest-f26e:~# cd /tmp
root@33332-FWTest-f26e:/tmp# wget http://firmware.4830.org/rawhide/sysupgrade/gluon-ffgt-0.7.9~107-x86-kvm-sysupgrade.img.gz
Connecting to firmware.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
gluon-ffgt-0.7.9~107 100% |*******************************|  4723k  0:00:00 ETA
root@33332-FWTest-f26e:/tmp# head -6 /etc/config/system

config system
        option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option hostname '33332-FWTest-f26e'

config timeserver 'ntp'
root@33332-FWTest-f26e:/tmp# ip addr show br-wan
6: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 52:55:00:14:f2:6e brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.218/24 brd 192.168.122.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fe80::5055:ff:fe14:f26e/64 scope link 
       valid_lft forever preferred_lft forever
root@33332-FWTest-f26e:/tmp# sysupgrade -v gluon-ffgt-0.7.9~107-x86-kvm-sysupgra
de.img.gz 
Saving config files...
[…]
Upgrade completed
Rebooting system...
packet_write_wait: Connection to 192.168.122.218: Broken pipe

Okay, 0.7.4~118 auf 0.7.9~107 aktualisiert. Und, tut das?

wusel@ysabell:~$ ssh root@192.168.122.218 
sh: /usr/bin/xauth: not found
[…]
  OS: Chaos Calmer, r49389                FW: 0.7.9~107                       
  HW: Westmere E56xx/L56xx/X56xx (Nehalem-C)                              

root@33332-FWTest-f26e:~# ip addr show br-wan
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 52:55:00:14:f2:6e brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.218/24 brd 192.168.122.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fe80::5055:ff:fe14:f26e/64 scope link 
       valid_lft forever preferred_lft forever
root@33332-FWTest-f26e:~# head -6 /etc/config/system

config system
        option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option hostname '33332-FWTest-f26e'
        option staticwanmac '52:55:00:14:f2:6e'

Ja! :wink: Okay, und wenn man von 0.7.9 in den Config-Mode geht?

root@33332-FWTest-f26e:~# uci set gluon-setup-mode.@setup_mode[0].enabled=1
root@33332-FWTest-f26e:~# uci commit
root@33332-FWTest-f26e:~# uci get gluon-setup-mode.@setup_mode[0].enabled
1
root@33332-FWTest-f26e:~# reboot
root@33332-FWTest-f26e:~# Connection to 192.168.122.218 closed.
wusel@ysabell:~$ telnet 192.168.122.218 
Trying 192.168.122.218...
Connected to 192.168.122.218.
[…]
  OS: Chaos Calmer, r49389                FW: 0.7.9~107                       
  HW: Westmere E56xx/L56xx/X56xx (Nehalem-C)                              
root@33332-FWTest-f26e:/# Connection closed by foreign host.
wusel@ysabell:~$ ssh root@192.168.122.218 uptime
sh: /usr/bin/xauth: not found
 02:47:12 up 0 min,  load average: 0.00, 0.00, 0.00
wusel@ysabell:~$ 

Im Config-Mode im Web den Branch auf “rawhide” gesetzt, durchgeklickt, es kam zum Reboot … und der Knoten blieb bei seiner MAC/seiner IP.

0.7.9~107 ist auf http://firmware.4830.org/ verfügbar; bitte, wo möglich, gegen 0.7.4~118- und 0.7.5~29-Basisfirmware testen …

Gerade versucht die zwei 841v9 von gestern upzudaten. Der erste scheint die MAC zu behalten. Hat sich aber aus welchen Gründen auch immer eine neue IP geholt, schon beim zweiten Reboot im normalen Modus. Bisher weiß ich nicht warum, evtl. Zufall. In den Config Mode will er mich aus welchen Gründen auch immer gerade nicht rein lassen. Muss das doch direkt vor Ort mal testen. Vermute das ich mit den Notfall IPs drauf kommen würde. Dann kann ich mehr heraus finden.

Der zweite Knoten lässt sich gerade nicht Updaten, obwohl es auch ein 841v9 ist. Vermutlich zu weniger Speicher, oder?

Habe noch einen WR1043N/ND v3 mit 0.7.4.210 im Zugriff. Da muss ich aber dann für den Configmode einmal vorbei fahren. Da keinen VPN Zugriff.

Habe gerade meinen ArcherC7 ein Update verpasst. Er hatte allerdings schon das 0.7.9 drauf. Ihn konnte ich nach dem Update auf die 107 in den Config Mode bringen und MAC und IP sind geblieben.

OK, der zweite AP wollte nicht weil ich einen Tippfehler beim Update hatte.

Hat nun auch das Update drin, aber das selbe wie beim ersten. MAC bleibt, IP hat sich geändert. (Im Normalen Modus)

Vorher
PC-192-168-XXX-131	192.168.XXX.131	C6:6F:1F:7A:AC:4C	LAN 4 mit 100 Mbit/s 		
PC-192-168-XXX-135	192.168.XXX.135	C6:6F:1F:63:0E:F0	LAN 1 mit 100 Mbit/s 	


Nachher
PC-192-168-XXX-104	192.168.XXX.104	C6:6F:1F:7A:AC:4C	LAN 4 mit 100 Mbit/s 		
PC-192-168-XXX-121	192.168.XXX.121	C6:6F:1F:63:0E:F0	LAN 1 mit 100 Mbit/s

Das ganze mit einer FritzBox 7270 Firmware 6.06

Habe einen 841v10 auf 0.7.5~29 gebracht, und von dort auf 0.7.9~107 sysupgraded. Alles fein, außer:

root@33332-FW-Test-cc9c:~# for i in /lib/gluon/core/sysconfig/*_ifname ; do echo
 $i ; cat $i ; echo ; echo ; done
/lib/gluon/core/sysconfig/lan_ifname
eth0

/lib/gluon/core/sysconfig/setup_ifname
eth0

/lib/gluon/core/sysconfig/wan_ifname
eth1

Sprich: sysupgrade tut, aber die alte Einstellung, Setup über LAN statt WAN zu fahren, wurde nicht geändert. Oops. Evtl. ist das auch der Grund für Deine unterschiedlichen IPs, @Thomas? Hast Du die Knoten ggf. per WAN und LAN direkt an die FB angebunden? EDIT: steht ja da oben :wink: MAC bleibt auf LAN und WAN gleich (da damals die LAN-IP genommen wurde) …

Das was heute morgen noch aufgefallen ist:
Ein AP hat die Konfiguration Bridge LAN Ports to WAN Port. Die will scheinbar nicht mehr richtig. Auf jeden Fall konnte ich die geräte dahinter nicht mehr erreichen.
Per SSH und brctl show, sah es auf den resten Blick so aus als ob die Bridge eingerichtet ist. Werde den AP mal persönlich besuchen fahren und einmal drauf schauen. Weil per VPN alles immer etwas doof.

Hmm, wo war die Einstellung denn? Die Patches für WLAN-Uplink fehlen noch, wie ich bei einem meiner Testknoten feststellen mußte. (Das waren Celler Anpassungen, die direkt im Gluon-Code gemacht wurde. sigh Es rächt sich eben alles ;))

Due Option ist im Webinterface direkt möglich. WAN auf LAN Ports oder so heist die.

Habe gerade einmal auf dem Knoten geschaut, dort ist im moment auf den Switch Ports nichts zugeordnet worden.

Ich mache jetzt erst einmal nichts. Und bei dem letzten Knoten den ich aktuell noch auf 0.7.4.210 am laufen habe warte ich auch noch.

Oder brauchst du aktuell noch weitere erkenntnisse?

Nee, ich werde v9 und v10 auf 7.4.stable und 7.5.stable factory flashen und von dort erstmal testen. Ziemlich viele bewegliche Teile diesmal :frowning: