Just tested a few TP-Link USB WiFi dongles: summary TL-WN722N and TL-WN823N work, TL-WN821N has problems; it comes up without errors, but when being listed, reports being down even though it is up and working; see below. This is just for info; note the driver is rtl8192cu which I suspect is the problem. (BBB ver c, kernel: 4.1.13-ti-r36, Debian Jessie, release 8.2). If you are close to router, then the TL-WN823N is small and seems to work well. No need to read the rest of this post unless you are interested in details.+
sudo ip ro flush dev wlan0
sudo ip a flush dev wlan0
sudo ip link set dev wlan0 down
sudo ip link set dev wlan0 up
sudo ip addr add 192.168.0.174/24 dev wlan0
ip link show dev wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether 10:fe:ed:12:2d:8b brd ff:ff:ff:ff:ff:ff
sudo ip route add 192.168.0.0/24 dev wlan0 metric 303
ip route show
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.244
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.174
192.168.0.0/24 dev wlan0 scope link metric 303
192.168.0.118 via 127.0.0.1 dev lo metric 202
ping -c 2 192.168.0.1 -I wlan0
PING 192.168.0.1 (192.168.0.1) from 192.168.0.174 wlan0: 56(84) bytes of data.
From 192.168.0.174 icmp_seq=1 Destination Host Unreachable
From 192.168.0.174 icmp_seq=2 Destination Host Unreachable
— 192.168.0.1 ping statistics —
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1006ms
pipe 2
ifconfig
eth0 Link encap:Ethernet HWaddr d0:5f:b8:fc:51:e2
inet addr:192.168.0.244 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3146 errors:0 dropped:189 overruns:0 frame:0
TX packets:867 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:271925 (265.5 KiB) TX bytes:102062 (99.6 KiB)
Interrupt:170
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:512 errors:0 dropped:0 overruns:0 frame:0
TX packets:512 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:42032 (41.0 KiB) TX bytes:42032 (41.0 KiB)
wlan0 Link encap:Ethernet HWaddr 10:fe:ed:12:2d:8b
inet addr:192.168.0.174 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether d0:5f:b8:fc:51:e2 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.244/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 10:fe:ed:12:2d:8b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.174/24 scope global wlan0
valid_lft forever preferred_lft forever
4: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether d0:5f:b8:fc:51:e0 brd ff:ff:ff:ff:ff:ff
inet 192.168.7.2/30 brd 192.168.7.3 scope global usb0
valid_lft forever preferred_lft forever
HOWEVER, FROM UBUNTU HOST, one can ssh to 192.168.0.174 and also
ping -c 2 192.168.0.174
PING 192.168.0.174 (192.168.0.174) 56(84) bytes of data.
64 bytes from 192.168.0.174: icmp_seq=1 ttl=64 time=0.447 ms
64 bytes from 192.168.0.174: icmp_seq=2 ttl=64 time=0.412 ms
but could this be going through the eth0 connection on the BBB?
— 192.168.0.174 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.412/0.429/0.447/0.027 ms
This is probably a Debian problem with the rtl8192cu driver, although it works with the TL-WN823N; I thought others might like to know not to use the TL-WN821N to save time