Timeline for nftables: duplicate broadcast packets between segments
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2020 at 20:00 | vote | accept | T2PS | ||
| Aug 20, 2020 at 20:54 | comment | added | A.B | I didn't get the time (until now) to check if nftables can do it. Looks it can do it too. | |
| Aug 20, 2020 at 20:53 | answer | added | A.B | timeline score: 6 | |
| Aug 20, 2020 at 17:53 | vote | accept | T2PS | ||
| Aug 22, 2020 at 20:00 | |||||
| Aug 19, 2020 at 14:44 | comment | added | T2PS | @A.B Your hint to use tc gave me the answer, thanks! | |
| Aug 19, 2020 at 14:44 | answer | added | T2PS | timeline score: 2 | |
| Aug 18, 2020 at 18:08 | comment | added | A.B | If the devices are not able to use a gateway (without NAT between LANs A B and C) I'm not sure this will help. There won't be a way for the return traffic to be un-NATed correctly. using stateless NAT (that's what is doing tc or maybe if it works nft) won't help the usual stateful NAT to send back the reply traffic to where it came from. | |
| Aug 18, 2020 at 16:36 | comment | added | T2PS |
Yes, the three segments in question are already routed/masqueraded to the fourth. We hadn't considered tc for this purpose yet, I'll take a closer look at it and nft ingress.
|
|
| Aug 18, 2020 at 13:13 | comment | added | A.B | In addition for return unicast traffic, the buster box would have to be configured as a router anyway | |
| Aug 18, 2020 at 13:06 | comment | added | A.B | this could be solved with tc or maybe with nftables's netdev ingress (reading again it doesn't appear egress is needed, I rewrote this comment). Here's a (not really readable) comment of mine on a similar problem which handles forwarding a broadcast to an other network using tc: unix.stackexchange.com/questions/594347/… (actually tc doesn't require a bridge). I can check later if using nftables' netdev ingress is enough for the same (you can check yourself of course). | |
| Aug 18, 2020 at 13:00 | comment | added | T2PS |
I must have read that gateway address line a dozen times earlier without picking that up, ack. Switched the dup to IPs to match the interface IPs and merged the daddr set into the dup rules. Trace shows packets appear with the right IP destination on the right interfaces, but inbound rather than out. Trace also shows ether daddr ff:ff:ff:ff:ff:ff, which would seem right if it were going in the opposite direction...
|
|
| Aug 18, 2020 at 12:31 | comment | added | A.B | check nft's man page: dup to address expects a gateway address, not a broadcast. That's just a part of your issues. They are related to handling broadcasts, which involve things at the Ethernet layer, while you're trying to work at the IP layer. | |
| Aug 18, 2020 at 11:06 | review | First posts | |||
| Aug 18, 2020 at 11:38 | |||||
| Aug 18, 2020 at 11:01 | history | asked | T2PS | CC BY-SA 4.0 |