AID limitations in hostAPD
Wed Mar 18 00:41:49 PDT 2015
On Wed, 2015-03-18 at 07:05 +0000, Atul Joshi wrote:
> Hi all,
> I can see that the AIDS are assigned from 1 onwards by hostAPD.
Depending on how you read this, this isn't really true. hostapd will
always pack the AID as low as possible, so if the station with AID 5
goes away, that AID will be reused by the next station to connect.
> It would mean that if an AP supports (or GO), 8 stations, it would
> have to keep changing the TIM IE length based on if the TIM bit needs
> to be set or not. (If no station is in PS or no bit in TIM bit PVB is
> set, the PVB length, according to the spec has to be 1 octet rather
> than 2 octets)
If you only support 8 stations, only AIDs 1-8 will be used by hostapd.
> Instead if it could assign the AID from 16-23 for example, it will not
> have to keep changing the length of the TIM IE.
I don't see the difference at all. You're very strictly reading the
required TIM IE format, and if you have only AIDs 16-23 then N1 would be
4, and you have the same problem just shifted down by 4 bytes. At the
very least, you'd not have the PVB at least when no station is in
In practice, I don't think you need to read this as strictly, and can
just always send a TIM IE as
[EID] [len] [DTIM count] [DTIM period] [0 or 1] [PVB]
so that you always have the PVB even when it's entirely 0. This is
really the only case you need to worry about, since the bitmap offset is
in bytes and thus you can never have it non-zero anyway.
> Can I have some thoughts from what the group thinks and if others
> agree, I can propose a patch.
I don't think this is a good idea - there are other things in the system
that assume low AIDs. Changing this would potentially break other
drivers and would then probably have to be a feature flag etc. and be
More information about the Hostap