MPW
19. November 2021 um 00:42
1
Moin,
weiß jemand, wie man das WAN auf einer 4040 als zusätzliches VLAN (z. B. 10) auf einem der gelben Ports ausgibt?
Anwendungsfall hier ist, dass an der 4040 proprietäre APs hängen, die untaggt mit Freifunk-Clientnetz und taggt mit dem WAN-Netz versorgt werden sollen.
Auf den 1043ern kann man einfach in der /etc/config/network
beim VLAN-Block 2 den LAN-Port hinzufügen.
Und auch die 4040 zeigt an, dass intern so gearbeitet wird:
# swconfig dev switch0 show
[...]
VLAN 1:
vid: 1
ports: 0 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 5
Aber das VLAN 2 taucht in der /etc/config/network
nirgendwo auf. Ich hatte jetzt überlegt ob man ein weiteres Interface in br-wan hängt, aber ideal ist das nicht, weil dann alles durch die CPU muss statt auf Hardwareebene geswitcht zu werden.
Viele Grüße
Matthias
Ich würde dir abraten id 2 zu benutzen, da irgedwas manchmal „hard-wired“ ist. Ensprechend kannst du auch mit der swconfig die ports abändern. Wichtig ist nur das alles tagged zum cpu port ist (nehme ich mal an).
Deswegen mach doch so? Dann ist dhcp einfach untagged auf allen ports.
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '42'
option ports '0t 1t 2t 3t 4t'
config switch_vlan
option device 'switch0'
option vlan '40'
option ports '0t 1 2 3 4'
config interface 'mgmt'
option ifname 'eth0.42'
option proto 'static'
option ipaddr 'xxx'
option ip6addr 'xxx'
config interface 'dhcp'
option ifname 'eth0.40'
option proto 'static'
option ipaddr 'xxx'
option type 'bridge'
option ip6addr 'xxx'
FYI: Bald gibt es DSA support auf trunk in Openwrt. Dann stimmt oben geschriebens nicht mehr ganz.
openwrt:master
← sartura:ipq40xx-dsa
offen 05:32PM - 25 Oct 21 UTC
This PR is a WIP draft for adding a working ethernet + DSA driver along with som… e PHY SFP improvements.
Ethernet driver is an updated and fixed version of the IPQESS driver that has been in various trees.
DSA driver is based on an older qca8k driver to which IPQ40xx specific stuff was added based on even older modified qca8k that was lingering in the same trees as the IPQESS.
DSA driver itself lacks some features that newer qca8k has like VLAN offloading but that is something that I plan on adding.
The code also isn't upstream ready due to various hacks that are specific to the IPQ40xx in regards to PSGMII.
Driver combo works surprisingly well, however it has one bug that doesn't always present itself.
The issue is that PSGMII PHY-s won't calibrate on some boots, this happens really randomly.
I have only added conversion of Jalapeno board as an example, however, I will add a few more.
Note that I don't know if RGMII works properly as I don't have any board using it.
This patch series is based on the following tree:
https://github.com/sartura/linux/tree/ipq40xx/linux-v5.10.8-DSA
It can be referenced to see the actual development in individual commits as I slightly cleaned up some things when preparing for OpenWrt submission and those are not yet reflected in our public kernel tree.
I will rebase on 5.14.14 which we are using internally and publish with OpenWrt changes.
You can see that there were actually 3 working taggers added but I only included the shinfo one which has the lowest overhead.
I find the driver combo usable, but the code requires some work regarding features and a decent cleanup.
We are publishing it in hopes that by working with the community we can eventually get support for wired networking
upstream and that will complete IPQ40xx support upstream as the only major subsystem missing.
So since the driver combo has been really fixed up I think that we need to convert all of the boards to get this merged.
So, to track that let's add a checklist:
- [x] 8devices Habanero
- [x] 8devices Jalapeno
- [x] Alfa AP120C-AC
- [x] Aruba AP-303
- [ ] Aruba AP-303H
- [ ] Aruba AP-365
- [x] Asus Lyra (MAP-AC2200)
- [ ] Asus RT-AC42U
- [x] Asus RT-AC58U
- [x] AVM FRITZ!Box 4040
- [x] AVM FRITZ!Box 7530
- [x] AVM FRITZ!Repeater 1200
- [ ] AVM FRITZ!Repeater 3000
- [ ] Buffalo WTR-M2133HP
- [x] Cell C RTL30VW
- [x] Crisis Innovation Lab MeshPoint.One
- [ ] Compex WPJ419
- [x] Compex WPJ428
- [ ] devolo Magic 2 WiFi next
- [ ] D-Link DAP-2610
- [x] Edgecore ECW5211
- [ ] Edgecore OAP100
- [ ] EnGenius EAP1300
- [ ] EnGenius EAP2200
- [ ] EnGenius EMD1
- [ ] EnGenius EMR3500
- [ ] EnGenius ENS620EXT
- [ ] EZVIZ CS-W3-WD1200G
- [ ] GL.iNet GL-AP1300
- [x] GL.iNet GL-B1300
- [x] GL.iNet GL-B2200
- [ ] GL.iNet GL-S1300
- [x] Linksys EA6350
- [x] Linksys EA8300
- [x] Linksys MR8300
- [ ] Luma Home WRTQ-329ACN
- [x] Cisco Meraki MR33
- [ ] MobiPromo CM520-79F
- [ ] NETGEAR EX6100 v2
- [ ] NETGEAR EX6150 v2
- [ ] NETGEAR RBR50
- [ ] NETGEAR RBS50
- [ ] NETGEAR SRS60
- [x] NETGEAR WAC510
- [ ] OpenMesh A42
- [ ] OpenMesh A62
- [x] P&W R619AC
- [ ] Plasma Cloud PA1200
- [ ] Plasma Cloud PA2200
- [ ] Qualcomm Atheros AP-DK01.1 C1
- [ ] Qualcomm Atheros AP-DK04.1 C1
- [ ] Qxwlan E2600AC C1
- [ ] Qxwlan E2600AC C2
- [ ] Teltonika RUTX10
- [ ] Unielec U4019
- [x] ZyXEL NBG6617
- [ ] ZyXEL WRE6606
- [x] MikroTik hAP ac2
- [x] MikroTik hAP ac3
- [x] MikroTik Wireless Wire Dish LHGG-60ad
- [x] MikroTik SXTsq 5 ac
- [x] MikroTik cAP ac
- [x] ZTE MF286D
- [ ] Telco X1 Pro
MPW
28. November 2021 um 00:21
4
Moin @Polynomialdivision ,
danke für die Antwort. Wenn ich sie richtig verstehe, beziehst du dich hier aber nur auf die gelben Ports. Ich suche eine Lösung für den blauen Port, bzw. möchte den blauen Port auf die gelben durchbridgen.
Grüße
Matthias
MPW
28. November 2021 um 00:37
5
Ich hab’s gelöst, es ist tatsächlich so trivial. Einfach unter dem VLAN 1 einen Block für wie oben richtig geraten VLAN2 anlegen. Obwohl es standardmäßig nicht drin ist, geht es genau wie bei einem 1043er.
Jedoch konnte ich die IP der 4040 auf dem WAN-Port nicht von einem Gerät am gelben Port aus erreichen. Von Upstream aus ging es und die durchgebridgten Clients konnten auch Upstream alles erreichen. Für meinen Anwendungsfall genügt das erstmal. Der Switch in der 4040 scheint nicht zu checken, welche MAC die CPU im Gerät selbst hat.
# Bestand
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 0'
# neu eingefügt
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 1t 2t 3t 4t 5'
Nach einem Neustart wird die Konfig übernommen:
# swconfig dev switch0 show
[...]
VLAN 1:
vid: 1
ports: 0 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 1t 2t 3t 4t 5
Hatte mich vorher nicht getraut, weil das Gerät ca. 30 min entfernt steht. Hab es jetzt mit einem lokalen Gerät testen können.
Ich würde dir trotzdem dazu raten, beide ports zu taggen zur CPU hin und nicht dieses vlan2 bzw 1 zu benutzen. Port 5 ist das WAN. Aber wenn es läuft, dann lass es so.
1 „Gefällt mir“
Wenn du zufällig Zeit hast und mehrere 4040er, dann versuch mal bitte die freezes nachzuprdouzieren, wenn du bock hast
offen 10:21AM - 07 Oct 21 UTC
geschlossen 08:18AM - 29 Apr 22 UTC
kernel
flyspray
*PolynomialDivision:*
The ar40xx on an ipq40xx device freezes from time to time… . The issue is hard to reproduce since it was seen on multiple devices on a very different time scale. We run a mesh network with olsr (IPv4) and babeld (IPv6) as routing daemons. The affected devices are mainly Fritz!Box 4040 and Fritz!Box 7530. Typically, on setups with a huge load, the switches begin to freeze. As an example, a church that acts as a central point of our mesh network and connection to the internet experiences the freeze daily. We can easily reproduce and test solutions in that location. Devices with fewer clients and just one mesh connection, also crash but it needs some time (30 days). Some devices with almost no traffic or client do not crash.
As a workaround, we wrote the naywatch daemon, which checks for ipv6 link-local connectivity. We also allow collecting debug output from it. With that, we can show what a diff of the swconfig looks like when a freeze happens. So the switch is already in a frozen state. As you can see the CPU Port 0 is not sending any frames (TX is not visible) to the CPU anymore. The switch still receives frames.
<code diff>
Port 0:
mib: Port 0 MIB counters
-RxBroad : 472793
+RxBroad : 472882
RxPause : 0
-RxMulti : 36772
+RxMulti : 36854
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
-Rx64Byte : 2075611
-Rx128Byte : 20964917
-Rx256Byte : 16459560
-Rx512Byte : 623700
-Rx1024Byte : 907303
-Rx1518Byte : 48003389
+Rx64Byte : 2075618
+Rx128Byte : 20964980
+Rx256Byte : 16459583
+Rx512Byte : 623752
+Rx1024Byte : 907344
+Rx1518Byte : 48003397
RxMaxByte : 21422694
RxTooLong : 0
-RxGoodByte : 107718798589
+RxGoodByte : 107718869396
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
@@ -51,38 +51,38 @@
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
</code>
I would suggest:
- Switch Broken?
- Switch wrongly configured
However, there seems to be an DSA implementation of the ar40xx that should be released some day. So maybe it is better to switch to DSA before fixing this issue. I already wrote with blocktrron and to my understanding, he was also able to experience a freeze.
**Rest of diff:**
<code diff>
root@emma-core:~# diff -u 1633480443-swconfig\ dev\ switch0\ show.log 1633480463-swconfig\ dev\ switch0\ show.log
--- "1633480443-swconfig dev switch0 show.log" 2021-10-06 02:34:03.000000000 +0200
+++ "1633480463-swconfig dev switch0 show.log" 2021-10-06 02:34:23.000000000 +0200
@@ -7,22 +7,22 @@
linkdown: ???
Port 0:
mib: Port 0 MIB counters
-RxBroad : 472793
+RxBroad : 472882
RxPause : 0
-RxMulti : 36772
+RxMulti : 36854
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
-Rx64Byte : 2075611
-Rx128Byte : 20964917
-Rx256Byte : 16459560
-Rx512Byte : 623700
-Rx1024Byte : 907303
-Rx1518Byte : 48003389
+Rx64Byte : 2075618
+Rx128Byte : 20964980
+Rx256Byte : 16459583
+Rx512Byte : 623752
+Rx1024Byte : 907344
+Rx1518Byte : 48003397
RxMaxByte : 21422694
RxTooLong : 0
-RxGoodByte : 107718798589
+RxGoodByte : 107718869396
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
@@ -51,38 +51,38 @@
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
mib: Port 1 MIB counters
-RxBroad : 107158
+RxBroad : 107267
RxPause : 0
-RxMulti : 1147
+RxMulti : 1173
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
-Rx64Byte : 1536
-Rx128Byte : 68123
-Rx256Byte : 20668
-Rx512Byte : 4912
-Rx1024Byte : 10327
-Rx1518Byte : 90128
-RxMaxByte : 9851
+Rx64Byte : 1555
+Rx128Byte : 68180
+Rx256Byte : 20673
+Rx512Byte : 4925
+Rx1024Byte : 10332
+Rx1518Byte : 90209
+RxMaxByte : 9860
RxTooLong : 0
-RxGoodByte : 166901240
+RxGoodByte : 167051151
RxBadByte : 0
RxOverFlow : 0
-Filtered : 118
-TxBroad : 856851
-TxPause : 1074
-TxMulti : 89960
+Filtered : 307
+TxBroad : 856940
+TxPause : 3442
+TxMulti : 90042
TxUnderRun : 0
-Tx64Byte : 38606
-Tx128Byte : 206906
-Tx256Byte : 56950
-Tx512Byte : 27986
-Tx1024Byte : 60718
-Tx1518Byte : 677209
+Tx64Byte : 40978
+Tx128Byte : 206965
+Tx256Byte : 56973
+Tx512Byte : 28038
+Tx1024Byte : 60759
+Tx1518Byte : 677217
TxMaxByte : 74048
TxOverSize : 0
-TxByte : 1186157213
+TxByte : 1186378970
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
@@ -95,38 +95,38 @@
link: port:1 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 2:
mib: Port 2 MIB counters
-RxBroad : 170588
+RxBroad : 170832
RxPause : 0
-RxMulti : 11717
+RxMulti : 11767
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
-Rx64Byte : 28452
-Rx128Byte : 6337895
-Rx256Byte : 408749
-Rx512Byte : 54975
-Rx1024Byte : 62053
-Rx1518Byte : 343977
-RxMaxByte : 130630
+Rx64Byte : 28455
+Rx128Byte : 6338150
+Rx256Byte : 408825
+Rx512Byte : 55001
+Rx1024Byte : 62066
+Rx1518Byte : 344149
+RxMaxByte : 130646
RxTooLong : 0
-RxGoodByte : 1345452080
+RxGoodByte : 1345783813
RxBadByte : 0
RxOverFlow : 0
-Filtered : 574
-TxBroad : 793647
-TxPause : 1151
-TxMulti : 79418
+Filtered : 1135
+TxBroad : 793736
+TxPause : 3519
+TxMulti : 79500
TxUnderRun : 0
-Tx64Byte : 97711
-Tx128Byte : 603920
-Tx256Byte : 173282
-Tx512Byte : 76156
-Tx1024Byte : 104686
-Tx1518Byte : 3582480
+Tx64Byte : 100079
+Tx128Byte : 603969
+Tx256Byte : 173305
+Tx512Byte : 76208
+Tx1024Byte : 104727
+Tx1518Byte : 3582488
TxMaxByte : 7391371
TxOverSize : 0
-TxByte : 16528781103
+TxByte : 16529001614
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
@@ -139,38 +139,38 @@
link: port:2 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 3:
mib: Port 3 MIB counters
-RxBroad : 159441
+RxBroad : 159671
RxPause : 0
-RxMulti : 18188
+RxMulti : 18257
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
-Rx64Byte : 9911
-Rx128Byte : 3051611
-Rx256Byte : 711251
-Rx512Byte : 377985
-Rx1024Byte : 459307
-Rx1518Byte : 46523339
-RxMaxByte : 21133903
+Rx64Byte : 9932
+Rx128Byte : 3052044
+Rx256Byte : 711326
+Rx512Byte : 378003
+Rx1024Byte : 459361
+Rx1518Byte : 46523507
+RxMaxByte : 21133924
RxTooLong : 0
-RxGoodByte : 100988636934
+RxGoodByte : 100989010961
RxBadByte : 0
RxOverFlow : 0
-Filtered : 36461
-TxBroad : 804786
-TxPause : 6016
-TxMulti : 72948
+Filtered : 37251
+TxBroad : 804875
+TxPause : 8384
+TxMulti : 73030
TxUnderRun : 0
-Tx64Byte : 1661972
-Tx128Byte : 18816233
-Tx256Byte : 15830078
-Tx512Byte : 276436
-Tx1024Byte : 524862
-Tx1518Byte : 3198326
+Tx64Byte : 1664343
+Tx128Byte : 18816282
+Tx256Byte : 15830101
+Tx512Byte : 276488
+Tx1024Byte : 524903
+Tx1518Byte : 3198334
TxMaxByte : 426878
TxOverSize : 0
-TxByte : 9485704082
+TxByte : 9485924799
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
@@ -202,19 +202,19 @@
RxBadByte : 871047744
RxOverFlow : 0
Filtered : 99
-TxBroad : 909305
-TxPause : 4319
-TxMulti : 67716
+TxBroad : 909394
+TxPause : 6687
+TxMulti : 67798
TxUnderRun : 0
-Tx64Byte : 335196
-Tx128Byte : 1832541
-Tx256Byte : 520952
-Tx512Byte : 320853
-Tx1024Byte : 412422
-Tx1518Byte : 42645040
+Tx64Byte : 337564
+Tx128Byte : 1832588
+Tx256Byte : 520975
+Tx512Byte : 320905
+Tx1024Byte : 412463
+Tx1518Byte : 42645048
TxMaxByte : 13773617
TxOverSize : 0
-TxByte : 84230298783
+TxByte : 84230519096
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
</code>
MPW
2. Dezember 2021 um 12:36
8
Moin,
hab mir das Ticket mal durchgelesen. Ich würde erstmal beobachten, ob das jetzt auftritt.
Wir haben viele 4040 mit VLAN-Konfig im Einsatz. Häufig einfach Mesch und Clientnetz parallel auf einem Port um über einen Switch Außenrouter mit Mesch- und Innenrouter mit Clientnetz zu versorgen. Da hat es noch keinen einzigen Absturz gegeben, soweit mir bekannt ist.
Und jetzt eben die Konfig mit dem WAN-Netz. Bisher auch keine Probleme.
Werde das auf jeden Fall mal beobachten.
4040 hab ich noch einige hier. Hast du einen konkreten Test, den ich nachstellen soll? Dort wirkt es einfach so, als ob die Geräte sich halt weghängen, was ich bei mehreren Geräten, teilweise schon Monate im Einsatz, bisher nicht hatte. Allerdings mit Gluon, nicht mit OpenWrt.
Grüße
Matthias
Ne, aber mittlerweile hat @blocktrron glaube ich auch einmal den Crash Reproduziert. Und es ist wirklich so merkwürdig. Ich glaube mit unterschiedlich viel Traffic trittt auch der freeze unterschiedlich oft auf. Ich wollte mal nen iperf3 testbed aufbauen.
1 „Gefällt mir“
Hier nur der Hinweis für alle, die den Thread ab 2022 lesen:
Gluon 2022.1 unterstützt VLANs jetzt updatefest.
Wer mag kann sich ja mal die Doku ansehen, die wir dafür gerade vorbereiten, ob es noch Verständnisprobleme gibt:
freifunk-gluon:master
← AiyionPrime:docs-wired-mesh-roles
offen 12:53AM - 11 Jul 22 UTC
> - explain what happens on gluon-reconfigure
> - show workflow to alter the wi… red network config
> - update examples
> - update 'has changed in' section
>
> resolves #2474
@herbetom lets take this as a first draft. Let me know what you're missing or'd like to have changed.
@MPW wenn ich das richtig im Kopf habe, wird es nicht möglich sein Client und Mesh auf dem selben Interface gleichzeitig zu betreiben, weil das zu Schleifen führen kann, die Gluon nicht abfängt.
1 „Gefällt mir“
MPW
12. Juli 2022 um 22:42
12
Den Satz verstehe ich nicht. Es geht gerade um VLANs, also das Trennen von virtuellen und physikalischen Interfaces. Schleifen machen in Mesh nichts um im Clientnetz darf das sowieso nicht sein. Und ehrlich gesagt verstehe ich deinen Satz auch nach mehrfachem Lesen nicht.
Aber siehe hier:
freifunk-gluon:master
← AiyionPrime:docs-wired-mesh-roles
offen 12:53AM - 11 Jul 22 UTC
> - explain what happens on gluon-reconfigure
> - show workflow to alter the wi… red network config
> - update examples
> - update 'has changed in' section
>
> resolves #2474
@herbetom lets take this as a first draft. Let me know what you're missing or'd like to have changed.
(Zeile 111 im Diff)
1 „Gefällt mir“
Mein Fehler. Die Info, dass du zwei getrennte VLANs auf dem Interface für die beiden Rollen nutzt hatte ich überlesen. Das geht natürlich weiterhing aber jetzt persistent konfigurierbar und von gluon unterstützt
Ich hatte rausgelesen, dass du auf dem selben VLAN-Interface Mesh und Client gleichzeitig abgeworfen hättest und das keine Probleme verursacht hätte.
1 „Gefällt mir“
MPW
13. Juli 2022 um 18:29
14
Ne, das wäre wirklich schräg
1 „Gefällt mir“