Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 6A021607F4
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Cody Schuffelen <schuffelen@google.com>
Cc:     Johannes Berg <johannes@sipsolutions.net>,
        "David S . Miller" <davem@davemloft.net>,
        linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
        netdev@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH net-next v2] wireless-drivers: rtnetlink wifi simulation device
References: <20180926194324.71290-1-schuffelen@google.com>
Date:   Thu, 27 Sep 2018 07:33:01 +0300
In-Reply-To: <20180926194324.71290-1-schuffelen@google.com> (Cody Schuffelen's
        message of "Wed, 26 Sep 2018 12:43:24 -0700")
Message-ID: <875zyrr24i.fsf@kamboji.qca.qualcomm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Cody Schuffelen <schuffelen@google.com> writes:

> This device takes over an existing network device and produces a
> new one that appears like a wireless connection, returning enough canned
> responses to nl80211 to satisfy a standard network manager. If
> necessary, it can also be set up one step removed from an existing
> network device, such as through a vlan/80211Q or macvlan connection to
> not disrupt the existing network interface.
>
> To use it to wrap a bare ethernet connection:
>
> ip link set eth0 down
> ip link set eth0 name buried_eth0
> ip link set buried_eth0 up
> ip link add link buried_eth0 name wlan0 type virt_wifi
>
> eth0 is renamed to buried_eth0 to avoid a network manager trying to
> manage it, as the original network link will become unusuable and only
> the wireless wrapper will be functional. This can also be combined with
> vlan or macvlan links on top of eth0 to share the network between
> distinct links, but that requires support outside the machine for
> accepting vlan-tagged packets or packets from multiple MAC addresses.
>
> This is being used for Google's Remote Android Virtual Device project,
> which runs Android devices in virtual machines. The standard network
> interfaces provided inside the virtual machines are all ethernet.
> However, Android is not interested in ethernet devices and would rather
> connect to a wireless interface. This patch allows the virtual machine
> guest to treat one of its network connections as wireless rather than
> ethernet, satisfying Android's network connection requirements.
>
> We believe this is a generally useful driver for simulating wireless
> network connections in other environments where a wireless connection is
> desired by some userspace process but is not available. Future work can
> also include exporting the wireless control plane to userspace, so the
> device can configure the behavior of the simulated wireless network
> itself.
>
> This is distinct from other testing efforts such as mac80211_hwsim by
> being a cfg80211 device instead of mac80211 device, allowing straight
> pass-through on the data plane instead of forcing packaging of ethernet
> data into mac80211 frames.
>
> Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
> Acked-by: Alistair Strachan <astrachan@google.com>
> Acked-by: Greg Hartman <ghartman@google.com>
> Signed-off-by: Cody Schuffelen <schuffelen@google.com>
> ---
> Original change: https://lore.kernel.org/lkml/5b5b8e09.1c69fb81.c693c.0acd@mx.google.com/
> First review: https://lore.kernel.org/lkml/1535460343.5895.56.camel@sipsolutions.net/
>
> Thanks for the detailed review! I believe I've addressed all comments.

BTW, this will likely go through mac80211-next, so don't add net-next to
the subject to avoid Dave getting confused. But no need to resend
because of this.

-- 
Kalle Valo