Jump to content

Understanding opi zero xradio error message


Dolf Andringa

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines