No. This is merely to understand the I2C connectivity between the SFP module and the board. It does not provide any network capability. The module is destroyed in this procedure. I am also not aware of any 2.5Gbit SFP modules. What you might have heard about is the 1.25 GBit that SFP modules use to talk via the MII interface to the host chip. But those 1.25 GBit have a protocol overhead so that merely the 1GBit of the 1000-BaseX connection can be transported.
Hi, Kobi
İ succesfully tested ROUTING and no problem.
I could not install "tc" packet via opkg and also tried with menuconfig there is not a packet with name "tc" in the pie branch
how can i do this.
thank you all
Great thing about the routing!
With respect to the tc, you can find it in menuconfig:
tc-full is found in menuconfig under Networking-> Routing and Redirection
But this is only the userspace program. One needs to also install several kernel support packages. I played round with it and I don't know what is all necessary, but this is what I suggest:
Kernel Modules -> Netfilter Extensions -> kmod-nf-conntrack, kmod-nf-flow, kmod-ipt-conntrack
Kernel Modules -> Network Support -> kmod-sched-core, kmod-sched-flower, kmod-sched-act-vlan,kmod-sched
I cannot promise that this is all you need, because I just did trial and error myself. Basically when you use tc and the command is correct but you get a "No such file or directory" error, it's actually a kernel module that is missing.
There is an instruction page on the Wiki how to submit patches. There are a lot of details to be kept in mind, but it definitely pays off to know others can make use of the work one did:
1 Like
I am having the same problem. Everything works intended, just that the switch is not accessible via port1. (the port currently is untagged in the lan vlan as ports 3-8 and from all Luci can be reached and the IPp can be pinged; port1 is not in any other vlan too)
The device connected to port1 can access everything else in that subnet normally too.
So something seems to be blocking the access to the switch on port1.
Hi, i have successfully installed "tc" utility and extracted commands given by you.
Logs are shown below
root@OpenWrt:~# tc qdisc add dev eth0 ingress
[16727.120753] rtl83xx_setup_tc: 5
[16727.124384] rtl83xx_setup_tc: setting up CB
root@OpenWrt:~#
root@OpenWrt:~# tc filter add dev eth0 protocol ip parent ffff: handle 2 flower src_ip 192.168.20.1 skip_sw action drop
root@OpenWrt:~# tc filter add dev eth0 protocol ip parent ffff: handle 2 flower src_mac e4:3a:6e:xx:xx:xx skip_sw action drop
root@OpenWrt:~#
[17192.765478] rtl83xx_setup_tc_block_cb: 2
[17192.769869] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17192.776041] rtl83xx_setup_tc_cls_flower: 2
[17192.780708] In rtl83xx_stats_flower
[17192.784614] In rtl838x_packet_cntr_read, id 21
[17192.789575] Registers: 00000124 000002c3
[17192.794038] Total packets: 292
[17192.797540] rtl83xx_setup_tc_block_cb: 2
[17192.802021] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17192.808050] rtl83xx_setup_tc_cls_flower: 2
[17192.812697] In rtl83xx_stats_flower
[17192.816600] In rtl838x_packet_cntr_read, id 20
[17192.821650] Registers: 00000124 000002c3
[17192.826029] Total packets: 707
root@OpenWrt:~# tc filter show dev eth0 ingress
filter parent ffff: protocol ip pref 49151 flower chain 0
filter parent ffff: protocol ip pref 49151 flower chain 0 handle 0x2
src_mac e4:3a:6e:xx:xx:xx
eth_type ipv4
skip_sw
in_hw in_hw_count 1
action order 1: gact action drop
random type none pass val 0
index 2 ref 1 bind 1
filter parent ffff: protocol ip pref 49152 flower chain 0
filter parent ffff: protocol ip pref 49152 flower chain 0 handle 0x2
eth_type ipv4
src_ip 192.168.20.1
skip_sw
in_hw in_hw_count 1
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
root@OpenWrt:~# tc filter del dev eth0 ingress
[17274.019045] rtl83xx_setup_tc_block_cb: 2
[17274.023541] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17274.029568] rtl83xx_setup_tc_cls_flower: 1
[17274.034234] In rtl83xx_delete_flower
[17274.038244] rtl838x_pie_rule_del: from 2 to 2
[17274.043258] rtl83xx_setup_tc_block_cb: 2
[17274.047643] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17274.053762] rtl83xx_setup_tc_cls_flower: 1
[17274.058334] In rtl83xx_delete_flower
[17274.062413] rtl838x_pie_rule_del: from 1 to 1
root@OpenWrt:~# tc -s filter show dev eth0 ingress
root@OpenWrt:~#
root@OpenWrt:~# tc filter add dev eth0 protocol ip parent ffff: handle 2 flower src_ip 192.168.20.1 skip_sw action mirred egress mirror dev lan3
[17689.615275] rtl83xx_setup_tc_block_cb: 2
[17689.619793] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17689.625822] rtl83xx_setup_tc_cls_flower: 0
[17689.630490] In rtl83xx_configure_flower
[17689.634781] Cookie 86c28400
[17689.637983] rtl83xx_configure_flower: New flow
[17689.642961] rtl83xx_add_flow
[17689.646175] In rtl83xx_parse_flow_rule
[17689.650444] rtl83xx_parse_flow_rule: BASIC
[17689.655021] rtl83xx_parse_flow_rule: IPV4
[17689.659574] rtl83xx_add_flow: MIRRED
[17689.663595] rtl83xx-switch switch@bb000000 lan3: rtl83xx_parse_fwd: not a DSA device.
[17689.672427] Using packet counter 24
[17689.676335] rtl838x_pie_rule_write: 3, t_select: 00000088
[17689.682452] rtl838x_pie_rule_write: template 1
[17689.687473] rtl838x_pie_rule_write: before pie_action
[17689.693119] rtl838x_write_pie_action, at 86e9b9ba
[17689.698441] Raw IACL table entry:
[17689.702149] Match : 00000000 00000000 00000000 00000000 00000000 c0a81401
[17689.709903] Fixed : 00000201
[17689.713219] Match M: 00000000 00000000 00000000 00000000 00000000 ffffffff
[17689.720993] Fixed M: 00000303
[17689.724312] AIF : 80000000 00000000 00000018
[17689.729451] Sel : 00000200
[17689.732859] rtl83xx_setup_tc_block_cb: 2
[17689.737348] rtl83xx_setup_tc_block_cb: TC_SETUP_CLSFLOWER
[17689.743381] rtl83xx_setup_tc_cls_flower: 2
[17689.748028] In rtl83xx_stats_flower
[17689.751933] In rtl838x_packet_cntr_read, id 24
[17689.756892] Registers: 00000000 00000000
[17689.761349] Total packets: 0
Great! Does it do what it is supposed to do, i.e is it useful enough to create firewall with an offloaded route so that the switches could be used to separate two parts of a network and route some traffic between them at hopefully wirespeed? There are a lot of things that can be implemented but it is not clear to me what would be really important to have.
Hi,
Can someone confirm if the SFP ports are working on GS1900 using the current SNAPSHOT? Thanks!
That depends on which GS1900 switch you are talking about and what level of "working" you mean. On the GS1900-10HP everything works perfectly. On the GS1900-48 the SFP ports transmit and receive data, i.e. they can be used, but the SFP tools do not work, meaning you cannot change e.g. change from the default 1GBit to 100Mbit connections. There are several other GS1900 models with different port numbers and PoE for which I do not know the exact status.
2 Likes
I was talking about -10HP version, so thanks for the answer! 
1 Like
Hi, first, thanks for all your work on this; it's great to finally be able to use openwrt on switches.
Has anyone tried using failsafe mode on realtek? Trying on GS1900-8, it doesn't seem to work quite right, for a few different reasons.
I had a go at fixing it using something like I mentioned here https://github.com/openwrt/openwrt/pull/3085#issuecomment-860079305 , but that doesn't seem to be enough -- with eth0 up and an address set on lan1 (also up) I don't get any packets through. Is this expected? The whole DSA thing is new to me, but that works on lantiq.
Adding a bridge containing lan1 works fine, as expected. As a hack I added a file target/linux/realtek/base-files/lib/preinit/05_set_preinit_iface containing:
set_preinit_iface() {
ip link set eth0 up
brctl addbr lan
brctl addif lan lan1
ip link set lan1 up
ifname=lan
}
boot_hook_add preinit_main set_preinit_iface
Which works, but is less than Ideal. I'll open a PR with this later so that failsafe still works until something better comes along.
1 Like
Some more information on this: it seems like the behaviour changed in this commit: https://github.com/openwrt/openwrt/commit/4342d27ec90cd0988fd3e62ccefbe66f2e691372
Before this, bringing up eth0 and lan1, and adding an ip to lan1 was enough to get traffic flowing.
That patch has a relatively big impact on the general behaviour of these switches. The purpose is to make the layer 2 forwarding (the switching) dependent on both the destination MAC of a device as well as the VLAN. Without it, the forwarding depends on the MAC and a station ID and while this is the default hardware behaviour, it is neither documented how it works nor is it the default software configuration of these switches with the OEM software. The forwarding based on MAC and VLAN-ID is fairly standard behaviour for switches in general, but there is a quirk with the RTL devices, namely they require a VLAN 1 to be present for anything VLAN-related to work, see for example dsa.c: rtl83xx_vlan_del(). Normally, this VLAN 1 set up from userspace, via /etc/config/network, see the default configuration. This VLAN 1 is probably set up too late for the failsafe mode.
Could you investigate to which point the VLANs are configured already at the time the failsafe starts and what the bridge configuration fixes?
2 Likes
Thanks for the information. My concern was that with this patch the driver doesn't behave like other DSA drivers (and the general DSA documentation), where you can use the interfaces for each port separately if you like, and that this might ultimately make configuration more difficult (and device-specific).
Without it, the forwarding depends on the MAC and a station ID and while this is the default hardware behaviour, it is neither documented how it works nor is it the default software configuration of these switches with the OEM software.
The default behaviour here sounds like the expected default DSA behaviour (assuming that the "station ID" identifies the physical port?). If the OEM behaviour is desired, can't that be achieved through the configuration interface, rather than as a default setup in the driver?
I don't think it's that concerning that the OEM software is always configured like this, because it was presumably only designed to do normal switch things, whereas with openwrt it seems really useful to be able to use each port separately if we want.
Anyway, sorry if this has already been discussed... to answer your question:
This VLAN 1 is probably set up too late for the failsafe mode.
Could you investigate to which point the VLANs are configured already at the time the failsafe starts and what the bridge configuration fixes?
By default the failsafe / preinit network configuration just does something like this (repeating myself slightly to make it clearer):
ip link set dev $ifname up
ip -4 address add 192.168.1.1/24 broadcast 192.168.1.255 dev $ifname
On other DSA targets, it's something like this:
ip link set dev eth0 up
ip link set dev lan1 up
ip -4 address add 192.168.1.1/24 broadcast 192.168.1.255 dev lan1
With my script above, that turns into:
ip link set eth0 up
brctl addbr lan
brctl addif lan lan1
ip link set lan1 up
ip link set dev lan up
ip -4 address add 192.168.1.1/24 broadcast 192.168.1.255 dev lan
It knows how to configure vlans by adding a vlan interface on top of the specified interface, but this also doesn't seem to work. The code is here if you're interested. I'll have a poke around to try to find out why the bridge makes it work.
The Station ID is the MSTI, see e.g. here: https://en.wikipedia.org/wiki/Multiple_Spanning_Tree_Protocol
It can be set per-VLAN on the RTL-SoCs, see here: https://svanheule.net/realtek/maple/table/vlan
but it is not clear how to assign an MSTI to a VLAN, so we just use the VLAN-ID itself. In principle this should be the same, except for this strange quirk that VLAN 1 needs to exist. There was not much discussion on whether this quirk needs to be fixed in the driver itself. But it is probably better to be aware of this VLAN in userspace to avoid intransparent behaviour.
Thanks again for the information; i was a bit confused!
Poking around, it seems like the only change required to get traffic to flow is to add them to vlan 1 (via a call to vlan_set_tagged); the rest of rtl83xx_vlan_setup doesn't affect this.
It works in bridge mode because for some reason something higher up in the stack adds and then removes vlan 1 on every configured port, and rtl83xx_vlan_del skips the removal for vlan 1. This does have the effect you'd expect, in that vlan 1 traffic gets to ports where it shouldn't. This is quite unfortunate from a security perspective.
Does the vendor firmware have this issue too? (edit: looks like yes, I'll do some more reading of this thread...) If not, maybe there's some extra configuration to be done, or otherwise some hack involving the vlan mapping rules might be possible.
I do not think there is necessarily a fundamental issue with the hardware. The firmware merely configures a VLAN 1 in hardware but does not tag any ports with it. Internally this seems to be the default VLAN-id used for packets that are not tagged. My suspicion is that the hardware does the following mapping: internal VLAN 1 = no 802.1q or vlan 1, internal VLAN 0 = any VLAN. This solution is found on all SoCs until the 9300 family, the 9310 family does not seem to have this quirk. @bmork suggested the solution that is currently in place. If you want to investigate yourself, there is a reasonably readable SDK available: https://biot.com/gpl/XGS1210_OSC_20201116.7z
For the VLAN default configuration have a look at e.g. sdk/src/dal/maple/dal_maple_vlan.c:_dal_maple_vlan_init_config()
What I found in early experiments was that removing VLAN 1 from a port would block all traffic on that port regardless of VLAN. Tagged or not doesn't matter. Only membership. My "fix" was to let the driver fake removals of VLAN 1 from any port. Very ugly since it creates a hidden domain with all ports, which can't be disabled.
Now this is a long time ago, and I must admit I haven't followed the development closely. So for all I know this was an issue related to how we configured the SoC at the time, and not relevant anymore.
But magic behaviour related to VLAN 1 (or another ID configured as the switch "management VLAN") is/was very common. So common that some guides recommend staying away from VLAN 1.
Playing with the vendor firmware, it looks like you can disable vlan 1 on a port and still have traffic on other vlans flow, so either some configuration is not quite right, or they have implemented a work-around (or my test was bogus!)
The poking continues...
This PR should fix the VLAN1 strangeness that was discussed above:
I've only been able to test on RTL8380M; it'd be good to hear if it works for any other devices.
For completeness, some of the things I said above about how this works were wrong, probably because I didn't have quite enough visibility into what was going on. With JTAG set up things were much clearer.
1 Like
Worked for me on a Netgear GS108T v3.
1 Like