<hurricos>
mrnuke: rebased and merged https://github.com/Hurricos/realtek-poe/pull/36. I started reading the actual code. It made sense, though I don't know enough about C to thoroughly review. I have not attempted to rebuild.
killgufo has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
dangole has joined #openwrt-devel
* dangole
just spent hours debugging the weirdest issue with nftables/fw4 he has had so far
<dangole>
imagine: you got bridge-vlans and wifi APs interfaces (mediatek) which attach to some of interfaces represented by that bridge.
<dangole>
now, weirdly, traffic from wifi, while ending up in the correct bridge, will be filtered by nftables
<dangole>
that doesn't matter as long that was going to happen anyway, ie. for traffic crossing layer-2 boundaries
<dangole>
but it prevents traffic between WiFi and other bridge ports
<dangole>
solution: change defaults in /etc/config/firewall forwarding to ACCEPT
al has joined #openwrt-devel
<dangole>
what on earth is happening there?!
<dangole>
and no, no bridger, no WED, no flow offloading, ...
<russell-->
presumably wifi iface is ap-mode?
<dangole>
russell--: yes, ap mode
<dangole>
like, as if bridge vlan filtering causes streams to end up in nftables
<dangole>
the same issue does not occur if bridge-vlans aren't used
<dangole>
ok, did another round of testing, and it's really like that. no bridge VLAN filtering => all works as expected, wifi clients can communicate with hosts on the DSA switch physical ports.
<dangole>
adding bridge-vlans into the mix makes the traffic from wlan to other bridge ports end up being answer as UNREACHABLE by the router, despite all this supposedly being the same layer-2 domain.
<dangole>
setting forward default policy to ACCEPT fixes it
<dangole>
(though this should supposedly only affect layer-3 traffic)
rmilecki has quit [Quit: Konversation terminated!]