Bug 214406

Summary: [urtwn] discard frame, too short - flakey performance - sometimes not even dhclient succeeds
Product: Base System Reporter: Dave Cottlehuber <dch>
Component: wirelessAssignee: freebsd-wireless (Nobody) <wireless>
Status: Closed FIXED    
Severity: Affects Some People CC: avos, diego.casati
Priority: ---    
Version: 11.0-RELEASE   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205477
Attachments:
Description Flags
message.log
none
service_netif_restart.log
none
tcpdump_bootps.log none

Description Dave Cottlehuber freebsd_committer freebsd_triage 2016-11-10 18:52:57 UTC 
Created attachment 176865 [details]
message.log

As reported on #freebsd-wifi and also forums, urtwn seems flakier
than under 10.3R on both rasp pi, and normal x86 hardware:

https://forums.freebsd.org/threads/57396/

```
Oct 20 13:13:28 akai kernel: wlan0: [74:da:38:7e:e6:e0] discard frame, too short (1): len 10
Oct 20 
13:13:28 akai kernel: wlan0: [74:da:38:7e:e6:e0] discard BAR frame, no BA stream, tid 0
Oct 20 13:13:28 akai kernel: wlan0: [74:da:38:7e:e6:e0] discard frame, too short (1): len 10
```

Occurs frequently in the logs and while association is quick, the system is
unable to pick up a dhcp address, even when one can see it being offered by
the the upstream AP. In my case, APs are Ubiquiti UAC PRO in a variety of
places, all within good range.


I have also enabled in /boot/loader.conf
```
# edimax wifi
legal.realtek.license_ack=1
# using 11n =1 or 11n=0 seems not to make any significant impact.
hw.usb.urtwn.enable_11n=1
```

Resulting in:

```
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   ether 74:da:38:7e:e6:e0
   inet6 fe80::76da:38ff:fe7e:e6e0%wlan0 prefixlen 64 scopeid 0x2
   inet 172.16.2.15 netmask 0xffffff00 broadcast 172.16.2.255
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g
   status: associated
   ssid skunkwerks channel 6 (2437 MHz 11g) bssid 80:2a:a8:5a:bd:3f
   regdomain FCC country US authmode WPA2/802.11i privacy ON
   deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
   protmode CTS wme roaming MANUAL
   groups: wlan
```

full logs in my gist; https://gist.github.com/dch/25079d4b7e91beb2d2e7a5f2359b6d04 and attached here.
Comment 1 Dave Cottlehuber freebsd_committer freebsd_triage 2016-11-10 18:55:09 UTC 
Created attachment 176867 [details]
service_netif_restart.log
Comment 2 Dave Cottlehuber freebsd_committer freebsd_triage 2016-11-10 18:56:20 UTC 
Created attachment 176868 [details]
tcpdump_bootps.log
Comment 3 Dave Cottlehuber freebsd_committer freebsd_triage 2016-11-10 18:58:52 UTC 
dhclient log is either this - blank - or shows a DHCPOFFER received
but dhclient never responds and so the client times out.

# dhclient wlan0
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Comment 4 Dave Cottlehuber freebsd_committer freebsd_triage 2016-11-10 19:00:45 UTC 
Fiddling with the MTU has no impact.
Comment 6 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-11-11 06:45:07 UTC 
> discard frame, too short (1): len 10
you can disable promiscuous mode to get rid of those messages (it is used by tcpdump):
ifconfig wlan0 -promisc

also, 'hw.usb.urtwn.enable_11n=0' should be equal to 'ifconfig wlan0 -ht'
Comment 7 Dave Cottlehuber freebsd_committer freebsd_triage 2017-02-25 07:40:20 UTC 
Closing this as 12.0-CURRENT runs rtwn sweet as honey now since a while.