You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry to put the issue here, but I can't open one at https://github.com/bcopeland/wmediumd fork. Using kernel 4.9.8-1 (Arch Linux) built with mac802_hwsim, I encounter the following issues. I'm not very familiar with wmediumd, so I don't know exactly what the problem is, but, here are the "symptoms":
Grepping 'dmesg', the wlan interfaces, created by loading mac80211_hwsim, use rates configured by minstrel_ht. Here's a rc_stats sample from /sys/kernel/debug/ieee80211/phy7/netdev:wlan0/stations/02:00:00:00:01:00 (where phy7 is of course the id associated with wlan0):
As you can see, the rates and indexes used are those from the first 2 columns.
Now, when inspecting the function queue_frame() from wmediumd.c (bcopeland fork), it seems to me that the array index_to_rate[], that gets consulted each time an index must be translated to a rate, is out of place - by logging the index value, I get for example values such as 9 etc. which are higher than the dimension of the array. So, my question is, is the following modification the 'right' one to make?
Since I'm not familiar with wmediumd, I have no clue about what causes this new set of rates to kick in, instead of the 'old' one. When does this happen - all the time? or does it depend on minstrel_ht (vs minstrel)? Even in this case, I'm not entirely sure the index is not 'offset' by 1 - if I log the rate index for an acknowledged frame (rate_idx in queue_frame(), after the loop), it seems to be higher (by 1) than the one selected as ideal (A P) in rc_stats (e.g. I get index 10 as the most used, but rc_stats shows that index 9 was the ideal one).
Thanks
The text was updated successfully, but these errors were encountered:
No idea why you cannot open an issue there, but in any case:
Yes, your modification looks correct, *if* you are operating a 2.4 GHz
network. The rateset that wmediumd uses by default assumes a 5 GHz
802.11a rateset, the reason being that at the time I originally wrote
it, I didn't have any good way of estimating anything . The other reason
is that I'm not aware of an easy way to tell from userspace what the
rateset actually is.
So another option is just to pick 5 GHz frequencies in your test
environment.
On Wed, Feb 15, 2017 at 04:21:53AM -0800, VanLaser wrote:
@bcopeland
Hello,
Sorry to put the issue *here*, but I can't open one at https://github.com/bcopeland/wmediumd fork. Using kernel 4.9.8-1 (Arch Linux) built with mac802_hwsim, I encounter the following issues. I'm not very familiar with **wmediumd**, so I don't know exactly what the problem is, but, here are the "symptoms":
Grepping 'dmesg', the wlan interfaces, created by loading mac80211_hwsim, use rates configured by **minstrel_ht**. Here's a **rc_stats** sample from _/sys/kernel/debug/ieee80211/phy7/netdev:wlan0/stations/02:00:00:00:01:00_ (where **phy7** is of course the id associated with **wlan0**):
As you can see, the rates and indexes used are those from the 2 columns.
Now, when inspecting the function **queue_frame()** from _wmediumd.c_ (**bcopeland** fork), it seems to me that the array **index_to_rate[]**, that gets consulted each time an index must be translated to a rate, is out of place - by logging the index value, I get for example values such as 9 etc. which are higher than the dimension of the array. So, my question is, is the following modification the 'right' one to make?
```
static int index_to_rate[] = {
10, 20, 55, 110, 60, 90, 120, 180, 240, 360, 480, 540
};
```
@bcopeland
Hello,
Sorry to put the issue here, but I can't open one at https://github.com/bcopeland/wmediumd fork. Using kernel 4.9.8-1 (Arch Linux) built with mac802_hwsim, I encounter the following issues. I'm not very familiar with wmediumd, so I don't know exactly what the problem is, but, here are the "symptoms":
Grepping 'dmesg', the wlan interfaces, created by loading mac80211_hwsim, use rates configured by minstrel_ht. Here's a rc_stats sample from /sys/kernel/debug/ieee80211/phy7/netdev:wlan0/stations/02:00:00:00:01:00 (where phy7 is of course the id associated with wlan0):
As you can see, the rates and indexes used are those from the first 2 columns.
Now, when inspecting the function queue_frame() from wmediumd.c (bcopeland fork), it seems to me that the array index_to_rate[], that gets consulted each time an index must be translated to a rate, is out of place - by logging the index value, I get for example values such as 9 etc. which are higher than the dimension of the array. So, my question is, is the following modification the 'right' one to make?
Since I'm not familiar with wmediumd, I have no clue about what causes this new set of rates to kick in, instead of the 'old' one. When does this happen - all the time? or does it depend on minstrel_ht (vs minstrel)? Even in this case, I'm not entirely sure the index is not 'offset' by 1 - if I log the rate index for an acknowledged frame (rate_idx in queue_frame(), after the loop), it seems to be higher (by 1) than the one selected as ideal (A P) in rc_stats (e.g. I get index 10 as the most used, but rc_stats shows that index 9 was the ideal one).
Thanks
The text was updated successfully, but these errors were encountered: