Hello,
I am a developer for IWD and trying to implement IBSS networks. The
initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
to connect two stations. The problem is that I am hitting a timeout in
the kernel once the connection has succeeded and there are no more
frames flowing between stations. I dug around in the kernel and saw
there is a 60 second inactivity timeout which is precicely what is
happening. After setting the keys 60 seconds go by and I recieve a
DEL_STATION (log attached).
My question is: is this timeout expected after the station has been
added and the keys are set? If so how does one reset this timeout so
the connection can remain alive even if no data is being sent?
heartbeat of some kind?
The log attached was obtained with iwmon, which is a utility included
in IWD that monitors NL traffic.
Thanks,
James
On Tue, 2018-07-17 at 09:57 +0200, Nicolas Cavallari wrote:
> On 16/07/2018 21:31, James Prestwood wrote:
> >
> > Hello,
> >
> > I am a developer for IWD and trying to implement IBSS networks. The
> > initial IBSS_JOIN, 4-way, and setting the keys all works and I am
> > able
> > to connect two stations. The problem is that I am hitting a timeout
> > in
> > the kernel once the connection has succeeded and there are no more
> > frames flowing between stations. I dug around in the kernel and saw
> > there is a 60 second inactivity timeout which is precicely what is
> > happening. After setting the keys 60 seconds go by and I recieve a
> > DEL_STATION (log attached).
> >
> > My question is: is this timeout expected after the station has been
> > added and the keys are set? If so how does one reset this timeout
> > so
> > the connection can remain alive even if no data is being sent?
> > heartbeat of some kind?
> This is not normal, but it isn't your fault. It's more a problem with
> your card
> firmware/driver. What card/driver do you have ?
One side has an Intel 7260 and the other has an Atheros 9462. It seems
to only be the 7260 that is getting the DEL_STATION events after the
timeout. I haven't seen the Ath 9k behave like this.
>
> In IBSS mode, all stations are required to send beacons. The protocol
> is a bit
> complex to arrange that, every 102.4ms, a station is chosen to emit
> the beacon.
>
> Receiving beacons from a station is enough to reset its timer, so
> with a
> properly functioning station, this timer does not expire.
>
> Unfortunately, in the wild, nobody test that IBSS beacons are
> generated, because
> without them, an open IBSS still appear to work...
Hmm, so how does one mitigate this? Manually sending beacons? That
would get messy if some cards do it automatically and some don't.
Something else I forgot to mention/ask in my original email was about
deauthentication. If one station does a LEAVE_IBSS, the other side
doesn't recieve a DEL_STATION until that 60 second inactivity timeout.
If we explicitly leave should the kernel send a deauth automatically? I
know wpa_supplicant explicitly sends a deauth, but I wasn't sure if
this was working around a bug or if it was the intended to be that way.
Thanks,
James
On 17/07/2018 17:02, Ben Greear wrote:
> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>> In IBSS mode, all stations are required to send beacons. The protocol
>> is a bit
>> complex to arrange that, every 102.4ms, a station is chosen to emit
>> the beacon.
>
> I'm not sure this part is correct. In practice, it seems to often
> happen this way,
> but last time I read the spec on this it seems like it is supposed to
> sort of negotiate
> and not have all ibss stations beaconning.
Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
IBSS participate in beacon generation."
On each TBTT, each station must wait for a random delay before
transmitting, and the first one to transmit wins.
In theory...
On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
> On 16/07/2018 21:31, James Prestwood wrote:
>> Hello,
>>
>> I am a developer for IWD and trying to implement IBSS networks. The
>> initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
>> to connect two stations. The problem is that I am hitting a timeout in
>> the kernel once the connection has succeeded and there are no more
>> frames flowing between stations. I dug around in the kernel and saw
>> there is a 60 second inactivity timeout which is precicely what is
>> happening. After setting the keys 60 seconds go by and I recieve a
>> DEL_STATION (log attached).
>>
>> My question is: is this timeout expected after the station has been
>> added and the keys are set? If so how does one reset this timeout so
>> the connection can remain alive even if no data is being sent?
>> heartbeat of some kind?
>
> This is not normal, but it isn't your fault. It's more a problem with your card
> firmware/driver. What card/driver do you have ?
>
> In IBSS mode, all stations are required to send beacons. The protocol is a bit
> complex to arrange that, every 102.4ms, a station is chosen to emit the beacon.
I'm not sure this part is correct. In practice, it seems to often happen this way,
but last time I read the spec on this it seems like it is supposed to sort of negotiate
and not have all ibss stations beaconning.
Thanks,
Ben
>
> Receiving beacons from a station is enough to reset its timer, so with a
> properly functioning station, this timer does not expire.
>
> Unfortunately, in the wild, nobody test that IBSS beacons are generated, because
> without them, an open IBSS still appear to work...
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 17/07/2018 18:19, James Prestwood wrote:
> On Tue, 2018-07-17 at 09:57 +0200, Nicolas Cavallari wrote:
>> This is not normal, but it isn't your fault. It's more a problem with
>> your card
>> firmware/driver. What card/driver do you have ?
>
> One side has an Intel 7260 and the other has an Atheros 9462. It seems
> to only be the 7260 that is getting the DEL_STATION events after the
> timeout. I haven't seen the Ath 9k behave like this.
It's not clear who is seeing the DEL_STATION for which station.
Your trace hints at 6C:71:D9:0D:6E:4B not sending beacons. A wireless
capture should confirm this.
>> In IBSS mode, all stations are required to send beacons. The protocol
>> is a bit
>> complex to arrange that, every 102.4ms, a station is chosen to emit
>> the beacon.
>>
>> Receiving beacons from a station is enough to reset its timer, so
>> with a
>> properly functioning station, this timer does not expire.
>>
>> Unfortunately, in the wild, nobody test that IBSS beacons are
>> generated, because
>> without them, an open IBSS still appear to work...
> Hmm, so how does one mitigate this? Manually sending beacons? That
> would get messy if some cards do it automatically and some don't.
Sending null frames could do the trick, i'm not sure userspace is
allowed to send them with cmd_frame in IBSS mode through.
That, or asking the manufacturer to fix their driver :)
> Something else I forgot to mention/ask in my original email was about
> deauthentication. If one station does a LEAVE_IBSS, the other side
> doesn't recieve a DEL_STATION until that 60 second inactivity timeout.
> If we explicitly leave should the kernel send a deauth automatically? I
> know wpa_supplicant explicitly sends a deauth, but I wasn't sure if
> this was working around a bug or if it was the intended to be that way.
wpa_supplicant sends a deauth when leaving an ibss ? I haven't seen any
code doing that. I don't know why it does that.
On 07/17/2018 10:44 AM, Nicolas Cavallari wrote:
> On 17/07/2018 17:02, Ben Greear wrote:
>> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>>> In IBSS mode, all stations are required to send beacons. The protocol
>>> is a bit
>>> complex to arrange that, every 102.4ms, a station is chosen to emit
>>> the beacon.
>>
>> I'm not sure this part is correct. In practice, it seems to often
>> happen this way,
>> but last time I read the spec on this it seems like it is supposed to
>> sort of negotiate
>> and not have all ibss stations beaconning.
>
> Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
> IBSS participate in beacon generation."
>
> On each TBTT, each station must wait for a random delay before
> transmitting, and the first one to transmit wins.
>
> In theory...
>
See 11.1.3.5, section d and e. I think this means that if it receives a beacon while
waiting to transmit one, then it cancels its intent to transmit the beacon. So
while they 'participate', they may not actually generate beacons?
I could be wrong about my interpretation of this however, and I am not sure how it
is actually implemented.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 18/07/2018 01:53, Ben Greear wrote:
> On 07/17/2018 10:44 AM, Nicolas Cavallari wrote:
>> On 17/07/2018 17:02, Ben Greear wrote:
>>> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>>>> In IBSS mode, all stations are required to send beacons. The protocol
>>>> is a bit
>>>> complex to arrange that, every 102.4ms, a station is chosen to emit
>>>> the beacon.
>>>
>>> I'm not sure this part is correct. In practice, it seems to often
>>> happen this way,
>>> but last time I read the spec on this it seems like it is supposed to
>>> sort of negotiate
>>> and not have all ibss stations beaconning.
>>
>> Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
>> IBSS participate in beacon generation."
>>
>> On each TBTT, each station must wait for a random delay before
>> transmitting, and the first one to transmit wins.
>>
>> In theory...
>>
>
> See 11.1.3.5, section d and e. I think this means that if it receives a beacon while
> waiting to transmit one, then it cancels its intent to transmit the beacon. So
> while they 'participate', they may not actually generate beacons?
>
> I could be wrong about my interpretation of this however, and I am not sure how it
> is actually implemented.
The a to g sections are done at each TBTT. If another station sent a beacon,
then by section d) we lost and we don't transmit. Since the random number in b)
is generated at each TBTT and uses a uniform distribution, all station have a
chance to win.
Considering a BI of 102.4ms, a timeout of 60s and a 100% idle network, a station
must lose 585 times to start risking being deleted. The probability of that
happening for a given station in a IBSS with N station is (1-1/n)**585. Even
with 50 stations, it's only twice as much as the probability to be struck by
lightning. And it does not account for losses, which will cause more beacon to
be transmitted.
On 16/07/2018 21:31, James Prestwood wrote:
> Hello,
>
> I am a developer for IWD and trying to implement IBSS networks. The
> initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
> to connect two stations. The problem is that I am hitting a timeout in
> the kernel once the connection has succeeded and there are no more
> frames flowing between stations. I dug around in the kernel and saw
> there is a 60 second inactivity timeout which is precicely what is
> happening. After setting the keys 60 seconds go by and I recieve a
> DEL_STATION (log attached).
>
> My question is: is this timeout expected after the station has been
> added and the keys are set? If so how does one reset this timeout so
> the connection can remain alive even if no data is being sent?
> heartbeat of some kind?
This is not normal, but it isn't your fault. It's more a problem with your card
firmware/driver. What card/driver do you have ?
In IBSS mode, all stations are required to send beacons. The protocol is a bit
complex to arrange that, every 102.4ms, a station is chosen to emit the beacon.
Receiving beacons from a station is enough to reset its timer, so with a
properly functioning station, this timer does not expire.
Unfortunately, in the wild, nobody test that IBSS beacons are generated, because
without them, an open IBSS still appear to work...