Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #2213 (new defect)

Opened 13 years ago

Last modified 13 years ago

AP(master mode)<---> Station(managed mode) packet getting dropped until broadcast comes from the destination PC

Reported by: dinomycle@yahoo.com Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: v0.9.4
Keywords: Cc: dinomycle@yahoo.com
Patch is attached: 0 Pending: 0

Description

hi all,

i am facing a problem in madwifi-0.9.4, when i connect using two AP one in AP(master mode)and another in sation(managed mode) and connecting one pc's to ap through a hub/switch and station. i am using IXP board with atheros miniPCI cards. the connection as below

PC1===Switch/Hub====AP(master mode)<-----> Station(managed mode)======PC2

i am pinging from PC1 to PC2 and PC1 to station(PC1 and PC2 are windows PC) ping goes fine. without stopping the ping i reboot the AP(master mode) when it comes up, station got associated with the AP ping is not going, after debugging , found that, if you do a "arp -d" at the PC1 ping goes

so after the ap reboots it will receive only the unicast packet from the PC1 and that is not been forwarded to wireless interface, it is getting dropped in the madwifi driver. Please help me to solve this problem.

Thanks and Regards Dino

Attachments

ap-script (0.8 kB) - added by dinomycle@yahoo.com on 12/20/08 06:38:28.
ap-script
sta-script (2.2 kB) - added by dinomycle@yahoo.com on 12/20/08 06:39:14.
sta-script

Change History

12/20/08 06:38:28 changed by dinomycle@yahoo.com

  • attachment ap-script added.

ap-script

12/20/08 06:39:14 changed by dinomycle@yahoo.com

  • attachment sta-script added.

sta-script

01/02/09 17:53:03 changed by anonymous

hi all,

i also noticed this problem, any patch to solve this ???

02/13/09 11:04:02 changed by dinomycle@yahoo.com

Hi All,

any update on this

Thanks Dino

04/16/09 15:45:50 changed by Ronald.intVelt@tno.nl

What you're seeing is not a bug: MadWifi is performing as can be expected. First off, you need to realise that as far as bridging is concerned, MadWifi already offers more functionality than the WLAN standard specifies. Per IEEE 802.11-2007, clause 5.2.5 and IEEE 802.1D-2004, clause 6.5.4, bridging is only defined / allowed at the AP (to be precise: AP with co-located portal). MadWifi gives you the possibility to configure bridging at the STA as well (and even bridging on nodes in ad hoc mode, if you apply my patch from ticket #1131 :-) Bridging is enabled by setting iwpriv ath<n> wds 1 at both the AP and STA. What this command really does is to allow the use of 4-address frame headers. Such frames have a Receiver Address (RA), Transmitter Address (TA), Destination Address (DA) and Source Address (SA). In your setup, these correspond to the STA, AP, PC2 and PC1, respectively, for the ICMP Echo Requests and to the AP, STA, PC1 and PC2, respectively, for the ICMP Echo Replies in the opposite direction. (Note that RA must be the MAC address of the receiving wireless interface, otherwise no Ack frame will be returned).

To be able to compose 4-address frame headers correctly, the AP needs to know which wired nodes are behind which STA. It learns this information by snooping the SA and TA fields from frames that are sent by PC2 to PC1 (i.e. frames that travel in the opposite direction). In detail: The relationship between STA and nodes attached to their wired interfaces is maintained in the AP's ieee80211_node_table by means of a hash table of ieee80211_wds_addr structures. Each ieee80211_wds_addr contains a pointer to the ieee80211_node (STA) it is currently associated with. (See file ieee80211_node.h for the definitions of the ieee80211_node_table, ieee80211_node and ieee80211_wds_addr structures). Every time the AP receives a 4-address frame, it checks whether it already has an ieee80211_wds_addr for the SA in its node table. If this is not the case, an ieee80211_wds_addr entry is added and its node pointer field is set to point to the ieee80211_node entry for the TA. (The code for this can be found in file ieee80211_input.c, function ieee80211_input(), lines 519-551, Subversion madwifi-0.9.4 branch. The ieee80211_find_wds_node(), ieee80211_remove_wds_addr() and ieee80211_add_wds_addr() functions are defined in file ieee80211_node.c). Stale ieee80211_wds_addr entries are deleted after they time out. The associations between STA and attached wired nodes thus established are used by the AP when it needs to forward frames originated by PC1. When the AP is trying to determine the RA of frames to be sent over the air, it first looks for the DA among the STA entries in the node table. If it does not find a matching MAC address there, it subsequently searches the ieee80211_wds_addr entries. (Function ieee80211_find_txnode() in file ieee80211_node.c). In case a matching entry is found, a reference to the ieee80211_node that it points to is returned. The MAC address of the latter is then used as the RA.

Obviously, there is a potential "chicken-and-egg" or bootstrap problem with the procedure described above: when PC1 initiates communication with PC2 (ping in your case), no frames have been flowing from PC2 to PC1 yet. So how can the AP determine the Receiver Address of the STA to which PC2 is attached? This is where ARP comes into the picture. The first frame that PC1 will generate contains an ARP request. The DA of this frame is the broadcast address (all ones) and hence the AP bridges the frame to all STA, using normal 3-address format. In turn, the receiving STA will bridge the frame to their attached nodes on the wired side. PC2 will recognise the IP address in the ARP request as its own and will generate a frame containing an ARP reply, using PC1 as the DA and its own MAC address as the SA. The STA, upon realising that the SA of the frame that it is about to transmit does not equal its own MAC address, will construct a 4-address header for the frame. On reception, the AP will use the SA and TA addresses to create a wds address entry as explained in the previous paragraph. The AP will then forward the frame over its wired interface to PC1. Now that state for PC2 has been established at the AP, it henceforth will know how to handle unicast frames coming from PC1 (your ICMP Echo Requests) and destined for PC2. However, when you reboot the AP all such state is of course lost. The AP will have to re-learn the relationships between STA and wired nodes attached to them. The only way it can, is by snooping ARP Replies (or Neighbour Advertisements in case of IPv6) again. Issuing an arp -d at PC1 will clear the ARP table entry for PC2 and forces PC1 to send a new ARP Request.

The diagrams below illustrate which MAC addresses go into which address fields for the over-the-air frames involved in your ping example.

  1. ARP "who-has-IP_PC2" from PC1
Addr1 Addr 2 Addr 3
Broadcast BSSID MAC_PC1
  1. ARP "PC2-is-at" from PC2
RA TA DA SA
BSSID MAC_STA MAC_PC1 MAC_PC2
  1. ICMP Echo Request from PC1
RA TA DA SA
MAC_STA BSSID MAC_PC2 MAC_PC1
  1. ICMP Echo Reply from PC2
RA TA DA SA
BSSID MAC_STA MAC_PC1 MAC PC2

As for a solution to your "problem", all I can say is: Don't reboot your AP!

04/17/09 14:48:27 changed by dinomycle@yahoo.com

Hi Ronald.intVelt@tno.nl

thanks a lot for the detailed explanation.

04/29/09 08:12:49 changed by Teco Boot

Here an option for improvement: We may think of implementing flooding "unknown" unicast packets, similar to 802.1D bridging. We have to define a 4-address header for it, with:

  • DA (Destination MAC address)
  • SA (Source MAC address)
  • TA (WLAN transmitter MAC address)
  • BSSID (to keep frame in the service set)

Because there is no RA (WLAN receiver MAC address), there is no way of implementing RTS-CTS or ACK. The frame is to be sent as multicast/broadcast. This may need extra attention when working on the enhancement.

05/04/09 10:38:34 changed by dinomycle@yahoo.com

yes if we do flooding the problem will be solved right ?