Obsolete, it just en/disables the switch and which is now part of DSA power management
Can be skipped since VLAN ports are untagged by default and VLAN 1 seems to be either Linux and/or OpenWrt default.
0t (assuming this being CPU switch management port) -> can be skipped
the “cpu” port is the Ethernet switch facing side of the management controller, and as such, would create a duplication of feature, since you would get two interfaces for the same conduit: master netdev, and “cpu” netdev
1t (assuming this being WAN ethX) -> can be skipped since already covered with eth2.12 (on the TO and confirmed working)
Assuming that Lan4 is not enslaved in a bridge:
5t (assuming this being lan4) -> suppose bridge v a dev lan4 vid 12 pvid untagged should work
Lan4 is not part of any configured iface and probably not up, which could be the cause but I doubt it in light of the RTNETLINK reponse - that is usually an indicator that the kernel does not know what has been requested (interpret the command), i.e. missing a feature -> in this case VLAN Filtering.
See if setting up an iface with Lan4 (not bridged) and getting it up will change the outcome.
I wish it hadn't been. I also have an Omnia, but my ISP is NOS (I know how to configure Vodafone, though).
In any case, the first thing you should try (assuming you have two separate devices, the ONT and the Thomson/Technicolor router) is to capture the TR-069 XML configuration by intercepting the traffic between the ONT and the router (with tcpdump, capturing it to a .pcap file), upon hard-resetting the router. You can even use the Omnia for that purpose, just bridge two of the LAN ports, connect the Thomson router and the ONT to each of the ports, start dumping the bridge and hard-reset the Thomson.
After capturing the traffic, you can extract the whole HTTP session (and XML configuration file) from the .pcap with Wireshark.
Since the connection is single-ended (only one VLAN), you should be able to completely replace the OEM router with the Omnia, if you get the routing right (and for that you need the information on the XML configuration file).
It does change the outcome. The bridge command runs without error. Unfortunatly, it also doesn't solve the issue ( the OEM router getting an IP and working ).
On a positive note, I did manage to get this thing running. The correct configuration should have been the one suggested by @moeller0 because in the end it was what I did, albeit manually.
config interface 'iptv'
option proto 'none'
option type 'bridge'
option ifname 'eth2.12 lan4.12'
The above configuration puts the latest trunk in boot loop mode because of a kernel crash. If using OpenWRT 18.06 the router doesn't crash and the configuration is accepted ( the bridge is created with those two interfaces ) but still, the OEM router doesn't get an IP address from the ISP.
So what I did was ( on latest trunk ):
Start with this config:
config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option delegate '0'
option ipaddr '192.168.88.254'
option ifname 'lan0 lan1 lan2 lan3'
config interface 'wan'
option proto 'dhcp'
option broadcast '1'
option peerdns '0'
option delegate '0'
list dns '8.8.4.4'
list dns '8.8.8.8'
option ifname 'eth2.12'
config interface 'iptv'
option proto 'none'
option ifname 'lan4.12'
and then manually create a bridge and add lan4.12 and eth2.12 to it with the following commands:
ip link add name iptvbridge type bridge
root@gateway:~# ip link set iptvbridge up
root@gateway:~# ip link set eth2.12 master iptvbridge
root@gateway:~# ip link set lan4.12 master iptvbridge
and it works!! Omnia gets a public IP address on eth2.12 wan port and the OEM router also gets a public IP address.
I see absolutely no difference between these manual commands and @moeller0 suggestion, so for sure this is a bug somewhere in netifd or kernel or whatever.
I've tried that before, maybe two years ago, without much luck. Someone published the routes on a forum, igmpproxy would catch the traffic but still, not image on tv, or actually if I remember correctly, only a couple of seconds and then it would stop.
Yeah, that's definitely an IGMP issue. Unfortunately, I don't have any experience at all configuring Altice/MEO (except for GlobalConnect, but that's an enterprise package).
Glad you found a solution that works for you, albeit this being software bridiging instead of packet switching but suppose it matters that you got connectivity for iptv node(s)
Is there a difference in using 'ip' vs 'bridge' commands when setting this up? I mean, does using the bridge utility somehow makes the kernel aware of the underlying hardware capabilities of the switch?
Erm, I believe in a DSA system the apparent configuration by interface as performed by @Pedro shoud be mapped to the actual switch, so I would guess under the hood there will be no difference, no?
It should, theoretically. In DSA, a network switch is nothing more than a layer-2 hardware accelerator. I don't know if that's already happening in practice (and there's still the second CPU port problem to solve, at least on the Omnia).
Physically of course traffic has to pass the lanes connecting WAN front panel port (eth2) -> CPU ethernet management controller port (eth0 or eth1) -> switch LAN front panel port (lan4@eth0 or lan4@eth1).
DSA currently supports 5 different tagging protocols, and a tag-less mode as well. The different protocols are implemented in:
net/dsa/tag_trailer.c: Marvell’s 4 trailer tag mode (legacy)
net/dsa/tag_dsa.c: Marvell’s original DSA tag
net/dsa/tag_edsa.c: Marvell’s enhanced DSA tag
net/dsa/tag_brcm.c: Broadcom’s 4 bytes tag
net/dsa/tag_qca.c: Qualcomm’s 2 bytes tag
To my understanding, thus software bridging (as done in this case) is bypassing the switch management (protocols), which might be more clear with
When a master netdev is used with DSA, a small hook is placed in in the networking stack is in order to have the DSA subsystem process the Ethernet switch specific tagging protocol.
802.1Q (VLAN) protocol is supposedly handled by the kernel's 802.11 network stack instead and not by DSA.
There has been progress recently, in the TOS repo eth0 is mapped to lan4 and the other lan ports to eth1.
And there are plans with upstream to make that configurable (moving lan ports between eth0 and eth1).
Both are part of iproute2 userland but I am not sure how each part interacts with the kernel network stack.
No, that is just userland to interact with the kernel. The kernel derives switch (and capability) awareness from other subsystems
Thanks for posting, I believe I have read this in the past but failed (and still fail) to fully understand it.
I a cautiously admitting, that you have more exposure/experience with the DSA switch config, as far as I can tell, so while I am still puzzled, I happily concede that you are probably right.
That would be a decent candidate for the "IGMP" bridge, no?
I also have an Omnia, but my ISP is NOS (I know how to configure Vodafone, though).