Cody Schuffelen <schuffelen@xxxxxxxxxx> 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 <schuffelen@xxxxxxxxxx> > Acked-by: Alistair Strachan <astrachan@xxxxxxxxxx> > Acked-by: Greg Hartman <ghartman@xxxxxxxxxx> > --- > First version: https://lkml.org/lkml/2018/7/27/947 > First review: https://lore.kernel.org/lkml/1535460343.5895.56.camel@xxxxxxxxxxxxxxxx/ > Second version: https://lore.kernel.org/lkml/20180926194324.71290-1-schuffelen@xxxxxxxxxx/ > 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
