On 02/01/2017 01:07 PM, Stephen Morris wrote:
> On 1/2/17 8:27 am, Rick Stevens wrote:
>> On 01/31/2017 01:47 PM, Stephen Morris wrote:
>>>> $ rfkill unblock wifi
>>>> OR
>>>> $ nmcli radio wifi on
>>>> IF
>>>> $ systemctl is-active NetworkManager
>>>> active
>>>> AND
>>>> subsequently
>>>> $ nmcli device wifi list
>>>> to show the APs within the range.
>>>>
>>>> $ rpm -qi NetworkManager-wifi | grep Summary
>>>> Summary : Wifi plugin for NetworkManager
>>>>
>>>> It is installed, right?
>>>>
>>>>> One question I have, in the 8814 instructions above you mentioned:
>>>>>
>>>>> // Adds missing Vendor/Product ID
>>>>> $ sed -i '/0xA834/ a\\t{USB_DEVICE(0x7392, 0xA833), .driver_info
=
>>>>> RTL8814A}, /* Edimax - Edimax */' os_dep/linux/usb_intf.c
>>>>>
>>>>> Should the values inside the USB_DEVICE brackets be the idVendor and
>>>>> idProduct numbers mentioned in the dmesg output above?
>>>>>
>>>> It is not for for D-Link DWA-192 - VID/PID 2001:331a is already there
>>>>
https://github.com/diederikdehaas/rtl8814AU/blob/driver-4.3.21/os_dep/lin...
>>>>
>>>>
>>>>
>>>>
>>> I've isolated one problem I have with this. Device wlp4s6 is still there
>>> and it is an old pci wireless device that I thought was dead. It looks
>>> like it wasn't and all the time that I thought I was using the DWA192 I
>>> was actually using the pci device, so I need to provide an apology to
>>> everyone who provided help on this, I was working under a false
>>> impression.
>>>
>>> But having compiled the 8814au driver that I downloaded from the web
>>> site you provided it seems to be using working now on the 5GHz channel,
>>> but the device has a blue light around the middle of it that the driver
>>> seems to be flashing all the time. When the device is active the light
>>> should be permanently on and goes out when connection to the net is
>>> lost. I could switch the light off but that defeats the purpose of what
>>> it is for. Under windows that process works correctly.
>>>
>>> In network manager the device it is talking to shows this: wlp3s0u2
>>> (0E:13:3D:F9:D2:A4). I thought the information within the brackets was
>>> the mac address of the device, but if I am correct it has determined the
>>> mac address incorrectly.
>> Yes, that should be the MAC address of the device. The newer kernels
>> number the network devices in the order they're discovered on the bus
>> and name them according to their position in the bus (e.g. "p4s0"
>> meaning PCI device 4, subdevice 0). Typically hardwired stuff starts
>> off with "en", wireless with "wl". Toss in USB and I'm
not sure what
>> they'd be.
>>
>> In your case, the PCI device is probably found first and would be, by
>> default, the one NM tries to use. Your USB dongle would probably be
>> discovered last and you'll need to tell NM to use it in place of the
>> PCI card.
>>
>> Again, "ip link show" will show you the various network devices you
>> have, along with their names and in the "link/ether" line for each
>> device, the MAC address of the device. You can then use "ethtool -i
>> <devicename>" to see which driver that device is using. Make note of
>> the MAC address of your new device and make sure it's using the driver
>> you expect it to use.
>>
>> If you really want to start from scratch, then in NM, I would delete
>> any existing configurations you have, then click "Add", then select
>> "Wi-Fi" in the "Connection Type" window. In the
"Wi-Fi" tab, fill in
>> the SSID of your wireless network, select "Client" (or
"Managed") in
>> the "Mode" field, then use the drop-down in "Device" and
select the MAC
>> of the new device.
>>
>> Click the "Wi-Fi Security" tab, fill in the appropriate data. Finally,
>> click the "General" tab and tick the "Automatically connect to
this
>> network when it is available" option, then click "Save".
Hopefully,
>> it'll come right up with a DHCP address. If not, right-click on the NM
>> applet, disable networking, then re-enable it.
> Yesterday, after sending this message, I changed the contents within the
> brackets to the correct mac address, because as well as the entry in the
> list for the old pci card there was an entry with no device but had the
> correct the correct mac address within brackets.
> This morning I tried to compile a beta driver that from the website I
> got the impression was designed to support the rtl8812au, rtl8814au and
> rtl8821au chipsets but when compiled it produced and 8812.ko kernel
> module which when activated Fedora would not use for the device as the
> device could not be activated by networkmanager.
> Consequently I have just gone back to the rtl8814au driver and activated
> that which has then immediately enable the device. When I look at
> networkmanager at the existing definitions I was looking at yesterday
> that had the 3 devices in the 'Restrict to Device' list, that drop down
> list now only has one entry which is the entry for the usb device with
> the correct mac address (wlp3s0u2 (6C:72:20:00:AC:C4)). I'm not sure
> what the u2 in the device name means, but I have 9 usb ports which are a
> mixture of usb 2 and usb 3 ports for 8 of the ports, and a 9th port that
> is self booting to allow updating of the motherboard bios from a usb stick.
> My ethernet device has device name enp7s0.
If I recall correctly, "wlp3s0u2" would mean wireless (wl), PCI bus 3
(p3), subdevice zero (s0), unit 2 (u2). Numbering/naming on USB buses
is more of a guess, but I'd assume the USB controller shows up in PCI
bus 3 and the third device on the first hub run by that controller is
the device.
Your PCI-based device is wired network (en), PCI bus 7 (p7), subdevice
0 (s0).
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- The trouble with troubleshooting is that trouble sometimes -
- shoots back. -
----------------------------------------------------------------------
I have
placed the source code in the required location for dkms to build
the module and found that at boot time there are messages to say that it
is starting the dkms build and install and a message to say that is
successfully started the dkms build and install, but the network does
not become available because it appears there is no modprobe done after
the kernel install process by dkms.
Do you know how I control this and ensure that it get done, as doing a
man dkms, I can't see anything in the dkms.conf information that would
control this?
regards,
Steve
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org