Ticket #168 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

Madwifi incorrectly handles multicast packets

Reported by: Matt Brown <matt@crc.net.nz> Assigned to:
Priority: minor Milestone: version 1.0.0 - first stable release
Component: madwifi: driver Version: trunk
Keywords: Cc: matt@crc.net.nz
Patch is attached: 0 Pending:

Description

Madwifi seems to have problems handling multicast packets correctly, this causes many problems for protocols like OSPF that use multicast for hello and link status packets.

We have observed two problems while running point-to-point links in Managed mode:

  1. Multicast packets are randomly dropped (mainly in AP->client direction)
  2. the AP receives duplicate copies of packets sent from a client

Problem 2 does not seem to have adverse effects, problem 1 results in protocols such as OSPF "flapping" on the link.

I have placed two TCP dumps showing this behaviour at:

MPH is the client at 10.1.236.1 http://www.crc.net.nz/~mglb1/madwifi/mph-tcpdump

MFR is the AP at 10.1.236.254 http://www.crc.net.nz/~mglb1/madwifi/mfr-tcpdump

Both hosts have several other OSPF speaking interfaces that do not exhibit this behaviour. We have also observed the duplicate multicast packets received at AP problem on links where the madwifi driver is used for the AP and another card (Orinoco (Hermes) orinoco_cs driver) is used as the client. There also seems to be some packet loss in this situation, but much much less frequently than in a scenario with 2 madwifi cards.

Hardware:

  • Soekris Biscuit PCs
  • Wistron CM9 Cards

Software Versions on MPH and MFR:

  • Linux 2.6.13.1 
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
wlan: 0.8.6.0 (EXPERIMENTAL)
ath_rate_sample: 1.2
ath_pci: 0.9.6.0 (EXPERIMENTAL)
Build date: Sep 15 2005
Debugging version (IEEE80211)
ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: H/W encryption support: WEP AES AES_CCM TKIP
ath0: mac 5.9 phy 4.3 radio 3.6
ath0: Use hw queue 1 for WME_AC_BE traffic
ath0: Use hw queue 0 for WME_AC_BK traffic
ath0: Use hw queue 2 for WME_AC_VI traffic
ath0: Use hw queue 3 for WME_AC_VO traffic
ath0: Use hw queue 8 for CAB traffic
ath0: Use hw queue 9 for beacons
Debugging version (ATH)
ath0: Atheros 5212: mem=0xa0000000, irq=10

I have not tried to reproduce the problem with madwifi-ng yet.

Attachments

mph-tcpdump.txt (3.5 kB) - added by mrenzmann on 11/23/05 08:23:58.
Local copy
mfr-tcpdump.txt (7.1 kB) - added by mrenzmann on 11/23/05 08:24:21.
Local copy

Change History

11/23/05 08:23:58 changed by mrenzmann

  • attachment mph-tcpdump.txt added.

Local copy

11/23/05 08:24:21 changed by mrenzmann

  • attachment mfr-tcpdump.txt added.

Local copy

11/23/05 08:26:54 changed by mrenzmann

Probably the same issue is the reason why some people can't seem to get DHCP leases on a MadWifi link.

I'd like to ask anyone to add experiences about this issue with madwifi-ng. It would be great if some of you could spend a little time on experimenting with such an setup, using madwifi-ng.

11/29/05 19:04:16 changed by mrenzmann

  • milestone set to version 0.9.0 - move to new codebase.

12/07/05 01:34:03 changed by Jamar

Well, it seems to be the same with madwifi-ng. We have setup with two AR5006X cards, and we have also experienced the same problems described here. In AP->Client direction, after OSPFD start, the packets are correctly transmitted for about 15-30 seconds, then they are dropped for about 10 minutes, then maybe transmitted again for a short time and so on. I haven't checked, if there's duplicates on the other direction yet, but this causes OSPFD to be messed up. I'll try to do some more monitoring, if you want.

12/07/05 02:01:26 changed by Matt Brown

  • version changed from madwifi-old to trunk.

We can confirm that the duplicate packets observed at the AP end occur with -ng.

01/01/06 13:29:48 changed by Matt Brown

Upon further investigation it appears the duplicate packets (point 2 of the bug report) may be a red herring.

Examination of the 802.11 headers for each packet indicates that the first is ToDS, the second is FromDS, ie, the AP is doing it's job and rebroadcasting the frame to the other clients. tcpdump seems to pick this up however a quick check of the driver code indicates that the FromDS packet never hits the kernel receive path.

If tcpdump correctly showed the direction each packet was travelling in this would be much clearer at a glance!

02/16/06 12:12:06 changed by kiru

  • priority changed from major to critical.
  • patch_attached changed.

I have the same problem with madwifi-ng-r1451-20060212.

03/03/06 18:29:38 changed by jbicket

  • milestone changed from version 0.9.0 - move to new codebase to version 1.0.0 - first stable release.

03/09/06 08:50:32 changed by anonymous

I can confirm problems with quagga (i tried version 98.3 and 99.2), routes sometimes missing. And I can confirm problem with multicast (VLC multicast), which causes enormous responses (from 1ms to >1000). It would be perfect to see it solved in version 0.9.0

03/09/06 09:17:13 changed by Matt Brown

  • priority changed from critical to minor.

I've been putting a lot of time into this bug over the last few days and I'm no longer convinced that it is a bug at all.

I've recently cleaned up the airspace around this link and it became clearer that the link was consistently dropping every second packet. Occasionally more were lost.

I have upgraded to the latest madwifi snapshot and past r1430 in particular. I think this bug was a major component of the loss I was seeing. Since upgrading multicast loss is MUCH more sporadic. In particular running the latest release, with diversity turned off and txantenna and rxantenna forced to the primary antenna sees absolutely no loss in one direction and only minimal loss in the other direction.

I think the remaining loss can be explained simply through interference and multicast packets being more vulnerable to loss as they are not acknowledged or retransmitted.

I'm also testing in Pseudo-IBSS mode now as it greatly simplifies the number of things to keep track of.

Jamar and Kiru: Can you please confirm which version of the driver you are using? If it is less than r1430 can you please upgrade and see if that solves the problem.

If loss exists after upgrading past r1430 can you please provide details on the environment the link is running in and the likelihood of the multicast loss being caused by interference.

I think this bug should closed shortly unless new evidence is presented to verify that it still exists. I can no longer reproduce it.

03/09/06 19:47:00 changed by anonymous

With XI-626 and latest hostap driver quagga (ospfd) and multicast working perfect.

04/27/06 19:03:41 changed by msmith@cbnco.com

I've been using the following cards and versions:

  • madwifi-old 2005-11-21 with NL-3054MP (mac 5.9 phy 4.3 radio 4.6)
  • madwifi-ng r1472 with NMP-8602 (mac 10.4 phy 6.1 radio 6.3)
  • madwifi-ng r1472 with EMP-8602 (mac 10.4 phy 6.1 radio 6.3)

I'm seeing dropped multicast/broadcast packets from AP to client with madwifi-ng r1472 and NMP-8602. Exactly every second multicast or broadcast packet is lost - doesn't matter if I'm transmitting every 1000ms or every 250ms. Although if I crank the rate up any higher, it refuses to transmit any broadcast for a few minutes.

The EMP-8602 doesn't have this problem. I'm not sure whether the NMP-8602 and EMP-8602 are identical; I bought them from Netgate at different times and they are listed as "NMP/EMP-8602" on their site. The EMP-8602s were ordered later. More importantly the working EMP-8602s are sitting on my desk and the NMP-8602s are on a 7km wireless link with a lot of interference. I might ship down an EMP-8602 to swap in and see if it has the same problem in that environment, but it'll be a few weeks. For now I worked around the OSPF problems with some NAT tricks to turn multicast into unicast.

My madwifi APs - all cards, all versions - are receiving every multicast and broadcast packet in duplicate, but as Matt said this may not be a real problem.

04/27/06 20:01:43 changed by anonymous

Haha oops. Setting txantenna to 1 fixed the 50% dropped multicast packets. (See #326, and log message for r1430.)

Why do multicast packets alternate antennas when other transmitted packets just follow the default antenna? This might be bad default behaviour for outdoor links, but maybe it works better indoors?

05/10/06 14:54:19 changed by Jers

I have carried out an AD-HOC network. All hosts run debian linux 2.6.9 and ospf/zebra routing process. Only a link of my network uses the madwifi-ng r1485. Sometimes this link has a problem. Wifi devices does not receive broadcast packets and, as a consequence, the routing does not work correctely and this link is left out of the possible paths. This problem can remain for some days and then, without any reason, it begins working again.

07/01/06 06:02:10 changed by Matt Brown

I don't think this ticket is relevant anymore. r1430 fixed the dominant issue, the other problems were red herrings.

Since March I've not been able to reproduce any of these problems in a variety of settings (outdoors, indoors, long links, short links, Managed mode, Ad-Hoc mode).

Multicast packets are still more vulnerable as they are not retransmitted, but that's 802.11 nothing the driver can do about that.

Please close this ticket.

07/01/06 15:16:16 changed by kelmo

  • status changed from new to closed.
  • resolution set to fixed.

Thanks for the feedback. Closing

Add/Change #168 (Madwifi incorrectly handles multicast packets)