SCIENTIFIC-LINUX-USERS Archives

January 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Tue, 26 Jan 2016 22:52:01 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
On 01/26/2016 09:41 PM, jdow wrote:
> On 2016-01-26 05:17, Tom H wrote:
>> On Tue, Jan 26, 2016 at 10:12 AM, David Sommerseth
>> <[log in to unmask]> wrote:
>>> On 26/01/16 08:13, Yasha Karant wrote:
>>>>
>>>> As neither VMware player nor VirtualBox seem capable of providing a MS
>>>> Win guest with any form of Internet access to an 802.11 connection 
>>>> from
>>>> the host (in both cases, the claim from a MS Win 7 Pro guest is that
>>>> there is no networking hardware, despite being shown by the guest as
>>>> existing), it is possible that the "native" (ships with) vm
>>>> functionality of EL 7 may address this issue.
>>>
>>> So you want the guest to have full control over the wireless network
>>> adapter?  That is possible, but only through a hypervisor ... and these
>>> days, unless the adapter supports PCI SR-IOV [1], you need to disable
>>> the interface (unload all drivers, unconfigure it) and allow your guest
>>> to access the PCI interface directly (so called PCI passthrough).
>>>
>>> With PCI SR-IOV support (this requires hardware support), you can
>>> actually split a physical PCI device also supporting SR-IOV into
>>> multiple "virtual functions" (VF) which results in more PCI devices
>>> appearing on your bare-metal host and you can then grant a VM access to
>>> this VF based PCI device.  For network cards, that also includes a
>>> separate MAC address per VF.
>>>
>>> [1] <http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/>
>>>
>>> But the downside, from your perspective, all this requires a 
>>> hypervisor.
>>
>> IIRC, Yasha's issue with 802.11 is that he cannot bridge a wifi NIC (I
>> pointed out in Oct/Nov that it's because the kernel prevents it).
>
> Have you gone into /dev and made the appropriate permissions change on 
> the device?
>
> {o.o}
Obviously, there is some point I am missing:

The physical 802.11 device has an instantiated driver interface wlp61s0 
on the machine in question.

bash-4.2$ ls -a /dev/wl*
ls: cannot access /dev/wl*: No such file or directory
bash-4.2$ ls /dev | grep -a wl
bash-4.2$
bash-4.2$ locate wlp61s0
/home/ykarant/.gkrellm2/data/net/wlp61s0
/var/lib/NetworkManager/dhclient-568cb7e6-daa1-4768-b13e-0ac4d3d61864-wlp61s0.lease
/var/lib/NetworkManager/dhclient-646c0914-6eff-4c67-ad42-330f130e6f8c-wlp61s0.lease
/var/lib/NetworkManager/dhclient-6ece21f4-61c7-47a1-bc0f-85b36632da7e-wlp61s0.lease
/var/lib/NetworkManager/dhclient-76d98a93-e645-4da2-b190-e2de2e2b9333-wlp61s0.lease
/var/lib/NetworkManager/dhclient-8811aaa3-40a9-43f7-b1d5-7d00f3e0c4fc-wlp61s0.lease
/var/lib/NetworkManager/dhclient-b31e96c6-392c-4c73-a6a5-8532908a0e44-wlp61s0.lease
/var/lib/NetworkManager/dhclient-ba0ab7fc-e666-4969-86d9-7e343ea8f722-wlp61s0.lease
/var/lib/NetworkManager/dhclient-c806cddf-1d8b-46da-a2a8-40bcf7e9956e-wlp61s0.lease
/var/lib/NetworkManager/dhclient-ef685b95-88bf-4a0d-acea-837443a026c0-wlp61s0.lease
/var/lib/NetworkManager/dhclient-wlp61s0.conf

ATOM RSS1 RSS2