Is there any way the Extended Rate PHY Element (Element ID 42 or 47) could appear in a frame (Beacon, Probe Response, etc) on a 5 GHz network?
The standard seems to say they should appear ONLY in networks supporting 802.11g, and I haven't been able to capture an occurrence on 5 GHz, but I'm seeing some indirect evidence of them in 5 GHz with another program (to remain anonymous at this point).
ERP should only be seen on g, ERP-OFDM, 2.4 GHz. But like you, Ive seen protocol analyzers interrupt values differently. Wireshark seems to do this more often than I like. However Im a fan of Omnipeek for deep packet and while they have some values that can make you smh from time to time, if you email Jay he is quick to mention yes its an issue or no and this is why.
I don't know if this will help, but 5 GHZ is also 801.11a, which is the same as 802.11g, just a different band..
ERP-OFDM (802.11g) and OFDM (802.11a) are indeed different in some ways. While they share the same modulation OFDM, ERP-OFDM uses 22 Mhz specs, OFDM uses 20 Mhz. Also ERP-OFDM has the backwards compatibility mechanism which OFDM 802.11a does not. Similar but not the same.
I agree the channel widths are different between 2.4 and 5 GHz, but everything I have read, including the spec. shows that both OFDM's have the same Spectral Masks, which are 20MHz wide. g just doesn't use the full channel width.
The MAC's are different to allow for compatibility, but other than that there is no difference in the modulation or coding between a & g.
If you can reference a specific part of the 802.11 spec, that says differently, I would like to read it.
I'd say it was buggy firmware, or that you had actually captured a 2.4 GHz packet.
I wanted to edit my last post because it was done on a mobile and was rather quick.
The original question "Is there any way the Extended Rate PHY Element (Element ID 42 or 47) could appear in a frame (Beacon, Probe Response, etc) on a 5 GHz network?"
"I don't know if this will help, but 5 GHZ is also 801.11a, which is the same as 802.11g, just a different band.."
As I mentioned in my post they are indeed different. Which is part of his problem. He is seeing ERP -OFDM info in OFDM. If they were the same -- then there wouldn't no ERP and he wouldn't see this as a problem. I didn't want someone to read your post and say " they are the same " and move on. I also mentioned in my post some of the differences which you then stated in your follow post :) LOL
They are different. Its likely the protocol analyzer is not reading the frame properly.
I'm extremly sorry to resurrect this dead thread. But i really cannot find anywhere why id of "ERP information" can be 47??? I checked all standards which i could find (802.11-1999, 802.11g-2003, 802.11-2012 and some others), and everywhere it is marked as "reserved". But in wireshark, and with several routers i still see this tag with this id. Am i missing something? why is it not enough id 42? how it happened that 47 tag appeared to be "ERP information"? Which purpose does it has?
A couple of questions:
1. What sniffer are you using and what is the actual radio being used by the sniffer ? We really need to know.
2. What brand and model of AP is being used ?
3. What mode (n/a/ac) does the AP think it is broadcasting in?
4. Does the AP Log show anything when this happens ?
Howard, thanks a lot for the reply.
1. I am using wireshark, as a sniffer I put dlink dwa-160 in monitor mode
2. This is a bit complicated, it is a kind of custom board based on broadcom chipset. But I saw it before with other APs + searching through internet brought me here. For example I also found that it is tag number 47 on this site:
3. It is actually in 2.4 GHz, b/g/n I suppose.
4. I don't know :) don't have access to it.
I was just wondering, why is it tag number 47? Standard says that it should be tag number 42 and tag number 47 is "reserved". And actually i see in pcap that there is also tag number 42, is it duplication? Why wireshark shows it as an "ERP information element"? Is it kind of vendor specific information element?
Unless it really is 2.4 GHz, the only reason I could see that happening is due to a buggy AP firmware or bad Wireshark version.
This is also an obsolete adapter, but its hard to believe that could cause it..
Are you using the latest copy of Wireshark ? Besides the occasional decoding error, Wireshark is sometimes slow to update their decoding routines - (especially for vendor specific indicators).
Unless it is causing you a problem, it's probably best just chalked up to the "something I've seen before category".