Dolf Andringa Posted June 11, 2021 Posted June 11, 2021 Hi all, I have a few orange pi zero's and recently on 2 I had an issue with wifi AP that I am trying to properly understand. I have read some of the discussion regarding the wifi chip on the opi0 and that's not a great chip. I thoroughly agree with people that say that if you pay bottom dollar for a board, don't expect top dollar performance. And especially don't come complaining on a public FOSS forum. The only thing I am trying to do is understand the error and see if there is anything I can do to improve it. I use my orange pi zero's with a basic (custom) armbian image that starts up with a wifi AP briefly, so I can ssh in and do some config. Afterwards I reboot it and either turn wifi off altogether, or just connect as a wifi client using wpa_supplicant/ `/etc/network/interfaces.d`. So no heavy wifi AP usage. This has been working fine so far, but with 2 recent boards I couldn't connect to the wifi, and upon inspection of the logs, it showed these errors: [ 21.667120] random: crng init done [ 21.667157] random: 7 urandom warning(s) missed due to ratelimiting [ 21.692073] xradio AP-WRN: ap restarting! [ 21.731438] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 33.782692] vcc3v0: disabling [ 33.782721] vcc5v0: disabling [ 56.852083] xradio TXRX-WRN: received frame has no key status [ 56.852107] xradio TXRX-WRN: dropped received frame [ 56.852208] xradio TXRX-WRN: received frame has no key status [ 56.852218] xradio TXRX-WRN: dropped received frame [ 56.855392] xradio TXRX-WRN: received frame has no key status [ 56.855413] xradio TXRX-WRN: dropped received frame [ 56.861510] xradio TXRX-WRN: ***skb_queue_tail [ 56.973724] xradio TXRX-WRN: ***skb_queue_tail [ 57.028068] xradio TXRX-WRN: ***skb_queue_tail [ 57.040336] xradio TXRX-WRN: ***skb_queue_tail [ 57.042775] xradio TXRX-WRN: received frame has no key status [ 57.042789] xradio TXRX-WRN: dropped received frame [ 57.198022] xradio TXRX-WRN: ***skb_queue_tail [ 57.198644] xradio TXRX-WRN: received frame has no key status [ 57.198669] xradio TXRX-WRN: dropped received frame [ 57.198740] xradio TXRX-WRN: received frame has no key status [ 57.198752] xradio TXRX-WRN: dropped received frame [ 57.199236] xradio TXRX-WRN: received frame has no key status [ 57.199249] xradio TXRX-WRN: dropped received frame [ 57.199662] xradio TXRX-WRN: received frame has no key status [ 57.199672] xradio TXRX-WRN: dropped received frame [ 57.273269] xradio TXRX-WRN: ***skb_queue_tail [ 57.398636] xradio TXRX-WRN: ***skb_queue_tail Can anybody explain what these errors actually mean? Is this indicative of an actual hardware error on the board? Or could it be caused by something else? I did update my base image recently (using the same `customize_image.sh`), or could it be something locally on my wifi that can cause these errors? ---- EDIT ---- After diving into the driver source (well, at least one of the versions), I found this piece of code that seems to trigger the message: void xradio_rx_cb(struct xradio_vif *priv, struct wsm_rx *arg, struct sk_buff **skb_p) { . . . . . . . if (unlikely(early_data)) { spin_lock_bh(&priv->ps_state_lock); /* Double-check status with lock held */ if (entry->status == XRADIO_LINK_SOFT) { skb_queue_tail(&entry->rx_queue, skb); dev_warn(priv->hw_priv->pdev, "***skb_queue_tail\n"); } else ieee80211_rx_irqsafe(priv->hw, skb); spin_unlock_bh(&priv->ps_state_lock); } else { ieee80211_rx_irqsafe(priv->hw, skb); } *skb_p = NULL; I am not very familiar with the linux networking drivers/stack, but from what I understand, a wifi frame comes in over a socket, causing the rx callback to be called, which does a bunch of stuff, ending with checking some status (on the wifi chip? or on the frame?) concludes that the status is XRADIO_LINK_SOFT, which I guess means it isn't able to do something, and queues the frame back on the receive socket buffer/queue (and warns about it)? So does anyone know what that status means? And if there is anything that could cause it? Cheers, Dolf.
hal8k Posted June 22, 2021 Posted June 22, 2021 Hi Dolf, See this link on github, in particular the paragraphs "read this" and "issues". When i was using the internal wifi, pings to the OPi from network resulted in dropouts and lags, but from OPi to network were better. https://github.com/fifteenhex/xradio/blob/master/README.md So as a workaround I have a USB wifi N dongle from Ali Express (very cheap) https://www.aliexpress.com/item/1005002626370066.html?spm=a2g0o.productlist.0.0.5eda3ec9E8E9W2&algo_pvid=c6007224-e8da-49fd-a509-c30ed26bc42f&algo_exp_id=c6007224-e8da-49fd-a509-c30ed26bc42f-11 This is recognised by the kernel in current Armbian buster and works better. Although it doesnt answer your question, these dongles are very good and you can use an external antenna of greater gain if you wish.
Recommended Posts