Using wmediumd in kernel 3.10

Using wmediumd in kernel 3.10

[Dani Camps]

Dear all,

I would like to use wmediumd with linuxwireless backports 3.10.

The problem is that as indicated in this post: http://www.spinics.net/lists/linux-wireless/msg96575.html, wmediumd is not supported in this kernel. Quoting from the post:

"To use mac80211_hwsim for testing channel contexts it has to support them, and for that it has to support hw scan and hw-remain-on-channel.
Since it's pure software, the off-channel activities are really not off-channel but listening and sending on a second channel. Also, the multi-channel isn't really doing TDM, it's just on both channels at the same time. 
Note that this breaks wmediumd right now as it doesn't propagate the channel."


In particular, wmediumd crashes whenever the first packet between the two mac80211_hwsim radios is sent. Specifically the place in mac80211_hwsim.c where the error occurs is in this call inside the function hwsim_tx_info_frame_received_nl():

mac80211_hwsim_monitor_ack(txi->rate_driver_data[0], hdr->addr2);

In mac80211_hwsim_monitor_ack() a crash occurs whenever accessing a field of txi->rate_driver_data[0], which is of type struct ieee80211_channel.

So, I would like to ask for support in any of the following:

1- Guidance on how to fix wmediumd for kernel 3.10.
2- Advise on another tool with functionality equivalent to that of wmediumd, i.e. introducing delay and drop probability to packets exchanged between mac80211_hwsim radios, and that works with kernel 3.10.

Best Regards

Daniel

Re: Using wmediumd in kernel 3.10

[Johannes Berg]

> I would like to use wmediumd with linuxwireless backports 3.10.
> 
> The problem is that as indicated in this
> post: http://www.spinics.net/lists/linux-wireless/msg96575.html,
> wmediumd is not supported in this kernel. Quoting from the post:
> 
> "To use mac80211_hwsim for testing channel contexts it has to support
> them, and for that it has to support hw scan and hw-remain-on-channel.
> Since it's pure software, the off-channel activities are really not
> off-channel but listening and sending on a second channel. Also, the
> multi-channel isn't really doing TDM, it's just on both channels at
> the same time. 
> Note that this breaks wmediumd right now as it doesn't propagate the
> channel."

This should only affect hwsim if you load it with channels=2 or more,
are you doing that?

johannes

Re: Using wmediumd in kernel 3.10

[Dani Camps]

Hi,

I am only loading mac80211_hwsim with the parameter "radios=2". I am not specifying anything about "channels", which looking at the code should be 1.

Cheers

Daniel



El Jueves 5 de diciembre de 2013 17:11, Johannes Berg <johannes@sipsolutions.net> escribió:


> I would like to use wmediumd with linuxwireless backports 3.10.
> 
> The problem is that as indicated in this
> post: http://www.spinics.net/lists/linux-wireless/msg96575.html,
> wmediumd is not supported in this kernel. Quoting from the post:
> 
> "To use mac80211_hwsim for testing channel contexts it has to support
> them, and for that it has to support hw scan and hw-remain-on-channel.
> Since it's pure software, the off-channel activities are really not
> off-channel but listening and sending on a second channel. Also, the
> multi-channel isn't really doing TDM, it's just on both channels at
> the same time. 
> Note that this breaks wmediumd right now as it doesn't propagate the
> channel."

This should only affect hwsim if you load it with channels=2 or more,
are you doing that?

johannes

Re: Using wmediumd in kernel 3.10

[Johannes Berg]

On Thu, 2013-12-05 at 16:14 +0000, Dani Camps wrote:

> I am only loading mac80211_hwsim with the parameter "radios=2". I am
> not specifying anything about "channels", which looking at the code
> should be 1.

Ok. What's the easiest way to reproduce this? Do I need
hostapd/wpa_supplicant and wmediumd, or something else?

johannes

Re: Using wmediumd in kernel 3.10

[Dani Camps]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]



Hi Johannes,

I attach the script that I am using to load mac80211_hwsim. What you need to do is:

1) Execute the script to load two mesh interfaces mesh0 and mesh1.
2) Load wmediumd (the version in GitHub: https://github.com/cozybit/wmediumd), and use as config file the file that I am attaching.
3) Ping from mesh0 to mesh1: ping -I mesh0 192.168.77.11

You will see in syslog a kernel crash, followed by mac80211_hwsim deregistering the netlink socket. Then the ping proceeds normally because wmediumd is dettached.

Thanks for your help!

Cheers

Daniel






El Jueves 5 de diciembre de 2013 17:25, Johannes Berg <johannes@sipsolutions.net> escribió:
On Thu, 2013-12-05 at 16:14 +0000, Dani Camps wrote:

> I am only loading mac80211_hwsim with the parameter "radios=2". I am
> not specifying anything about "channels", which looking at the code
> should be 1.

Ok. What's the easiest way to reproduce this? Do I need
hostapd/wpa_supplicant and wmediumd, or something else?


johannes

[-- Attachment #2: script.sh.txt --]
[-- Type: text/plain, Size: 1872 bytes --]


############### #
# Configuration #
#################
NUM_RADIOS=2

sudo modprobe mac80211
sudo modprobe mac80211_hwsim channels=1 radios=$NUM_RADIOS

echo "-> Modules loaded"
sleep 2

# Prepare ip rules for send-to-self
ip rule flush
ip rule del pref   0 lookup local
ip rule add pref 5000 lookup local
ip rule add pref 32766 lookup main
ip rule add pref 32767 lookup default

#Configure the mesh interfaces
PHYS=`find /sys/kernel/debug/ieee80211 -name hwsim | cut -d/ -f 6 | sort`
i=0
for phy in ${PHYS}; do

        #Configure the mesh interface
        iw phy ${phy} interface add mesh$i type mp mesh_id bazooka
        ip address add 192.168.77.1$i/24 dev mesh$i
        ip link set mesh$i up

        i=$(($i+1))

done

#Configure the IP rules required to implement send-to-self
for i in $(seq 0 $(($NUM_RADIOS - 1))); do

        #rule for incoming packets on each interface --> go to local table
        ip rule add pref $(($i+10)) iif mesh$i lookup local

        #create a rule for each pair i->j to point to table i->j where the default device is mesh$j. This ensures t$
        for j in $(seq 0 $(($NUM_RADIOS - 1))); do
                if [ "$j" -ne "$i" ]; then
                        #table_idx=$(($j+($i+1)*100))
                        table_idx=$(($j+100))
                        #table_prio=$table_idx
                        table_prio=$(($j+($i+1)*100))
                        ip rule add pref $table_prio from 192.168.77.1$j to 192.168.77.1$i lookup $table_idx
                        ip route flush table $table_idx
                        ip route add default dev mesh$j table $table_idx
                fi
        done
        echo 1 >/proc/sys/net/ipv4/conf/mesh$i/accept_local

done

# Bringing up hwsim0, otherwise the packets do not flow through mac80211_hwsim
ifconfig hwsim0 up


[-- Attachment #3: wmediumd_config_file.txt --]
[-- Type: text/plain, Size: 785 bytes --]


ifaces :
{
        count = 2;
        ids = ["42:00:00:00:00:00", "42:00:00:00:01:00" ];
};
prob :
{
        rates = 12;
        matrix_list = (
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ],
                [ -1.000, 0.500, 0.500, -1.000 ]
        );
};

Re: Using wmediumd in kernel 3.10

[Johannes Berg]

On Thu, 2013-12-05 at 16:42 +0000, Dani Camps wrote:
> ping -I mesh0 192.168.77.11

Works fine for me. Maybe you should try a later backports version, e.g.
3.12? I don't remember fixing anything, but I don't see any issues
either.

johannes

Re: Using wmediumd in kernel 3.10

[Dani Camps]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

Hi,

I tried with kernel 3.12 but I still get the same error. Just to clarify, if wmediumd would work properly you should see in the ping approximately half of the packets being dropped, because the configuration file has 0.5 drop probability for all rates. If you see that the ping proceeds normally is because the error happened and wmediumd de-registered.

I attach the error I see in syslog.

Best Regards


Daniel





El Jueves 5 de diciembre de 2013 18:40, Johannes Berg <johannes@sipsolutions.net> escribió:
On Thu, 2013-12-05 at 16:42 +0000, Dani Camps wrote:
> ping -I mesh0 192.168.77.11

Works fine for me. Maybe you should try a later backports version, e.g.
3.12? I don't remember fixing anything, but I don't see any issues
either.


johannes

[-- Attachment #2: var_log_syslog.txt --]
[-- Type: text/plain, Size: 5229 bytes --]

Dec  5 13:28:21 mininet-vm kernel: [  261.300120] mac80211_hwsim: received a REGISTER, switching to wmediumd mode with pid 1561
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] BUG: unable to handle kernel NULL pointer dereference at 00000004
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] IP: [<f81ddf99>] mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim]
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] *pde = 7ebc1067
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Oops: 0000 [#1] SMP
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Modules linked in: arc4 mac80211_hwsim mac80211 cfg80211 compat vesafb ppdev joydev snd_intel8x0 snd_ac97_codec ac97_bus binfmt_misc snd_pcm psmouse serio_raw parport_pc snd_timer snd soundcore snd_page_alloc i2c_piix4 lp parport usbhid hid ahci libahci e1000
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Pid: 1561, comm: wmediumd Tainted: G        W   3.0.0-12-generic #20-Ubuntu innotek GmbH VirtualBox/VirtualBox
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP: 0060:[<f81ddf99>] EFLAGS: 00010287 CPU: 0
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP is at mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim]
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EAX: f28e3640 EBX: f2dc3900 ECX: f2dc3900 EDX: 00000016
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] ESI: f28e3c58 EDI: 00000004 EBP: f2d0bc34 ESP: f2d0bc28
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Process wmediumd (pid: 1561, ti=f2d0a000 task=f2986600 task.ti=f2d0a000)
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Stack:
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  f2dc3c00 f2dc3c2c f2dc3c21 f2d0bc60 f81de54c 00000004 f2d0bc8c f2dc3c00
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  f29295a0 f2dc3c00 00000000 f81e3260 f81e31c0 00000000 f2d0bcbc c145d4f4
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  00000038 f81e32a0 00000008 f81e32a0 00000004 c1943e40 f28e3410 f2dc3600
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Call Trace:
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<f81de54c>] hwsim_tx_info_frame_received_nl+0x1dc/0x1e0 [mac80211_hwsim]
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d4f4>] genl_rcv_msg+0x1c4/0x240
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d330>] ? genl_rcv+0x30/0x30
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145ce9e>] netlink_rcv_skb+0x8e/0xb0
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d31c>] genl_rcv+0x1c/0x30
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145c8a9>] netlink_unicast+0x239/0x290
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145cb5b>] netlink_sendmsg+0x25b/0x2e0
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1425d7c>] sock_sendmsg+0xec/0x110
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c10320d2>] ? check_preempt_curr+0x72/0x90
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c128836f>] ? __copy_from_user_ll+0x1f/0x40
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1288502>] ? _copy_from_user+0x42/0x60
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1430d44>] ? verify_iovec+0x44/0xb0
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1427590>] __sys_sendmsg+0x270/0x280
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1041600>] ? default_wake_function+0x10/0x20
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102e277>] ? __wake_up_common+0x47/0x70
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102fa85>] ? __wake_up+0x45/0x60
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1311049>] ? tty_wakeup+0x39/0x70
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c131ab29>] ? pty_write+0x69/0x70
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1026018>] ? default_spin_lock_flags+0x8/0x10
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c152c6fd>] ? _raw_spin_lock_irqsave+0x2d/0x40
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102fa85>] ? __wake_up+0x45/0x60
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c115bc88>] ? fsnotify+0x198/0x250
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c142839b>] sys_sendmsg+0x3b/0x60
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1428a23>] sys_socketcall+0x263/0x2c0
Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c152c8e4>] syscall_call+0x7/0xb
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Code: 84 bd 00 00 00 ba 16 00 00 00 e8 23 f2 24 c9 c6 00 00 c6 40 01 00 66 c7 40 02 16 00 c7 40 04 0a 00 00 00 c6 40 10 00 c6 40 11 00 <0f> b7 17 8d 7b 18 66 c7 40 14 80 00 66 89 50 12 ba 0a 00 00 00
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP: [<f81ddf99>] mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim] SS:ESP 0068:f2d0bc28
Dec  5 13:28:44 mininet-vm kernel: [  284.292247] CR2: 0000000000000004
Dec  5 13:28:44 mininet-vm kernel: [  284.493005] ---[ end trace a7919e7f17c0a728 ]---
Dec  5 13:28:44 mininet-vm kernel: [  284.496382] mac80211_hwsim: wmediumd released netlink socket, switching to perfect channel medium

Re: Using wmediumd in kernel 3.10

[Johannes Berg]

On Thu, 2013-12-05 at 21:37 +0000, Dani Camps wrote:
> Hi,
> 
> I tried with kernel 3.12 but I still get the same error. Just to
> clarify, if wmediumd would work properly you should see in the ping
> approximately half of the packets being dropped, because the
> configuration file has 0.5 drop probability for all rates. If you see
> that the ping proceeds normally is because the error happened and
> wmediumd de-registered.

Not sure I saw packet loss, but I made wmediumd print out statistics and
it was definitely seeing packets ...

johannes

Re: Using wmediumd in kernel 3.10

[Javier Lopez]

Dani Camps <danicamps81@...> writes:

> 
> Hi,
> 
> I tried with kernel 3.12 but I still get the same error. Just to clarify,
if wmediumd would work properly you
> should see in the ping approximately half of the packets being dropped,
because the configuration file
> has 0.5 drop probability for all rates. If you see that the ping proceeds
normally is because the error
> happened and wmediumd de-registered.
> 
> I attach the error I see in syslog.
> 
> Best Regards
> 
> Daniel
> 

Hi Dani, Johannes,

I was able to reproduce your issue with latest version of wireless-testing
and wmediumd.

The problem is that txi->rate_driver_data[0] is not set on
hwsim_tx_info_frame_received_nl(). Later mac80211_hwsim_monitor_ack()
crashes while accessing that information.

I'm preparing a patch to fix this.

Jlo 
 
> El Jueves 5 de diciembre de 2013 18:40, Johannes Berg <johannes <at>
sipsolutions.net> escribió:
> On Thu, 2013-12-05 at 16:42 +0000, Dani Camps wrote:
> > ping -I mesh0 192.168.77.11
> 
> Works fine for me. Maybe you should try a later backports version, e.g.
> 3.12? I don't remember fixing anything, but I don't see any issues
> either.
> 
> johannes
> 
> Dec  5 13:28:21 mininet-vm kernel: [  261.300120] mac80211_hwsim: received
a REGISTER, switching to
> wmediumd mode with pid 1561
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] BUG: unable to handle
kernel NULL pointer dereference at 00000004
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] IP: [<f81ddf99>]
> mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim]
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] *pde = 7ebc1067
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Oops: 0000 [#1] SMP
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Modules linked in: arc4
mac80211_hwsim mac80211
> cfg80211 compat vesafb ppdev joydev snd_intel8x0 snd_ac97_codec ac97_bus
binfmt_misc snd_pcm
> psmouse serio_raw parport_pc snd_timer snd soundcore snd_page_alloc
i2c_piix4 lp parport usbhid hid
> ahci libahci e1000
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Pid: 1561, comm:
wmediumd Tainted: G        W   3.0.0-12-generic
> #20-Ubuntu innotek GmbH VirtualBox/VirtualBox
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP: 0060:[<f81ddf99>]
EFLAGS: 00010287 CPU: 0
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP is at
> mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim]
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EAX: f28e3640 EBX:
f2dc3900 ECX: f2dc3900 EDX: 00000016
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] ESI: f28e3c58 EDI:
00000004 EBP: f2d0bc34 ESP: f2d0bc28
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Process wmediumd (pid:
1561, ti=f2d0a000 task=f2986600 task.ti=f2d0a000)
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Stack:
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  f2dc3c00 f2dc3c2c
f2dc3c21 f2d0bc60 f81de54c 00000004
> f2d0bc8c f2dc3c00
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  f29295a0 f2dc3c00
00000000 f81e3260 f81e31c0 00000000
> f2d0bcbc c145d4f4
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  00000038 f81e32a0
00000008 f81e32a0 00000004 c1943e40
> f28e3410 f2dc3600
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Call Trace:
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<f81de54c>]
> hwsim_tx_info_frame_received_nl+0x1dc/0x1e0 [mac80211_hwsim]
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d4f4>]
genl_rcv_msg+0x1c4/0x240
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d330>] ?
genl_rcv+0x30/0x30
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145ce9e>]
netlink_rcv_skb+0x8e/0xb0
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145d31c>]
genl_rcv+0x1c/0x30
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145c8a9>]
netlink_unicast+0x239/0x290
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c145cb5b>]
netlink_sendmsg+0x25b/0x2e0
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1425d7c>]
sock_sendmsg+0xec/0x110
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c10320d2>] ?
check_preempt_curr+0x72/0x90
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c128836f>] ?
__copy_from_user_ll+0x1f/0x40
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1288502>] ?
_copy_from_user+0x42/0x60
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1430d44>] ?
verify_iovec+0x44/0xb0
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1427590>]
__sys_sendmsg+0x270/0x280
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1041600>] ?
default_wake_function+0x10/0x20
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102e277>] ?
__wake_up_common+0x47/0x70
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102fa85>] ?
__wake_up+0x45/0x60
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1311049>] ?
tty_wakeup+0x39/0x70
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c131ab29>] ?
pty_write+0x69/0x70
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1026018>] ?
default_spin_lock_flags+0x8/0x10
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c152c6fd>] ?
_raw_spin_lock_irqsave+0x2d/0x40
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c102fa85>] ?
__wake_up+0x45/0x60
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c115bc88>] ?
fsnotify+0x198/0x250
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c142839b>]
sys_sendmsg+0x3b/0x60
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c1428a23>]
sys_socketcall+0x263/0x2c0
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247]  [<c152c8e4>]
syscall_call+0x7/0xb
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] Code: 84 bd 00 00 00 ba
16 00 00 00 e8 23 f2 24 c9 c6 00 00 c6 40 01 00
> 66 c7 40 02 16 00 c7 40 04 0a 00 00 00 c6 40 10 00 c6 40 11 00 <0f> b7 17
8d 7b 18 66 c7 40 14 80 00 66 89 50 12 ba 0a 00 00 00
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] EIP: [<f81ddf99>]
> mac80211_hwsim_monitor_ack.isra.19.part.20+0x49/0x120 [mac80211_hwsim]
SS:ESP 0068:f2d0bc28
> Dec  5 13:28:44 mininet-vm kernel: [  284.292247] CR2: 0000000000000004
> Dec  5 13:28:44 mininet-vm kernel: [  284.493005] ---[ end trace
a7919e7f17c0a728 ]---
> Dec  5 13:28:44 mininet-vm kernel: [  284.496382] mac80211_hwsim: wmediumd
released netlink socket,
> switching to perfect channel medium
> 

Re: Using wmediumd in kernel 3.10

[Dani Camps]

Hi,

You are right, since we have retransmissions at layer 2 with a 0.5 drop probability the pings still go through, but with high delay variations.

Anyway, I tested the patch posted by Javier Lopez, and it is now working for me.

Cheers

Daniel



El Jueves 5 de diciembre de 2013 23:07, Johannes Berg <johannes@sipsolutions.net> escribió:
On Thu, 2013-12-05 at 21:37 +0000, Dani Camps wrote:
> Hi,
> 
> I tried with kernel 3.12 but I still get the same error. Just to
> clarify, if wmediumd would work properly you should see in the ping
> approximately half of the packets being dropped, because the
> configuration file has 0.5 drop probability for all rates. If you see
> that the ping proceeds normally is because the error happened and
> wmediumd de-registered.

Not sure I saw packet loss, but I made wmediumd print out statistics and
it was definitely seeing packets ...


johannes