Re: [PATCH RFC 1/3] net/tun: Ensure tun devices have a MAC address

[Chuck Lever III <chuck.lever@oracle.com>]

> On May 5, 2023, at 12:59 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> On Fri, 05 May 2023 11:42:17 -0400
> Chuck Lever <cel@kernel.org> wrote:
> 
>> From: Chuck Lever <chuck.lever@oracle.com>
>> 
>> 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@oracle.com>
>> ---
>> 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