Reception:
General Informations
We report in this page the block diagram of the part of code we developed concerning the reception of frames: each box reppresents a label on the source, a check or a decision taken. Below we try to resume the firmware's behavior explaining the most important steps.
Reception starts with function rx_plcp that is called when a valid PLCP is recevied from the air. Here the frame is classified depending on its type: management, control or data. Later on, once the header part has been successfully received, it is analyzed: the firmware checks that the frame has a valid length and a valid protocol version, extracts informations for NAV update, extracts the type of the frame and look for WEP payload encryption.
If the frame is a control frame, rx_ack function will be called: currently firmware doesn't manage CTS or RTS frames. This is a key function in the transmission mechanism: rx_ack, in fact, checks the destination MAC address of ACK frame and if it matches the station address firmware, it checks that the system is actually waiting for an acknowledgement. In this case and if the EXPECTED_CTL_RESPONSE parameter matches the frame type, then the operation can be completed. The firmware stops the ACK timeout so that later the system will understand that the transmission has been successfully completed; finally the COND_TX_PMQ condition will be cleared so that tx_contention_params_update will be no longer triggered, unless it was explicitly called.
Another important function is send_response: every time a frame that needs to be acked is received, this function is called. send_response prepares the acknowledgement frame that will be sent back to the source station.
rx_beacon_probe_resp is fundamental for synchronization: this function, in fact, extracts time informations from both Beacon and Probe Response frames and adjusts the internal station counter.
rx_complete waits until the reception has been completed and, if everything went fine, it calls send_frame_to_host if the frame needs to be sent to the host (to the b43 driver), or discard_frame if the frame is not valid. Finally, send_frame_to_host calls push_frame_into_fifo, that copies the received frame into the receiving queue and rises up and interrupt so that the host will process the frame received through dma.
Every received data frame is also controlled in order to see if the destination address matches the station address. Only devices put in promiscuous mode can receive frames that are not directly addressed to them.
