On 02/03/2017 05:34 PM, Stephen Morris wrote: > n 3/2/17 10:35 am, Rick Stevens wrote: >> On 02/02/2017 01:07 PM, Stephen Morris wrote: >>> On 3/2/17 4:28 am, poma wrote: >>>> On 02.02.2017 14:19, poma wrote: >>>>> On 01.02.2017 22:12, Stephen Morris wrote: >>>>> [...] >>>>>> I'm about to try to interface the source code for this driver to >>>>>> dkms so >>>>>> that it will get compiled every time I boot from a new kernel, but at >>>>>> the moment I'm not sure how to tell dkms where to find the source >>>>>> code, >>>>>> so I'll have to try to investigate that. >>>>>> >>>>> "dkms.conf" of rtl8812AU is working example >>>>> https://github.com/diederikdehaas/rtl8812AU >>>>> >>>>> # journalctl -o cat -b -u dkms >>>>> Starting Builds and install new kernel modules through DKMS... >>>>> Kernel preparation unnecessary for this kernel. Skipping... >>>>> Building module: >>>>> cleaning build area... >>>>> 'make'...................................... >>>>> cleaning build area... >>>>> DKMS: build completed. >>>>> 8812au.ko: >>>>> Running module version sanity check. >>>>> - Original module >>>>> - No original module exists within this kernel >>>>> - Installation >>>>> - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/ >>>>> Adding any weak-modules >>>>> depmod...... >>>>> DKMS: install completed. >>>>> Kernel preparation unnecessary for this kernel. Skipping... >>>>> Building module: >>>>> cleaning build area... >>>>> 'make'................................ >>>>> cleaning build area... >>>>> DKMS: build completed. >>>>> 8814au.ko: >>>>> Running module version sanity check. >>>>> - Original module >>>>> - No original module exists within this kernel >>>>> - Installation >>>>> - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/ >>>>> Adding any weak-modules >>>>> depmod.... >>>>> DKMS: install completed. >>>>> Started Builds and install new kernel modules through DKMS. >>>>> >>>>> # modinfo -k $(uname -r) -n 8812au 8814au >>>>> /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko >>>>> /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko >>>>> >>>>> # modprobe -v 8812au ; modprobe -v 8814au >>>>> insmod >>>>> /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz >>>>> insmod >>>>> /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz >>>>> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko >>>>> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko >>>>> >>>>> # dmesg -t >>>>> ... >>>>> RTL871X: module init start >>>>> RTL871X: rtl8821au v4.3.14 >>>>> RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51 >>>>> usbcore: registered new interface driver rtl8821au >>>>> RTL871X: module init ret=0 >>>>> RTL871X: module init start >>>>> RTL871X: rtl8814au v4.3.21_17997.20160531 >>>>> usbcore: registered new interface driver rtl8814au >>>>> RTL871X: module init ret=0 >>>>> >>>>> >>>> DKMS - RTL8814AU, >>>> as explained for RTL8812AU here: >>>> https://github.com/diederikdehaas/rtl8812AU >>>> >>>> $ git clone https://github.com/diederikdehaas/rtl8814AU.git >>>> $ cd rtl8814AU/ >>>> ... >>>> // eventual steps, previously mentioned >>>> ... >>>> $ curl -JLO >>>> https://raw.githubusercontent.com/diederikdehaas/rtl8812AU/driver-4.3.14/dkms.conf >>>> >>>> >>>> $ sed -i 's/12/14/g' dkms.conf >>>> $ git add . >>>> $ git commit -m "Added dkms.conf" >>>> $ git tag 4.3.21_17997.20160531 >>>> >>>> $ su >>>> # DRV_NAME=rtl8814AU >>>> # DRV_VERSION=4.3.21_17997.20160531 >>>> # mkdir /usr/src/${DRV_NAME}-${DRV_VERSION} >>>> # git archive ${DRV_VERSION} | tar -x -C >>>> /usr/src/${DRV_NAME}-${DRV_VERSION} >>>> >>>> # dkms add -m ${DRV_NAME} -v ${DRV_VERSION} >>>> # dkms build -m ${DRV_NAME} -v ${DRV_VERSION} >>>> # dkms install -m ${DRV_NAME} -v ${DRV_VERSION} >>>> >>>> # modinfo 8814au -F version >>>> # modprobe -v 8814au >>>> >>>> 'modprobe' goes if the device is already plugged in, >>>> otherwise re-plug USB device, and if VID/PID of device and driver >>>> match - auto loading kicks in. >>> I think I have worked out the issue with the flashing light on the >>> device, it seems to be functioning the same way as the flashing lights >>> on ethernet pci cards, which from the functionality of the vendor >>> supplied driver under windows, is not the vendor intended mode of >>> operation. >>> >>> I now have two issues with the device, one is dkms and the other is >>> standard networking functionality. >>> >>> For dkms I have used the rtl8812au dkms.conf as my starting point. My >>> file is below. >>> >>> PACKAGE_NAME="rtl8814AU" >>> PACKAGE_VERSION="4.3.21" >>> BUILT_MODULE_NAME[0]="8814au" >>> MAKE="'make' -j3 KVER=${kernelver}" >>> CLEAN="'make' clean" >>> DEST_MODULE_LOCATION[0]="/updates/dkms" >>> AUTOINSTALL="YES" >>> >>> >>> The driver source code is stored in directory /usr/src/rtl8814AU-4.3.21, >>> does the version number in the directory name and the 'PACKAGE_VERSION' >>> in the conf file have to match the internal version number in the driver >>> for the boot time compile of the driver to work? >>> I've added the -j3 in the make to get the multi-threaded compile and >>> I've added the KVER parameter as from my search I did on the net I found >>> an article relative to an older version of Fedora that said the KVER >>> parameter must be added to get the driver compiled against the correct >>> kernel version at kernel install time (they said that without that >>> parameter the driver would be compiled against the running kernel, not >>> the newly installed kernel). >>> With the setup I have if I issue the commands: >>> sudo dkms build -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m rtl8814AU >>> -v 4.3.21 and >>> sudo dkms install -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m >>> rtl8814AU -v 4.3.21 and >>> sudo modprobe -v 8814au >>> they build, install and load the module successfully. I've also found >>> that the driver does not get loaded and used unless I issue the modprobe >>> command. >>> >>> If I issue the command journalctl -o cat -b -u dkms I only get the two >>> messages below, which are also the only two message I get shown in the >>> boot display when the driver needs to be compiled for a new kernel. >>> >>> Starting Builds and install new kernel modules through DKMS... >>> Started Builds and install new kernel modules through DKMS. >>> >>> I'm also noticing that when the driver has already been compiled and >>> installed into the kernel, and I boot my machine, the mounts for my >>> network connected nas are failing again because the network via this >>> wireless device is not available. From the flashing of the light on the >>> device this driver is doing, the network appears to not actually >>> becoming active until after the display manager is started, and in my >>> case, I physically log into KDE. >> That's normal if you don't have the network in question set to start >> at boot. You need to make sure the >> >> /etc/sysconfig/network-scripts/ifcfg-<name-of-connection> >> >> file contains "ONBOOT=yes". Otherwise, they only come up when YOUR >> instance of NetworkManager comes up (e.g. when you actually log into >> your desktop). > Thanks Rick, I have a definition in networkmanager to connect to the > 2.4GHz channel on my rounter named Linksys07468, which when I checked > the corresponding ifcfg file found that it indeed did have "ONBOOT=no". > I have changed it to yes but I don't understand why it was set that way > because I found that several days ago and changed it to yes, hence I'm > confused as to why it changed back. NM can do things to the files, depending on the "last" version of the file used. If it used a "-1" file last time, it'll set the version without the "-1" to "ONBOOT=no" so you don't end up with two profiles competing with each other. > Also I found a couple of days ago that for some reason I had two > definitions to the 5GHz channel on the router in Networkmanager both > name Linksys07468_5Ghz, one of which Networkmanager said had not been > used and the other it said had been used an hour before, so I deleted > the one that was flagged as not having been used. Looking in > /etc/sysconfig/network-scripts there is a file in there named > ifcfg-Linksys07648_5Ghz-1 which does have "ONBOOT=yes", does that ifcfg > file need to have the "-1" removed from it to match the connection name > in Networkmanager? Yes, you will. NM uses the name of the ifcfg file as the key. I believe it displays them without the "-X" in its own display. > As a side issue to this, just for info, the names of the entries I have > in Networkmanager are named to match the SSID's exposed by my router. Excellent! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If this is the first day of the rest of my life... - - I'm in BIG trouble! - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
