| Message ID | 20190208194018.20325-1-gert@greenie.muc.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [Openvpn-devel] Add unknown-unicast flooding to p2mp tap bridge. | expand |
Hi, On Fri, Feb 08, 2019 at 08:40:18PM +0100, Gert Doering wrote: > Enable flooding of "unknown-unicast" packets from the server to > all connected clients (+tap). Hrmph, this is incomplete. While it enables flooding of UU-Packets "from client 1 to client 2", packets coming in from the TAP interface towards an UU MAC will still be dropped. "More code paths in multi.c". But I still like feedback on this patch. As I said, normal switches behave like this (UU is flooded, as is broad- and multicast) but it seems James was afraid of flooding clients with "stuff they do not want". So, we could have an option here. Options! We need more options! :-) gert
Hi, On Fri, Feb 08, 2019 at 08:45:53PM +0100, Gert Doering wrote: > On Fri, Feb 08, 2019 at 08:40:18PM +0100, Gert Doering wrote: > > Enable flooding of "unknown-unicast" packets from the server to > > all connected clients (+tap). > > Hrmph, this is incomplete. And broken. Packets coming in "from TAP" do not trigger MAC learning, so if you ping "from client 1" to "out the tap", every single ping packet client 1 -> tap will trigger an Fri Feb 8 20:47:39 2019 us=707460 freebsd-82-amd64/2001:608:0:814::f000:2 MULTI: unknown unicast destination [00:bd:50:58:45:00], flood ... we do have a trac ticket regarding MAC learning and TAP interface, so it seems I need to revisit this... "Now I see why our code does not do UU flooding". gert
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c index 55c167b..aa5ae26 100644 --- a/src/openvpn/multi.c +++ b/src/openvpn/multi.c @@ -2689,6 +2689,13 @@ multi_process_incoming_link(struct multi_context *m, struct multi_instance *inst } c->c2.to_tun.len = 0; } + else + { + /* flood "unknown unicast" packets */ + msg(D_MULTI_LOW, "MULTI: unknown unicast destination [%s], flood", + mroute_addr_print(&src, &gc)); + multi_bcast(m, &c->c2.to_tun, m->pending, NULL); + } } } #ifdef ENABLE_PF
Enable flooding of "unknown-unicast" packets from the server to all connected clients (+tap). These are packets that are sent to an unknown destination MAC address and which are not broadcast/multicast packets. "Normal" switches also flood these packets, which allows client-to-client MAC learning without having to have an initial broadcast packet. Without the patch, the p2mp tap server will only forward such packets to the tap interface on the host. This is only active if --client-to-client is configured on the server. Signed-off-by: Gert Doering <gert@greenie.muc.de> --- src/openvpn/multi.c | 7 +++++++ 1 file changed, 7 insertions(+)