Lost packets after switching Wi-Fi AP

Hello,

I work on an extension of the mobility protocol for IPv6 (FMIPv6-RFC4068) and I've noticed the following problem:

When I switch my Mobile Node between 2 Wi-Fi Access Points, there is a period of time where all the packets I send are lost, although I got the netlink event SIOCGIWAP 'up' for the new AP. The device is supposed to be ready, but the packets are lost.

By 'lost', I mean: silently discarded by the kernel, no error returned to the user-space application sending the packet, packets never appear on the network monitored with wireshark.

Here is the setup:
------------------

1. The daemon decides to switch from one AP to the other for some reason (better link quality, ...) and set the new ESSID, etc.

2. The daemon waits for the SIOCGIWAP 'up' netlink event.

3. SIOCGIWAP received: the daemon sends a unique Mobility Header packet using a raw socket to its new router to signal it has successfully moved. sendmsg() returned 0, no error, but the packet never shows up.

- The interface has an IPv6 address configured for the new network (previously created).
- There is a route between the node and the router.
- I set the socket option IPV6_RECVERR to get all the errors, but none shows up.
- The "black hole" period lasts for about 500ms after the SIOCGIWAP event. Every packets sent during this period are lost.
- I tried to get the interface status before sending the packet (ioctl(SIOCSIFFLAGS)) but I got a perfect IFF_UP|IFF_RUNNING.

What I've found in the kernel:
------------------------------

- The packet is discarded in the packet scheduler in net/sched/sch_generic.c::noop_enqueue() which returns NET_XMIT_CN.

- The error doesn't go up to the application because net/ipv6/ip6_output.c::ip6_push_pending_frames() filters this type of error (using net_xmit_errno(err)).

- noop_enqueue() is used to enqueue the packet because the device has been deactivated by link_watch_run_queue() calling dev_deactivate(). The device is re-activated about 500ms later.

- According to net/sched/sch_api.c, NET_XMIT_CN means "probably this packet enqueued, but another one dropped". But it seems to me that this packet IS actually dropped in noop_enqueue() (kfree_skb()). Shouldn't the routine return NET_XMIT_DROP instead? Then the application should be able to get the error code when the device is deactivated and retry later?

My questions:
-------------

- Am I doing something obviously wrong? Is there another event I should expect before sending my packet? An event that signals more reliably that the link is up and running and associated with the new AP?

- Shouldn't we change the return code in noop_enqueue()?

Thanks a lot for your help,
Benjamin

B e n j a m i n   T h e r y  - BULL/DT/Open Software R&D

   http://www.bull.com

Which wireless card are you using? Which version of the kernel?

Jiri

Jiri Benc
SUSE Labs

Hi Jiri,

The kernel version is 2.6.16.20 (the latest kernel version officially supported by MIPv6). I'd like to use a 2.6.19 but unfortunately not all the IPv6 mobility patches are in.

I reproduced the problem with an Intel Pro Wireless 2200 (latest driver version: 1.2.0) and a pcmcia "D-Link Airplus G+ DWL-G650+" using the ndiswrapper version 1.25.

But I'm not sure the problem is wireless-specific.

And as I wrote in my first message I'm also surprised that when noop_enqueue() is used, the return code is NET_XMIT_CN, whereas the packet seems to be dropped.

Thanks for your help.

Benjamin

B e n j a m i n   T h e r y  - BULL/DT/Open Software R&D

   http://www.bull.com