Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device

2 messages, 2 authors, 2018-11-21 · open the first message on its own page

Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device

From: Kalle Valo <hidden>
Date: 2018-10-06 11:52:34

Cody Schuffelen [off-list ref] 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 connection 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 add link eth0 name wlan0 type virt_wifi

You may have to rename or otherwise hide the eth0 from your connection
manager, 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.

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 <redacted>
Acked-by: Alistair Strachan <redacted>
Acked-by: Greg Hartman <redacted>
---
First version: https://lkml.org/lkml/2018/7/27/947
First review: https://lore.kernel.org/lkml/1535460343.5895.56.camel@sipsolutions.net/
Second version: https://lore.kernel.org/lkml/20180926194324.71290-1-schuffelen@google.com/
Second review: https://www.lkml.org/lkml/2018/9/27/228
Second review: https://www.lkml.org/lkml/2018/9/27/229
Second review: https://www.lkml.org/lkml/2018/9/27/669

Thanks for all the comments on v2! I believe I've addressed all of them
here. I've also added changes to react better to the netdev going down,
canceling ongoing scans and rejecting wifi network connection requests.

I wasn't completely clear on whether I should change the title (net-next
to mac80211-next) so I left it as is for v3 to try to keep the patchwork
series together.
I already said in v2 that you should not mark this for net-next as this
goes to mac80211-next (if it gets accepted), now you are just
unnecessarily confusing people.

-- 
Kalle Valo

Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device

From: Cody Schuffelen <hidden>
Date: 2018-11-21 03:20:40

I already said in v2 that you should not mark this for net-next as this
goes to mac80211-next (if it gets accepted), now you are just
unnecessarily confusing people.
My fault, I misunderstood. The next version will be named correctly.

The new version is uploaded here: https://lkml.org/lkml/2018/11/21/251
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help