I noticed that when I send packets in ATH_MAC_TX_RAW mode the channel number does not stay set.
I first call qcom_set_channel() and then immediately send a packet using custom_qapi() with ATH_MAC_TX_RAW mode and what I observe on a monitoring device is that the channel number that the packet comes out on is all over the place.
If anyone knows how to lock down the channel number for a raw packet transmission that would be helpful.
Roger
Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.
I did a little more investigation. I notice that qcom_get_channel() appears always to return A_OK status but the value returned is always 0, even after calling qcom_set_channel() and successfully setting the channel to a valid number. I would think that if qcom_set_channel() returns A_OK, I would immediately be able to read the channel back and have it reflect what I just wrote. But apparently not.
So, flaky operation prevails so far.
Roger
I have the same problem - qcom_get_channel() always returns zero, even after qcom_set_channel() was called successfully with a valid channel number and A_OK is returned.
Has anyone else seen this or know of a possible solution?
My team was also having problems getting qcom_set_channel to work correctly. We have isolated the problem as being a bug in the driver:
- The API call qcom_set_channel() sends an ATH_SET_CHANNEL command with the data pointer equal to the address of the requested channel frequency stored as a uint16.
- This eventually makes its way to ath_ioctl_handler(), where param_ptr->data is aliased as PTR_SET_CHAN, defined as follows:
#define PTR_SET_CHAN ((uint_32_ptr*)(data))
- The case for ATH_SET_CHANNEL then sets the device context channelHint member to the thing pointed to by PTR_SET_CHAN, casted to a uint16.
This likely works as intended on little endian architectures, which would explain why it has not been noticed by Qualcomm.
In our case (our MCU architecture is big-endian), this assigns the wrong half of the 32-bits of data pointed to by PTR_SET_CHAN to channelHint.
This effectively assigns garbage data to the channelHint and any ensuing connect call to put the GT202 into AP mode tells it to use a channel which probably doesn’t exist.
Our quick fix has been to edit qcom_set_channel() to take a 32-bit unsigned integer for the channel argument.