What do you think I should do besides the bug report that I filled?
I'm not even sure that bugtracker is the right place to fill bug reports. It seems quite dead. Very little activity
Response activity on the OpenWrt repo at Github is indeed better than on the Flyspray platform, however only certain elements are available for issue reporting on Github and probably the kernel crash cannot be reported there - though I am no expert in dissenting a crash log and figuring the culprit.
Else there are some IRC channels you could try perhaps.
1 Like
This would need to be corrected since DSA leverages the switchdev framework apparently for hardware Vlan ID whilst 802.1Q is used for software Vlan ID
- [1]
The first patch adds the VTU operations to the mv88e6xxx code, as well as a
"vtu" debugfs file to read and modify the hardware VLAN table.The second patch adds the glue between DSA and the switchdev VLAN objects.
The third patch finally implements the necessary functions in the mv88e6xxx code to interact with the hardware VLAN through switchdev, from userspace commands such as "bridge vlan"
- [2]
DSA directly utilizes SWITCHDEV
SWITCHDEV objects supported by DSA are the FDB and VLAN objects
switchdev object is used to carry the VID and bridge flags
switchdev object is used to carry the VID and FDB info
switchdev object is used to carry the VID and MDB info
[1] https://lwn.net/Articles/650480/
[2] https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html
1 Like
This probably been the wrong command, you may try instead with bridge v a dev lan4 vid 12 master, that is after lan4 been removed from the bridge with eth2.
bridge vlan should then print
lan4 1 PVID Egress Untagged
12
and the IPTV client(s) should get connectivity.
1 Like
I will try it next monday!
Man thanks alot for all your inputs.
Another question is:
Is there a way to implement this configuration in a uci compatible way, for instance, a way to define this in /etc/config/network?
I will need to somehow make this configuration permanent and also to be re-applied if I ever change other network configurations that lead to restarting the network.
Afaik [1] there is no (L)UCI parsing routine for
bridge a dev <netdev> vid <id> <options>bridge d dev <netdev> vid <id>
Thus time being it would require a script to retain the setting after reboot. Might work with Firewall - Custom Rules since those are being interpreted as shell script and might fit into the workflow since the FW being reloaded on network changes.
As for enabling vlan filtering on a bridge
/sys/class/net/<bridge>/bridge/vlan_filtering
that does not seem being supported via (L)UCI either but is easier to be set retainable after reboot via sysctl
Another way seems to be, though not via (L)UCI it would appear:
ip l s dev <bridge> ty bridge vlan_filtering 1
1 Like
ok, so what about using the old switch driver and swconfig instead of the dsa driver? not even know if this is possible to be configured using make kernel_menuconfig
To my understanding swconfig was refused for inclusion in mainline kernel and thus may not be available via make kernel_menuconfig unless patched by what OpenWrt provides. But then again it may have been removed for the Omnia build and only DSA is now available.
Perhaps best if you check it out your end.
1 Like
Though not applicable to the specifics of the thread topic it heads more under the general umbrella of switch in Omnia.
Querying the two management ports (eth0|1) and the front panel ports (lan0|1|2|3|4) with:
ethtool -k <dev>| grep offload
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
ethtool -k <dev>| grep vlan
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Would indicate there is not much offloading possible with the device/driver and also Vlan features are turned off.
I found this [1] somewhat curiosly related to the query of the hardware capabilities (features turned off)
For hardware offloading, when a flow is constructed, the driver implements a callback to send it to hardware. If the hardware supports it, it is added there, otherwise it is added to the software flow table. Hardware offloading is not upstream yet because there is no driver using it yet. In OpenWRT, the flow offloading is extended to support bridges, VLANs and PPPoE.
[1] https://www.mind.be/openwrtsummit18/2018-10-29-OpenWRT18-network-offloading.html
1 Like
Worked!
On another note, I took a day off to figure out why I was unable to put multicast to work and ended up figuring out the issue, so I won't be needing this anymore. I also was able to configure the telephony part of the OEM device on OpenWRT, so all is good, and the OEM router will now be on the shelf gathering dust.
2 Likes
Well I guess you have found a way,
I live in Portugal too and I have MEO, they use the clan 12 and I can receive a IP for it, but when adding vlans to the interfaces the kernel crahes as you said.
I have found a patch but this patch only makes the kernel not crash, cause after using it I can't get any traffic between the two ports.
I've been waiting for openwrt to adopt kernel 5.4 cause these issues are now fixed upstream. Also don't bother with creating a bug report cause that issue is already up there and they didn't fix it.
But are you using an Omnia? Do you want to keep the OEM router connected for some reason ( IPTV or telephony or both ) ?
Actually I can keep the ISP router, but there are many issues with DSA, it is more than broken in kernel 4.19, in kernel 4.14 it works very well.
My router is a WRT3200ACM, the switch is the same as yours, and I only keep it connected because in kernel 4.19 I can't get the igmp proxy to work because of the kernel, and I can't bride the wan(.12) to the lan1 because it doesn't work with non bridged interfaces, if I bridge a clan interface with another clan interface with the same vlan it works, but vlan interfaces with non vlan interfaces doesn't work.
I can't fix it and no one answers me to fix it with my help, so I'm hoping and waiting that kernel 5.4 really fixes it.
I have igmpproxy working on MEO without any issues with kernel 4.19 and DSA switch.
Here is how to do it:
add the following line to:
/etc/sysctl.conf
net.ipv4.conf.all.force_igmp_version=2
igmpproxy configuration file
/etc/config/igmpproxy
config igmpproxy
option quickleave 1
config phyint
option network WAN # replace WAN with your wan network name
option direction upstream
# list altnet 0.0.0.0/0
list altnet 194.65.46.0/23
list altnet 192.168.0.0/16
list altnet 10.173.0.0/16
list altnet 213.13.16.0/20
list altnet 213.13.19.0/20
list altnet 213.13.19.177/20
list altnet 232.17.12.47/20
list altnet 224.0.0.0/4
list altnet 10.159.224.0/24
list altnet 239.0.0.0/8
list altnet 232.0.0.0/8
config phyint
option network iptv # replace iptv with your iptv network name
option zone iptv # same
option direction downstream
list whitelist 192.168.89.0/24 # put your iptv network here
Firewall file ( the two rules should be inserted by the igmpproxy start up script but because of a bug, they aren't, and as such we need to add them to firewall conf file )
/etc/config/firewall
config rule
option name 'Allow-IGMP'
option proto 'igmp'
option src 'wan'
option target 'ACCEPT'
config rule
option name 'IPTV' #change this to your iptv network name
option proto 'udp'
option src 'wan'
option dest_ip '224.0.0.0/4'
option target 'ACCEPT'
option dest 'iptv' #change this to your iptv firewall zone name
config zone
option name 'iptv' #this is your iptv zone firewall declaration
option network 'iptv'
option forward 'REJECT'
option input 'ACCEPT'
option output 'ACCEPT'
config forwarding
option src 'iptv'
option dest 'wan'
the network configuration file, for defining the iptv network
/etc/config/network
config interface 'iptv'
option proto 'static'
option ifname 'lan4' #change this to the port you want to connect your iptv box to.
option delegate '0'
option ipaddr '192.168.89.254' #change to the IP network you want to have on the iptv network
option netmask '255.255.255.0'
and finally enable dhcp on the iptv network so that the iptv box can get an IP address
/etc/config/dhcp
config dhcp 'iptv'
option interface 'iptv'
option start '100'
option limit '150'
option leasetime '12h'
all this can be configured via luci with exception of the igmpproxy file
I have created a separated network for iptv for security concerns. You can, if you prefer to ignore the iptv network and use the lan network. in this case, you only need to configure the igmpproxy file and add the two firewall rules.
So, no need to bridge vlans and no need to use the OEM router for IPTV
if you want the password for the SIP account, just hard reset the OEM router and sniff it out with wireshark. It is transmitted in clear text in a TR-069 message somewhere in the first five minutes after the reset. I used the port mirroring function of my R7800 but a switch with management or a hub will do just fine. Wireshark for linux allows you to run on a remote interface via ssh, as long as the remote device has tcpdump installed.
1 Like
I did all you said but it doesn't work because for some reason IGMP packets don't reach the CPU cause they get lost along the way, the situation you described was the one I used in kernel 4.14, but it stopped working in kernel 4.19. So this is a bug in the DSA driver but it won't get fixed, at least until the release of 5.4.
Yeah I know, I did the same for the SIP ahahah, It's nice to have someone in Portugal to talk to about this stuff, cause no one usually gets it.
I made a bug report in bugs.openwrt.org and also in bugzilla.kernel.org but neither one gets feedback.
If you need to talk about, discuss or any help about Portugal ISP don't hesitate to reach out to me!
If there's any developer of OpenWRT reading this please help us fix this issue with DSA.
PS: I have found that disabling vlan filtering in the kernel can actually fix the issue, but thats not a viable solution.
1 Like
I'm not understanding why you need vlan filtering as you only need to configure one port with vlan, and that is the wan port. so essentially wan port would be let's say eth0.12 and the other ports can all be bridged to br-lan.
I see what you mean. I don't need Vlan filtering, it is enabled by default on the OpenWRT kernel config. And about the interface with vlan I need it bridged to lan1 because I'm studying networks and I need to have direct access to the WAN (to receive a public IP) on the LAN1.
Hi @Pedro and @anon45274024
I have been reading the entire message to try to understand how to reconfigure the turris omnia router in TOS 4.x / 5.x versions. unable to use swconfig.
I have seen that the Vlan are now controlled with the DSA switch, but I do not see enough information about it to understand it. How can I transfer this configuration to Dsa Switch?
This is my configuration for Turris Omnia that I have been using for 2-3 years Turris OS version 3.xx with 15.05 (Chaos Calmer), with Lan eth0.1, Iptv eth1.2 (incoming tv traffic), Voip eth1.3, Tvlan eth0.4 (isolated tv so it doesn't flood traffic with mcproxy), wan eth1.6:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fda7: 8045: b9e8 :: / 48'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '1 2 3 5t 6'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '4t'
config switch_vlan
option device 'switch0'
option vlan '3'
option vid '3'
option ports '4t'
config switch_vlan
option device 'switch0'
option vlan '4'
option vid '4'
option ports '0 5t'
config switch_vlan
option device 'switch0'
option vlan '6'
option vid '6'
option ports '4t'
config interface 'lan'
option ifname 'eth0.1'
option type 'bridge'
option proto 'static'
option ip6assign '60'
option igmp_snooping '1'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config interface 'iptv'
option ifname 'eth1.2'
option proto 'static'
option ipaddr '10 .133.155.92 '
option netmask '255.128.0.0'
option gateway '10 .128.0.1 '
option defaultroute '0'
option peerdns '0'
config interface 'tvlan'
option proto 'static'
option ifname 'eth0.4'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
config route
option interface 'iptv'
option target '172.16.0.0'
option gateway '10 .128.0.1 '
option netmask '255.240.0.0'
config route
option interface 'voip'
option target '10 .31.255.128 '
option gateway '10 .22.64.1 '
option netmask '255.255.255.224'
config interface 'voip'
option ifname 'eth1.3'
option proto 'dhcp'
option defaultroute '0'
option peerdns '0'
config interface 'wan'
option ifname 'eth1.6'
option proto 'pppoe'
option username 'adslppp @ telefonicanetpa'
option password 'adslppp'
option ipv6 '1'
option mtu '1492'
config interface 'wan6'
option ifname 'wan'
option proto 'dhcpv6'
option noserverunicast '1'
config interface 'vpn_turris'
option ifname 'tun_turris'
option proto 'none'
option auto '1'
option enabled '1'
Do we know what is the current state of this?
- Of DSA in general
- of Luci parts of configuration
- of port config regarding tagged/untagged/off vlans in luci
I think first part should be working, but regarding others. I was trying to find in on github and mailing list and I am far from wise
Also, importantly. Did you succeed?