Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan' option ifname 'br-wan' option transitive '1' option fixed_mtu '1' option proto 'gluon_mesh' option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
ich habe dann mal meine parallel-ssh-superkräfte eingesetzt und gesehen, dass auf folgenden Routern zwar "network.mesh_wan.auto='0'" gesetzt, aber trotzdem "br-wan: active" ist.
Butjadingen-Deichgraf-A20 Butjadingen-Deichgraf-A26 Butjadingen-Deichgraf-A8 Butjadingen-Deichgraf-B1 Butjadingen-Deichgraf-B12 Butjadingen-Deichgraf-B20 Butjadingen-Deichgraf-B22 Butjadingen-Deichgraf-C3 Butjadingen-Deichgraf-D4 Butjadingen-Deichgraf-Schwimmbad Butjadingen-FaM-Butjadingerstr.-51-4 Butjadingen-FaM-Butjadingerstr.-51-5 Butjadingen-FaM-Butjadingerstr.-51-8 Butjadingen-Familien-Aparthotel-Strandhof-1 Butjadingen-Familien-Aparthotel-Strandhof-2 Butjadingen-FaM-Langlütjenring-1 Butjadingen-FaM-Langlütjenring-27 Butjadingen-FaM-Langlütjenring-29 Butjadingen-FaM-Langlütjenring-3 Butjadingen-FaM-Marschenring-14 Butjadingen-FaM-Marschenring-15 Butjadingen-FaM-Marschenring-19 Butjadingen-FaM-Marschenring-20 Butjadingen-FaM-Marschenring-37 Butjadingen-FaM-Marschenring-42 Butjadingen-FaM-Marschenring-48 Butjadingen-FaM-Marschenring-49 Butjadingen-FaM-Marschenring-53 Butjadingen-FaM-Marschenring-63 Butjadingen-FaM-Wattenring-1 Butjadingen-FaM-Wattenring-13 Butjadingen-FaM-Wattenring-16 Butjadingen-FaM-Wattenring-17 Butjadingen-FaM-Wattenring-2 Butjadingen-FaM-Wattenring-20 Butjadingen-FaM-Wattenring-24 Butjadingen-FaM-Wattenring-27 Butjadingen-FaM-Wattenring-28 Butjadingen-FaM-Wattenring-30 Butjadingen-FaM-Wattenring-35 Butjadingen-FaM-Wattenring-36 Butjadingen-FaM-Wattenring-39 Butjadingen-FaM-Wattenring-42 Butjadingen-FaM-Wattenring-43 Butjadingen-FaM-Wattenring-47 Butjadingen-FaM-Wattenring-5 Butjadingen-FaM-Wattenring-6 Butjadingen-FaM-Wattenring-8a Butjadingen-FaM-Wattenring-9 Butjadingen-Ferienwohnung-1 Butjadingen-Ferienwohnung-Schild Butjadingen-Ferienwohnung-Schild-2 Butjadingen-Ferienwohnung-Schild-4 Butjadingen-Ferienwohnung-Schild-5 Butjadingen-Ferienwohnung-Schild-6 Butjadingen-Ferienwohnung-Schild-7 Butjadingen-Freifunk-Test Butjadingen-Gulfshof1 Butjadingen-HofvonOldenburg Butjadingen-HofvonOldenburg1 Butjadingen-WaReDi Ferienwohnung-Frings-3 Ferienwohnung-Frings-4 FF-IBB-HK-Offloader FF-IBB-SchWeg-Offloader FF-IBB-STADT-Offloader05 ffnw-LOHNetz_Braegeler_Ring_15_01 ffnw-LOHNetz_Falkenweg_21 ffnw-LOHNetz_Feuerwehr-Brockdorf_01-NDS ffnw-LOHNetz_Gewerbering_14-15_01 ffnw-LOHNetz_Hamberger_Pickerweg_42_01 ffnw-LOHNetz_Marktstrasse_11_01 ffnw-LOHNetz_Marktstrasse_30_01 ffnw-LOHNetz_Rathaus_01 ffnw-LOHNetz_Schuetzenfest-2017-VPN FF-OL-Bültmann-uplink ff-os-ameos-Gertrudenring12-nds1266 ff-os-ameos-Gertrudenring12-nds1267 ff-os-ameos-Gertrudenring12-nds1268 ff-os-ameos-Gertrudenring12-nds1269 ff-os-ameos-Gertrudenring13-nds1270 ff-os-ameos-Gertrudenring13-nds1271 ff-os-ameos-Gertrudenring13-nds1272 ff-os-ameos-Gertrudenring2-nds1253 ff-os-ameos-Gertrudenring2-nds1254 ff-os-ameos-Gertrudenring3-nds1255 ff-os-ameos-Gertrudenring4-nds1257 ff-os-ameos-Gertrudenring4-nds1258 ff-os-ameos-Gertrudenring5-nds1259 ff-os-ameos-Gertrudenring5-nds1260 ff-os-ameos-Gertrudenring5-nds1261 ff-os-ameos-Gertrudenring7-nds1262 ff-os-ameos-Gertrudenring7-nds1263 ff-os-ameos-Gertrudenring9-nds1264 ff-os-ameos-Gertrudenring9-nds1265 ff-os-ameos-Knollstrasse27-nds1274 ff-os-ameos-Knollstrasse29-nds1275 ff-os-ameos-Knollstrasse29-nds1276 ff-os-ameos-Knollstrasse31-A2-1r-nds1277 ff-os-ameos-Knollstrasse31-A3-2r-nds1278 ff-os-ameos-Knollstrasse31d-nds1906 ff-os-ameos-Knollstrasse31-Lecker-nds1905 ff-os-ameos-Knollstrasse31-Lift-nds1917 ff-os-ameos-Knollstrasse31-S2-4r-nds1281 ff-os-ameos-Knollstrasse31-S5-nds1283 ff-os-ameos-Knollstrasse31-VER-nds1286 ff-os-ameos-Knollstrasse86a-P1-nds1914 ff-os-ameos-Knollstrasse86-G1-nds1909 ff-os-ameos-Knollstrasse86-G2-nds1910 ff-os-ameos-Knollstrasse86-G3-nds1911 ff-os-ameos-Knollstrasse86-IAG-nds1908 ff-os-ameos-Knollstrasse86-PSM1-nds1912 FF-OS-Bramscher-Str-159-Indoor FF-OS-Fokus-eV FF-OS-Peiner5-0R FF-OS-Trattoria-Grani-Ost
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
LG Lorenz
Der gluon-issue auf github hierzu ist: https://github.com/freifunk-gluon/gluon/issues/1263
Am 16.11.2017 um 21:08 schrieb lrnzo via Dev:
Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan' option ifname 'br-wan' option transitive '1' option fixed_mtu '1' option proto 'gluon_mesh' option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
ich habe dann mal meine parallel-ssh-superkräfte eingesetzt und gesehen, dass auf folgenden Routern zwar "network.mesh_wan.auto='0'" gesetzt, aber trotzdem "br-wan: active" ist.
Butjadingen-Deichgraf-A20 Butjadingen-Deichgraf-A26 Butjadingen-Deichgraf-A8 Butjadingen-Deichgraf-B1 Butjadingen-Deichgraf-B12 Butjadingen-Deichgraf-B20 Butjadingen-Deichgraf-B22 Butjadingen-Deichgraf-C3 Butjadingen-Deichgraf-D4 Butjadingen-Deichgraf-Schwimmbad Butjadingen-FaM-Butjadingerstr.-51-4 Butjadingen-FaM-Butjadingerstr.-51-5 Butjadingen-FaM-Butjadingerstr.-51-8 Butjadingen-Familien-Aparthotel-Strandhof-1 Butjadingen-Familien-Aparthotel-Strandhof-2 Butjadingen-FaM-Langlütjenring-1 Butjadingen-FaM-Langlütjenring-27 Butjadingen-FaM-Langlütjenring-29 Butjadingen-FaM-Langlütjenring-3 Butjadingen-FaM-Marschenring-14 Butjadingen-FaM-Marschenring-15 Butjadingen-FaM-Marschenring-19 Butjadingen-FaM-Marschenring-20 Butjadingen-FaM-Marschenring-37 Butjadingen-FaM-Marschenring-42 Butjadingen-FaM-Marschenring-48 Butjadingen-FaM-Marschenring-49 Butjadingen-FaM-Marschenring-53 Butjadingen-FaM-Marschenring-63 Butjadingen-FaM-Wattenring-1 Butjadingen-FaM-Wattenring-13 Butjadingen-FaM-Wattenring-16 Butjadingen-FaM-Wattenring-17 Butjadingen-FaM-Wattenring-2 Butjadingen-FaM-Wattenring-20 Butjadingen-FaM-Wattenring-24 Butjadingen-FaM-Wattenring-27 Butjadingen-FaM-Wattenring-28 Butjadingen-FaM-Wattenring-30 Butjadingen-FaM-Wattenring-35 Butjadingen-FaM-Wattenring-36 Butjadingen-FaM-Wattenring-39 Butjadingen-FaM-Wattenring-42 Butjadingen-FaM-Wattenring-43 Butjadingen-FaM-Wattenring-47 Butjadingen-FaM-Wattenring-5 Butjadingen-FaM-Wattenring-6 Butjadingen-FaM-Wattenring-8a Butjadingen-FaM-Wattenring-9 Butjadingen-Ferienwohnung-1 Butjadingen-Ferienwohnung-Schild Butjadingen-Ferienwohnung-Schild-2 Butjadingen-Ferienwohnung-Schild-4 Butjadingen-Ferienwohnung-Schild-5 Butjadingen-Ferienwohnung-Schild-6 Butjadingen-Ferienwohnung-Schild-7 Butjadingen-Freifunk-Test Butjadingen-Gulfshof1 Butjadingen-HofvonOldenburg Butjadingen-HofvonOldenburg1 Butjadingen-WaReDi Ferienwohnung-Frings-3 Ferienwohnung-Frings-4 FF-IBB-HK-Offloader FF-IBB-SchWeg-Offloader FF-IBB-STADT-Offloader05 ffnw-LOHNetz_Braegeler_Ring_15_01 ffnw-LOHNetz_Falkenweg_21 ffnw-LOHNetz_Feuerwehr-Brockdorf_01-NDS ffnw-LOHNetz_Gewerbering_14-15_01 ffnw-LOHNetz_Hamberger_Pickerweg_42_01 ffnw-LOHNetz_Marktstrasse_11_01 ffnw-LOHNetz_Marktstrasse_30_01 ffnw-LOHNetz_Rathaus_01 ffnw-LOHNetz_Schuetzenfest-2017-VPN FF-OL-Bültmann-uplink ff-os-ameos-Gertrudenring12-nds1266 ff-os-ameos-Gertrudenring12-nds1267 ff-os-ameos-Gertrudenring12-nds1268 ff-os-ameos-Gertrudenring12-nds1269 ff-os-ameos-Gertrudenring13-nds1270 ff-os-ameos-Gertrudenring13-nds1271 ff-os-ameos-Gertrudenring13-nds1272 ff-os-ameos-Gertrudenring2-nds1253 ff-os-ameos-Gertrudenring2-nds1254 ff-os-ameos-Gertrudenring3-nds1255 ff-os-ameos-Gertrudenring4-nds1257 ff-os-ameos-Gertrudenring4-nds1258 ff-os-ameos-Gertrudenring5-nds1259 ff-os-ameos-Gertrudenring5-nds1260 ff-os-ameos-Gertrudenring5-nds1261 ff-os-ameos-Gertrudenring7-nds1262 ff-os-ameos-Gertrudenring7-nds1263 ff-os-ameos-Gertrudenring9-nds1264 ff-os-ameos-Gertrudenring9-nds1265 ff-os-ameos-Knollstrasse27-nds1274 ff-os-ameos-Knollstrasse29-nds1275 ff-os-ameos-Knollstrasse29-nds1276 ff-os-ameos-Knollstrasse31-A2-1r-nds1277 ff-os-ameos-Knollstrasse31-A3-2r-nds1278 ff-os-ameos-Knollstrasse31d-nds1906 ff-os-ameos-Knollstrasse31-Lecker-nds1905 ff-os-ameos-Knollstrasse31-Lift-nds1917 ff-os-ameos-Knollstrasse31-S2-4r-nds1281 ff-os-ameos-Knollstrasse31-S5-nds1283 ff-os-ameos-Knollstrasse31-VER-nds1286 ff-os-ameos-Knollstrasse86a-P1-nds1914 ff-os-ameos-Knollstrasse86-G1-nds1909 ff-os-ameos-Knollstrasse86-G2-nds1910 ff-os-ameos-Knollstrasse86-G3-nds1911 ff-os-ameos-Knollstrasse86-IAG-nds1908 ff-os-ameos-Knollstrasse86-PSM1-nds1912 FF-OS-Bramscher-Str-159-Indoor FF-OS-Fokus-eV FF-OS-Peiner5-0R FF-OS-Trattoria-Grani-Ost
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
LG Lorenz
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 11/16/17 21:08, lrnzo via Dev wrote:
Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan' option ifname 'br-wan' option transitive '1' option fixed_mtu '1' option proto 'gluon_mesh' option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
Ich bin noch nicht dazu gekommen, aber der hoodselector arbeitet im MOLWM mit mesh on LAN/WAN
vg Tarek
hm, also auch mit firmware 20171126 (LEDE) kann man folgendes beobachten:
root@FF-Bad-Iburg-Riesweg-Offloader:~# uci show network | grep auto network.wan.auto='1' network.mesh_wan.auto='0' network.mesh_lan.auto='1' network.client.auto='1' network.bat0.auto='1' root@FF-Bad-Iburg-Riesweg-Offloader:~# batctl if br-mesh_lan: active br-wan: active primary0: active mesh-vpn: active
unter Benutzung meiner parallel-ssh-Superkräfte habe ich gesehen, dass bei 115 von 635 ffnw-routern network.mesh_wan.auto='0' und trotzdem br-wan: active ist.
ich vermute, dass der Grund hierfür in der Funktion molwm(radios) liegt. hier wird am Anfang geprüft, ob network.mesh_wan.auto='1' _oder_ network.mesh_lan.auto='1' ist. Falls ja, wird mesh_en=true gesetzt. Dieser boolean spielt später (Zeile 207) eine Rolle, wenn es darum geht, ob mesh_wan enabled werden soll. hier sollte vielleicht besser nochmal network.mesh_wan.auto='1' direkt geprüft werden?
LG Lorenz
Am 09.12.2017 um 12:29 schrieb Jan-Tarek Butt via Dev:
On 11/16/17 21:08, lrnzo via Dev wrote:
Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan' option ifname 'br-wan' option transitive '1' option fixed_mtu '1' option proto 'gluon_mesh' option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
Ich bin noch nicht dazu gekommen, aber der hoodselector arbeitet im MOLWM mit mesh on LAN/WAN
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
siehe Merge-Request
https://git.ffnw.de/ffnw-firmware/packages/merge_requests/81
Am 09.12.2017 um 13:27 schrieb lrnzo via Dev:
hm, also auch mit firmware 20171126 (LEDE) kann man folgendes beobachten:
root@FF-Bad-Iburg-Riesweg-Offloader:~# uci show network | grep auto network.wan.auto='1' network.mesh_wan.auto='0' network.mesh_lan.auto='1' network.client.auto='1' network.bat0.auto='1' root@FF-Bad-Iburg-Riesweg-Offloader:~# batctl if br-mesh_lan: active br-wan: active primary0: active mesh-vpn: active
unter Benutzung meiner parallel-ssh-Superkräfte habe ich gesehen, dass bei 115 von 635 ffnw-routern network.mesh_wan.auto='0' und trotzdem br-wan: active ist.
ich vermute, dass der Grund hierfür in der Funktion molwm(radios) liegt. hier wird am Anfang geprüft, ob network.mesh_wan.auto='1' _oder_ network.mesh_lan.auto='1' ist. Falls ja, wird mesh_en=true gesetzt. Dieser boolean spielt später (Zeile 207) eine Rolle, wenn es darum geht, ob mesh_wan enabled werden soll. hier sollte vielleicht besser nochmal network.mesh_wan.auto='1' direkt geprüft werden?
LG Lorenz
Am 09.12.2017 um 12:29 schrieb Jan-Tarek Butt via Dev:
On 11/16/17 21:08, lrnzo via Dev wrote:
Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan' option ifname 'br-wan' option transitive '1' option fixed_mtu '1' option proto 'gluon_mesh' option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
Ich bin noch nicht dazu gekommen, aber der hoodselector arbeitet im MOLWM mit mesh on LAN/WAN
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
-
Jan-Tarek Butt -
lrnzo