> On May 5, 2023, at 12:59 PM, Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 05 May 2023 11:42:17 -0400 > Chuck Lever <cel@xxxxxxxxxx> wrote: > >> From: Chuck Lever <chuck.lever@xxxxxxxxxx> >> >> A non-zero MAC address enables a network device to be assigned as >> the underlying device for a virtual RDMA device. Without a non- >> zero MAC address, cma_acquire_dev_by_src_ip() is unable to find the >> underlying egress device that corresponds to a source IP address, >> and rdma_resolve_address() fails. >> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> >> --- >> drivers/net/tun.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c >> index d4d0a41a905a..da85abfcd254 100644 >> --- a/drivers/net/tun.c >> +++ b/drivers/net/tun.c >> @@ -1384,7 +1384,7 @@ static void tun_net_initialize(struct net_device *dev) >> >> /* Point-to-Point TUN Device */ >> dev->hard_header_len = 0; >> - dev->addr_len = 0; >> + dev->addr_len = ETH_ALEN; >> dev->mtu = 1500; >> >> /* Zero header length */ > > This is a bad idea. > TUN devices are L3 devices without any MAC address. > This patch will change the semantics and break users. I suspected this might be a problem, thanks for the quick feedback. > If you want an L2 address, you need to use TAP, not TUN device. We can't assume how the VPN is implemented. In our case, it's Tailscale, which creates a tun device. wireguard (in kernel) is the same. We would prefer a mechanism that can support tun. Having a MAC is the easiest way forward, but is not a hard requirement AFAICT. -- Chuck Lever
