2016-12-22 12:34:36

by Ferran Quer i Guerrero

[permalink] [raw]
Subject: Question: Packet drop criterion

Hello everyone,

I would like to modify the retry threshold for dropping a packet using
mesh mode. I tried with iw

iw phy <phyname> set retry [short <limit>] [long <limit>]

with short and long limits equal to 10 first and later 5, but I couldn't
tell any effect. I'm checking by adding a printk in `status.c` and
manually shutting down (ifdown) the mesh-peered interface to cause
packet retries. It turns out that the tx report only appears when
`retry_count` is 28 (after many continued drops, it also appears at 23,
24, 25 or retries).=20

void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb=
)
{
/* ... */
if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
ieee80211_handle_filtered_frame(local, sta, skb);=

rcu_read_unlock();
return;
} else {
if (!acked)
sta->tx_retry_failed++;
sta->tx_retry_count +=3D retry_count;
/* Dirty debugging */
printk("Packet dropped. Retry count: %d",
retry_count);
}

rate_control_tx_status(local, sband, sta, skb);
if (ieee80211_vif_is_mesh(&sta->sdata->vif))
ieee80211s_update_metric(local, sta, skb);
/* ... */
}

I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
mesh point mode.

Did I get wrong the iw command?
Is it Minstrel who decides the retry trheshold?
Is it Atheros driver?
Does it have anything to do with mesh mode?

I'm trying to find the responsible at the source code, but haven't
succeeded yet, so I decided to write to yo.

Thank you very much
Ferran Quer


2016-12-22 19:53:19

by Oleksij Rempel

[permalink] [raw]
Subject: Re: Question: Packet drop criterion

Am 22.12.2016 um 13:34 schrieb Ferran Quer i Guerrero:
> Hello everyone,
>
> I would like to modify the retry threshold for dropping a packet using
> mesh mode. I tried with iw
>
> iw phy <phyname> set retry [short <limit>] [long <limit>]
>
> with short and long limits equal to 10 first and later 5, but I couldn't
> tell any effect. I'm checking by adding a printk in `status.c` and
> manually shutting down (ifdown) the mesh-peered interface to cause
> packet retries. It turns out that the tx report only appears when
> `retry_count` is 28 (after many continued drops, it also appears at 23,
> 24, 25 or retries).
>
> void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> /* ... */
> if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> ieee80211_handle_filtered_frame(local, sta, skb);
> rcu_read_unlock();
> return;
> } else {
> if (!acked)
> sta->tx_retry_failed++;
> sta->tx_retry_count += retry_count;
> /* Dirty debugging */
> printk("Packet dropped. Retry count: %d",
> retry_count);
> }
>
> rate_control_tx_status(local, sband, sta, skb);
> if (ieee80211_vif_is_mesh(&sta->sdata->vif))
> ieee80211s_update_metric(local, sta, skb);
> /* ... */
> }
>
> I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
> mesh point mode.

are you talking about usb dongles? If yes, then it is not ath9k


--
Regards,
Oleksij


Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-12-27 14:17:35

by Ferran Quer i Guerrero

[permalink] [raw]
Subject: Re: Question: Packet drop criterion

Hi,

I have browsed further the code and have some conclusions that it would
be nice to check with you


El 22/12/16 a les 13:34, Ferran Quer i Guerrero ha escrit:

> Did I get wrong the iw command?

Probably not, but minstrel is interferring. If I fixed the tx bitrates,
this would possibly set the retry limits.

> Is it Minstrel who decides the retry trheshold?

Yes, but...

> Is it Atheros driver?

Based on decisions of the Atheros (it sets the #rates to 4 and the
max_rate_retry to 10

> Does it have anything to do with mesh mode?

Not that I have noticed. However, I would like to ask for the meaning of
this params:

# iw dev wlan0 get mesh_param
mesh_retry_timeout = 100 milliseconds
[...]
mesh_max_retries = 3
[...]

What packets do they apply to?

Thank you in advance,
Ferran


El 22/12/16 a les 13:34, Ferran Quer i Guerrero ha escrit:
> Hello everyone,
>
> I would like to modify the retry threshold for dropping a packet using
> mesh mode. I tried with iw
>
> iw phy <phyname> set retry [short <limit>] [long <limit>]
>
> with short and long limits equal to 10 first and later 5, but I couldn't
> tell any effect. I'm checking by adding a printk in `status.c` and
> manually shutting down (ifdown) the mesh-peered interface to cause
> packet retries. It turns out that the tx report only appears when
> `retry_count` is 28 (after many continued drops, it also appears at 23,
> 24, 25 or retries).
>
> void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> /* ... */
> if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> ieee80211_handle_filtered_frame(local, sta, skb);
> rcu_read_unlock();
> return;
> } else {
> if (!acked)
> sta->tx_retry_failed++;
> sta->tx_retry_count += retry_count;
> /* Dirty debugging */
> printk("Packet dropped. Retry count: %d",
> retry_count);
> }
>
> rate_control_tx_status(local, sband, sta, skb);
> if (ieee80211_vif_is_mesh(&sta->sdata->vif))
> ieee80211s_update_metric(local, sta, skb);
> /* ... */
> }
>
> I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
> mesh point mode.
>
> Did I get wrong the iw command?
> Is it Minstrel who decides the retry trheshold?
> Is it Atheros driver?
> Does it have anything to do with mesh mode?
>
> I'm trying to find the responsible at the source code, but haven't
> succeeded yet, so I decided to write to yo.
>
> Thank you very much
> Ferran Quer
>
>