I'm a little surprised it doesn't actually. I've got half a dozen of them, in a Pi they just work. Garden variety USB wifi adapter, comes in big or small depending on the antenna size, $4-15 on eBay.
ifquery --list shows only lo
lsmod shows:
Code: Module Size Used by
rtl8xxxu 73728 0
rtl8192cu 94208 0
rtl_usb 24576 1 rtl8192cu
rtl8192c_common 65536 1 rtl8192cu
rtlwifi 98304 3 rtl_usb,rtl8192c_common,rtl8192cu
usblp 20480 0
ip_tables 24576 0
x_tables 32768 1 ip_tables
autofs4 40960 0
uas 20480 0
usb_storage 61440 1 uas
dmesg | grep rtl shows:
Code: [ 7.043104] rtl8192cu: Chip version 0x10
[ 7.137326] rtl8192cu: MAC address: 48:02:2a:9d:4d:57
[ 7.137346] rtl8192cu: Board Type 0
[ 7.137584] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 7.137706] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 7.138374] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 7.139636] usbcore: registered new interface driver rtl8192cu
[ 7.150127] usbcore: registered new interface driver rtl8xxxu
[ 7.162122] rtl8192cu 1-1:1.0 wlx48022a9d4d57: renamed from wlan0
[ 8.852083] rtl8192cu: MAC auto ON okay!
[ 8.880483] rtl8192cu: Tx queue select: 0x05
[ 9.458969] rtl8192cu: MAC auto ON okay!
[ 9.488545] rtl8192cu: Tx queue select: 0x05
[ 352.137643] rtl8192cu: MAC auto ON okay!
[ 352.188560] rtl8192cu: Tx queue select: 0x05
[ 668.148896] rtl8192cu: MAC auto ON okay!
[ 668.203780] rtl8192cu: Tx queue select: 0x05
[ 889.037179] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x90e1317
[ 889.037224] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut! status:0xffffffed value=0xf000690e
[ 889.037267] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x324072c
[ 889.037439] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x1a0335
[ 1186.287879] rtl8192cu: Chip version 0x10
[ 1186.395365] rtl8192cu: MAC address: 48:02:2a:9d:4d:57
[ 1186.395406] rtl8192cu: Board Type 0
[ 1186.395544] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 1186.395620] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 1186.396401] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
[ 1186.425928] rtl8192cu 1-1:1.0 wlx48022a9d4d57: renamed from wlan0
[ 1186.461059] rtl8192cu: MAC auto ON okay!
[ 1186.492930] rtl8192cu: Tx queue select: 0x05
[ 1187.071627] rtl8192cu: MAC auto ON okay!
[ 1187.101405] rtl8192cu: Tx queue select: 0x05
[ 1530.115320] rtl8192cu: MAC auto ON okay!
[ 1530.158109] rtl8192cu: Tx queue select: 0x05
[ 1846.131275] rtl8192cu: MAC auto ON okay!
[ 1846.187095] rtl8192cu: Tx queue select: 0x05
A cell phone is my only internet connection, through the wifi hotspot. So I can't just apt-get anything yet. I can mount the SD in a reader on a Pi and get things on and off that way. The firmware seems to be there.
I have an interfaces file that generally works fine under Debian consisting of
Code: auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet dhcp
wireless-essid Moto_lte
that didn't work, the stock one didn't work.
What does
gives?
Your dmesg gives
Code: [ 7.162122] rtl8192cu 1-1:1.0 wlx48022a9d4d57: renamed from wlan0
as it say "renamed from", not "renamed to" wlan0. Should the wifi device name be wlx48022a9d4d57 ?
ip a says:
Code: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether de:0a:fc:15:fc:d9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::dc0a:fcff:fe15:fcd9/64 scope link
valid_lft forever preferred_lft forever
3: wlx48022a9d4d57: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 2e:31:c8:66:35:14 brd ff:ff:ff:ff:ff:ff
Flagged as up with no carrier. I run my wifi open, no password. Usually my simple interfaces file just works without any password junk. This ip a was done with the stock one.
I hope I don't have to live with that name forever. Looks like it's 12 hexadecimal digits with wlx in front, like some sort of pointer.
There's much I don't like about Linux, I was an active OpenBSD user for 15 years or so. In the BSDs a device driver is given a name like rtl for realktek or ath for Atheros. The devices are named for the drivers, hence the manufacturer. An Atheros card might be /dev/ath0. Each driver has a man page so you can learn its particulars. Patches are done the old fashioned way, by patching source and recompiling, so you could locate ath.c because you've got the source around.
But you can ratchet the stupidity down a notch by falling back to the previous scheme:
https://www.freedesktop.org/wiki/Softwar...faceNames/
By creating /etc/systemd/network/99-default.link that's a symlink to /dev/null it turns it off.
I'll find out after I reboot into no-network-land. At least the name will make more sense even if it still doesn't work. Really, has anybody thought about the security implications of mistyping one of those gadawful names?
06-05-2018, 02:32 PM
Alright, that didn't work, I guess I'm stuck calling it wlx48022a9d4d57.
But I re-did my simple interfaces file (using the wlx48022a9d4d57 name) and rebooted. Now ip a shows
Code: : lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether de:0a:fc:15:fc:d9 brd ff:ff:ff:ff:ff:ff
3: wlx48022a9d4d57: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 48:02:2a:9d:4d:57 brd ff:ff:ff:ff:ff:ff
inet 192.168.43.117/24 brd 192.168.43.255 scope global wlx48022a9d4d57
valid_lft forever preferred_lft forever
inet6 fe80::4a02:2aff:fe9d:4d57/64 scope link
valid_lft forever preferred_lft forever
I got a lease, and an IP. Sort of. Still can't ping the AP/router, or www.google.com. BUT oddly enough I can get back in. On a phone I scanned my subnet and saw it. So I FTPed a file out as a test. Then I started wondering what was open so I port scanned it with Zenmap on my portable Pi.
I get "destination host unreachable" trying to get out of the Rock but I can reach in. Sounds like a netmask problem to me but I don't know where it would be.
It's all an intermittent mess, very discouraging. It worked for a little while, I did apt-get update and upgrade, installed joe and mc. I started a big install of something that needed X and the network quit working again. Can't even ping the phone 3 feet away. Maybe this isn't the image to be using.
06-06-2018, 12:16 AM
(This post was last modified: 06-06-2018, 12:17 AM by cooker.)
most likely, can't ping a domain name is because you have not set up /etc/resolv.conf properly.
can you ping your router(phone) by ip# ?
recently version of debian has /etc/resolv.conf controlled by daemon (NetworkManager.service ? pls double check) so that direct edit on this file is not stable. I cannot recall detail but there is a lot of help on google about this.
You can live with your infrastructure described above, I am sure you can work it out.
(06-05-2018, 01:10 PM)ab1jx Wrote: But you can ratchet the stupidity down a notch by falling back to the previous scheme:
https://www.freedesktop.org/wiki/Softwar...faceNames/
By creating /etc/systemd/network/99-default.link that's a symlink to /dev/null it turns it off.
Yes, it is nightmare. I thought I had managed to turn it off before, using that symlink trick. There is also the option of passing 'net.ifnames=0' to the kernel at boot. (This would be via the /boot/efi/extlinux/extlinux.conf file, and adding to the 'append' line for kernel-latest.
Which image are you actually running, as I gather it is a debian one, but what flavour, and what version?
(06-06-2018, 12:16 AM)cooker Wrote: recently version of debian has /etc/resolv.conf controlled by daemon (NetworkManager.service ? pls double check) so that direct edit on this file is not stable. I cannot recall detail but there is a lot of help on google about this.
I had to poke DNS resolving at one point on a image as something was broken. The worked well on ubuntu to smack a running system into submission...
Code: sudo mkdir /run/resolvconf && sudo tee "nameserver 1.1.1.1" /run/resolvconf/resolv.conf
It may be necessary to use nmtui / nmcli to configure the networking if NetworkManager is in use...
06-07-2018, 07:00 PM
(This post was last modified: 06-07-2018, 07:01 PM by ab1jx.)
Well, I'm using Armbian, at least for now. It has way more fancy stuff and daemons doing nonsense than I like but Arch I think doesn't even have HDMI working on the Rock64. OpenBSD says they require a serial console as part of the install (for ARM machines in general). What I like about Linux is that because of the popularity more things will build under it. It's like pulling hen's teeth getting some things to build under OpenBSD because writers of configure scripts don't anticipate it.
Anyway, the rtl8192 doesn't work any better in Armbian than in Ayufan's Debian. Very unreliable, works maybe 1/5 of the time. I don't know where you guys got your driver but it's crap. The one Raspbian uses works much better. The one in arm64 Buster is at least different when I look at an nm listing of the ko files. I haven't used it much, I just use the Pi's built-in wifi hardware except when I want the extra range of a gain antenna. I'll look at it when I'm on the Pi.
I'm using a Ralink $4 micro USB wifi that OpenBSD didn't have a driver for last time I tried it. That was probably at least 5 years ago.
But I bought a Rock64 for the extra RAM over the Pi. My Nikon D5200 takes RAW files that are 6000x400x pixels and 14 bits/color/pixel. Gimp since 1.9 can handle the full color depth but it's a large amount of data, on a Pi it takes 5 minutes to apply some of the filters to an image.
|
