Le dim. 26 avr. 2020 à 10:57, Etienne Champetier <champetier.etie...@gmail.com> a écrit : > > Hi All, > > Le sam. 11 avr. 2020 à 12:48, Etienne Champetier > <champetier.etie...@gmail.com> a écrit : > > > > Hello OpenWrt hackers, > > > > I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and > > would like to do hardware accelerated statefull bridge firewalling. My > > end goal is to learn and make PhanTap > > (https://github.com/nccgroup/phantap) work at line rate. > > > > MT7621 supports flow offload, so the high level idea would be to: > > - create a linux bridge with 2 ports (say lan4/lan5) > > - disable normal switch offload (do not forward just based on mac > > dest) and have the packets go through netfilter > > Big thanks to Qingfang for the tip, for this part I just disabled MAC leaning > > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -1319,6 +1319,9 @@ mt7530_setup(struct dsa_switch *ds) > /* Enable consistent egress tag */ > mt7530_rmw(priv, MT7530_PVC_P(i), PVC_EG_TAG_MASK, > PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT)); > + > + /* hack */ > + mt7530_set(priv, MT7530_PSC_P(i), SA_DIS); > } > > /* Setup port 5 */ > > > - have netfilter create/install flow offload rules for most > > connections like we do for the routing case.
Just trying to have software flow offloading for bridge working on RB750Gr3 (Linux 5.4) sysctl -w net.bridge.bridge-nf-call-iptables=1 In iptables I see the FLOWOFFLOAD rule # iptables-save ... -A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule -A FORWARD -m comment --comment "!fw3: Traffic offloading" -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD ... In conntrack I see [OFFLOAD] connections # cat /proc/net/nf_conntrack ipv4 2 tcp 6 src=192.168.1.2 dst=192.168.1.15 sport=56018 dport=22 packets=29858 bytes=1609629 src=192.168.1.15 dst=192.168.1.2 sport=22 dport=56018 packets=57155 bytes=20636422 [OFFLOAD] mark=0 zone=0 use=3 But if I add an iptables LOG rule # iptables -A forwarding_rule -j LOG --log-prefix "ipt forward: " --log-level 4 # logread -f ... Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.430466] ipt forward: IN=br-lan OUT=br-lan PHYSIN=lan5 PHYSOUT=lan2 MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15 DST=192.168.1.2 LEN=148 TOS=0x10 PREC=0x00 TTL=64 ID=57031 DF PROTO=TCP SPT=22 DPT=56018 WINDOW=2687 RES=0x00 ACK PSH URGP=0 Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.454055] ipt forward: IN=br-lan OUT=br-lan PHYSIN=lan2 PHYSOUT=lan5 MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2 DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=40139 DF PROTO=TCP SPT=56018 DPT=22 WINDOW=1316 RES=0x00 ACK URGP=0 ... Same test with 2 separate interfaces (GL-AR150 / Linux 4.19): # logread -f Sat Apr 25 22:04:40 2020 kern.warn kernel: [ 968.671777] ipt forward: IN=br-lan OUT=br-lan PHYSIN=eth1 PHYSOUT=eth0 MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15 DST=192.168.1.2 LEN=116 TOS=0x10 PREC=0x00 TTL=64 ID=48741 DF PROTO=TCP SPT=22 DPT=58094 WINDOW=2165 RES=0x00 ACK PSH URGP=0 Sat Apr 25 22:04:40 2020 kern.warn kernel: [ 968.698088] ipt forward: IN=br-lan OUT=br-lan PHYSIN=eth0 PHYSOUT=eth1 MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2 DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=31502 DF PROTO=TCP SPT=58094 DPT=22 WINDOW=83 RES=0x00 ACK URGP=0 # grep 192.168.1.15 /proc/net/nf_conntrack ipv4 2 tcp 6 src=192.168.1.2 dst=192.168.1.15 sport=58094 dport=22 packets=461 bytes=40449 src=192.168.1.15 dst=192.168.1.2 sport=22 dport=58094 packets=252 bytes=35034 [OFFLOAD] mark=0 zone=0 use=3 So software flow offload seems broken with bridge :( (I'll do some more tests with classic distros and latest Linux version) > > - enjoy > > > > My questions are: > > - will the hardware let me do that (any restrictions on the flow > > offload rules or ...) ? > > - is it already possible with OpenWrt master (I was not able to have a > > bridge without offload yet) ? > > - any pointer to ongoing work in that area (while writing this email I > > just found NF_CONNTRACK_BRIDGE) > > > > Thanks > > Etienne _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel