You don't say whether this is an infrastructure or ad-hoc network. I just
reviewed the 802.11 standards, and it looks like all control, management,
and data frames put a MAC address in at least one of the four address
fields. A couple of things come to mind:
1. I believe that address bits are transmitted in least-to-most significant
bit order, since the group and broadcast bits must be processed first to
properly interpret the remaining address bits. I don't know how your
analyzer is set up to display the bits. Do you just have a simple
bit-ordering problem, so that the octets displayed by the analyzer are
reversed compared to the hex values you are looking for? Byte order might
also be reversed. If so, why don't you also have a problem making sense of
the fields in the frame control field (or do you - are you really seeing a
reserved protocol value and weird subtypes, or just parsing the bits in the
wrong order)?
2. If it's an ad-hoc network, the BSSID is a randomly-generated
locally-administered MAC address, and won't match any MAC you're looking
for. However, in data frames address field 1 should contain either the DA
(ad-hoc network) or the BSSID (infrastructure - see table 4). The BSSID will
be the AP's MAC address in an infrastructure network, so presumably address
field 1 contains the MAC address of the station you're monitoring, whichever
kind of network it is.
Could you enclose a couple of frame dumps, and the MAC address you expect to
find?
"Jerry" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Greetings,
> I am trying to capture the MACs in the frames. I need to know the time of
> arrival of the MACs.
> To get to the point, I have wired three signals from the Intersil Prism
chip
> set to a FPGA and logic analyzer.
> The signals are RXD, RXCLK and MD_RDY and I picked them off the HFA3861B
> chip. With the analyzer I can
> trigger storage on the rising edge of MD_RDY and store RXD. I can see
> SERVICE, SIGNAL and LENGTH
> data along with the CRC on the analyzer. The data I see in the PLCP header
> makes sense and agrees with the way the system is set up.
> Its when we get into the PSDU part of the frame things start to not
adhere
> to the 802.11 spec section 7 frame format definition.
>
> I am trying to locate the MAC of the transmitter in the frame but when I
> look at the captured data in the FPGA there is no data that
> matches the MAC. I have looked at the bits reversed and tried matching on
a
> byte by byte. The logic analyzer data agrees with the
> data in the FPGA so that validates my FPGA design.
>
> The vendor of the card sometimes uses a protocol of 01 which is reserved
> and various subtypes are also used that are reserved.
> I haven't seen a type of 11 (reserved) in the frame control.
>
> So my questions are these:
> 1. Is there some sort of bit interleaving of the mac address being
done?
> 2. Is there some sort of mapping of the mac to some other value being
> done?
> 3. If I restrict my data capture to association request and
> authentication will the MAC show up in the frame?
>
>
> The MAC I speak about is the MAC that is printed on the label on the
> equipment and matches the one displayed in the monitor
> program via the serial interface,
>
> Thanks for any info.
> Regards
> Jer
>
>
>
>
|