ROAM/CONNECT event with PORT_AUTHORIZED

ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

Hi Arend, Jouni, all,

Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
which is PMKSA caching.

Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
connection (doesn't matter if it's roaming or not), the AP may chose to
use it and start the 4-way-HS, or it may not be able to and start the
802.1X handshake.

In the supplicant, if you are waiting for the 1X handshake, then in the
case the PMKSA gets used the supplicant would wait forever, and
eventually terminate the connection because the handshake isn't
successful.

Thus, *both* cases need to know about the PORT_AUTHORIZED flag.

I previously didn't apply the patch for the flag in CONNECT
notification, but nobody is using it in ROAM notification so far, so
that we still have a chance of revisiting this.

Throwing a potential EAPOL-over-nl80211 (*) into the mix complicates
the picture further. For example, in that case the OPER_STATE might not
be set to UP until the port is authorized. In the case of roaming, this
might - on first sight - lead to toggling DOWN/UP if a new 1X handshake
needs to be done and the PORT_AUTHORIZED flag doesn't come with the
ROAM event. However, I think this is actually wrong as it would
probably lose IPv6 address assignment etc. - so I think we don't want
to do this even if we do have EAPOL-over-nl80211 and don't need the
oper_state to be up in order to do the 1X handshake. Do you agree with
this assessment?

Assuming this assessment is correct, this opens up another possibility:
tracking the PORT_AUTHORIZED state with a separate event:

 * new connection case - no PMKSA (usage)
   - CONNECT event
     - [if !eapol-over-nl: toggle oper state up]
     - initialize 1X state machines/timeouts
   - 1X handshake
   - send PMK to device for 4-way-HS
   - AUTHORIZED event
     - [if eapol-over-nl: toggle oper state up]

 * new connection case - PMKSA usage
   - CONNECT event
     - [if !eapol-over-nl: toggle oper state up]
     - initialize 1X state machines/timeouts
   - AUTHORIZED event
     - stop 1X state machine/timeouts
     - [if eapol-over-nl: toggle oper state up]

 * roaming case - no PMKSA (usage)
   - ROAM event
     - [no touching oper state]
     - initialize 1X state machines/timeouts
   - 1X handshake
   - AUTHORIZED event
     - [no touching oper state]

 * roaming case - PMKSA usage
   - ROAM event
     - [no touching oper state]
     - initialize 1X state machines/timeouts
   - AUTHORIZED event
     - stop 1X state machine/timeouts
     - [no touching oper state]


Does this seem reasonable? If possible, I prefer this to just having
the attribute, because with the attribute the roaming case will be
difficult, the natural code flow in the driver would probably make it
end up looking like this:

 * roaming case - no PMKSA (usage)
   - ROAM event
     - [no touching
oper state]
     - initialize 1X state machines/timeouts
   - 1X
handshake
   - CONNECT event w/ PORT_AUTHORIZED
     - [no touching oper
state]

which seems awkward.

Any other thoughts?

johannes

(*) is anyone working on that? I'll throw it on my list if not.

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Arend van Spriel]

On 14-09-17 10:39, Johannes Berg wrote:
> Hi Arend, Jouni, all,
> 
> Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
> which is PMKSA caching.
> 
> Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
> connection (doesn't matter if it's roaming or not), the AP may chose to
> use it and start the 4-way-HS, or it may not be able to and start the
> 802.1X handshake.
> 
> In the supplicant, if you are waiting for the 1X handshake, then in the
> case the PMKSA gets used the supplicant would wait forever, and
> eventually terminate the connection because the handshake isn't
> successful.
> 
> Thus, *both* cases need to know about the PORT_AUTHORIZED flag.
> 
> I previously didn't apply the patch for the flag in CONNECT
> notification, but nobody is using it in ROAM notification so far, so
> that we still have a chance of revisiting this.
> 
> Throwing a potential EAPOL-over-nl80211 (*) into the mix complicates
> the picture further. For example, in that case the OPER_STATE might not
> be set to UP until the port is authorized. In the case of roaming, this
> might - on first sight - lead to toggling DOWN/UP if a new 1X handshake
> needs to be done and the PORT_AUTHORIZED flag doesn't come with the
> ROAM event. However, I think this is actually wrong as it would
> probably lose IPv6 address assignment etc. - so I think we don't want
> to do this even if we do have EAPOL-over-nl80211 and don't need the
> oper_state to be up in order to do the 1X handshake. Do you agree with
> this assessment?

Yep. Toggling the OPER_STATE seems to go against what roaming is about. 
Come to think of it, is it a good idea to tightly couple PORT_AUTHORIZED 
to OPER_STATE. Aren't these separate concepts in different layers of the 
network stack.
> Assuming this assessment is correct, this opens up another possibility:
> tracking the PORT_AUTHORIZED state with a separate event:
> 
>   * new connection case - no PMKSA (usage)
>     - CONNECT event
>       - [if !eapol-over-nl: toggle oper state up]
>       - initialize 1X state machines/timeouts
>     - 1X handshake
>     - send PMK to device for 4-way-HS
>     - AUTHORIZED event
>       - [if eapol-over-nl: toggle oper state up]
> 
>   * new connection case - PMKSA usage
>     - CONNECT event
>       - [if !eapol-over-nl: toggle oper state up]
>       - initialize 1X state machines/timeouts
>     - AUTHORIZED event
>       - stop 1X state machine/timeouts
>       - [if eapol-over-nl: toggle oper state up]
> 
>   * roaming case - no PMKSA (usage)
>     - ROAM event
>       - [no touching oper state]
>       - initialize 1X state machines/timeouts
>     - 1X handshake
>     - AUTHORIZED event
>       - [no touching oper state]
> 
>   * roaming case - PMKSA usage
>     - ROAM event
>       - [no touching oper state]
>       - initialize 1X state machines/timeouts
>     - AUTHORIZED event
>       - stop 1X state machine/timeouts
>       - [no touching oper state]
> 
> 
> Does this seem reasonable? If possible, I prefer this to just having
> the attribute, because with the attribute the roaming case will be
> difficult, the natural code flow in the driver would probably make it
> end up looking like this:
> 
>   * roaming case - no PMKSA (usage)
>     - ROAM event
>       - [no touching
> oper state]
>       - initialize 1X state machines/timeouts
>     - 1X
> handshake
>     - CONNECT event w/ PORT_AUTHORIZED
>       - [no touching oper
> state]
> 
> which seems awkward.
> 
> Any other thoughts?

In earlier discussions the proposal for a separate event was made by 
Jithu (colleague). In brcmfmac it would become a bit less complicated 
with a separate event so it has my vote as well. So the AUTHORIZED event 
will have no attributes, right? So if the event occurs it is AUTHORIZED.

> johannes
> 
> (*) is anyone working on that? I'll throw it on my list if not.

The last I saw on this was Denis Kenzior volunteering for it, but that 
was about it.

By the way, I still have wpa_supplicant patches for 4way-hs offloading. 
I need to dust it off a little and obviously did not foresee the change 
above ;-) Let me know if you (Intel) plan to submit patches for it.

Regards,
Arend

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 13:21 +0200, Arend van Spriel wrote:

> Yep. Toggling the OPER_STATE seems to go against what roaming is
> about. 

Agree.

> Come to think of it, is it a good idea to tightly couple
> PORT_AUTHORIZED to OPER_STATE. Aren't these separate concepts in
> different layers of the network stack.

Well, I think that coupling would make the most sense, since once you
have oper state UP you'll try to get IPv6 etc., no? And before being
authorized there's no point.

Note that we *can't* do this right now, otherwise we can't transfer the
EAPOL frames; but once we do that over nl80211 we'd be able to.

> In earlier discussions the proposal for a separate event was made by 
> Jithu (colleague). In brcmfmac it would become a bit less
> complicated with a separate event so it has my vote as well. So the
> AUTHORIZED event will have no attributes, right? So if the event
> occurs it is AUTHORIZED.

I think so, yes. I pondered having the attribute in there so you could
explicitly have a "not authorized" event, but do we really need that?
If you get disconnected that's pretty much implied, so ... I don't
think we need it.


> > (*) is anyone working on that? I'll throw it on my list if not.

["that" being EAPOL-over-nl80211]

> The last I saw on this was Denis Kenzior volunteering for it, but
> that was about it.

Oh, thanks for the reminder, I'd forgotten entirely...
Denis?

> By the way, I still have wpa_supplicant patches for 4way-hs
> offloading. I need to dust it off a little and obviously did not
> foresee the change above ;-) Let me know if you (Intel) plan to
> submit patches for it.

We also have some patches, we can go either way.

Thanks!

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/14/2017 03:39 AM, Johannes Berg wrote:
> Hi Arend, Jouni, all,
> 
> Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
> which is PMKSA caching.
> 
> Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
> connection (doesn't matter if it's roaming or not), the AP may chose to
> use it and start the 4-way-HS, or it may not be able to and start the
> 802.1X handshake.

Curious, isn't sending a PMKID for a non-roaming case not strictly per 
spec?  Is this just to avoid running 802.1x?

> 
> In the supplicant, if you are waiting for the 1X handshake, then in the
> case the PMKSA gets used the supplicant would wait forever, and
> eventually terminate the connection because the handshake isn't
> successful.
> 
> Thus, *both* cases need to know about the PORT_AUTHORIZED flag.
> 
> I previously didn't apply the patch for the flag in CONNECT
> notification, but nobody is using it in ROAM notification so far, so
> that we still have a chance of revisiting this.
> 
> Throwing a potential EAPOL-over-nl80211 (*) into the mix complicates
> the picture further. For example, in that case the OPER_STATE might not
> be set to UP until the port is authorized. In the case of roaming, this
> might - on first sight - lead to toggling DOWN/UP if a new 1X handshake
> needs to be done and the PORT_AUTHORIZED flag doesn't come with the
> ROAM event. However, I think this is actually wrong as it would
> probably lose IPv6 address assignment etc. - so I think we don't want
> to do this even if we do have EAPOL-over-nl80211 and don't need the
> oper_state to be up in order to do the 1X handshake. Do you agree with
> this assessment?

How does this mesh with operstates outlined in 
Documentation/networking/operstates.txt?  Are you treating the 'roaming' 
case as 802.1x 'reauthentication'?

> 
> Assuming this assessment is correct, this opens up another possibility:
> tracking the PORT_AUTHORIZED state with a separate event:
> 
>   * new connection case - no PMKSA (usage)
>     - CONNECT event
>       - [if !eapol-over-nl: toggle oper state up]

Doesn't this go against operstates.txt, Section 4?

Also, I must be dense, but why is the behavior different between 
eapol-over-nl and not?

>       - initialize 1X state machines/timeouts
>     - 1X handshake
>     - send PMK to device for 4-way-HS
>     - AUTHORIZED event
>       - [if eapol-over-nl: toggle oper state up]
> 
>   * new connection case - PMKSA usage
>     - CONNECT event
>       - [if !eapol-over-nl: toggle oper state up]
>       - initialize 1X state machines/timeouts
>     - AUTHORIZED event
>       - stop 1X state machine/timeouts
>       - [if eapol-over-nl: toggle oper state up]
> 
>   * roaming case - no PMKSA (usage)
>     - ROAM event
>       - [no touching oper state]

My understanding is that oper state goes back to dormant in case we 
re-associate.  At least we needed to set it back to UP after a fast 
transition?

>       - initialize 1X state machines/timeouts
>     - 1X handshake
>     - AUTHORIZED event
>       - [no touching oper state]
> 
>   * roaming case - PMKSA usage
>     - ROAM event
>       - [no touching oper state]
>       - initialize 1X state machines/timeouts
>     - AUTHORIZED event
>       - stop 1X state machine/timeouts
>       - [no touching oper state]
> 
> 
> Does this seem reasonable? If possible, I prefer this to just having
> the attribute, because with the attribute the roaming case will be
> difficult, the natural code flow in the driver would probably make it
> end up looking like this:
> 
>   * roaming case - no PMKSA (usage)
>     - ROAM event
>       - [no touching
> oper state]
>       - initialize 1X state machines/timeouts
>     - 1X
> handshake
>     - CONNECT event w/ PORT_AUTHORIZED
>       - [no touching oper
> state]
> 
> which seems awkward.
> 
> Any other thoughts?

A separate authorized event seems fine to me...

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

Hi Denis,

I'd actually only Cc'ed you to see if you were actually working on
EAPOL-over-nl80211 :-)

> Curious, isn't sending a PMKID for a non-roaming case not strictly
> per spec?  Is this just to avoid running 802.1x?

I don't think so, what makes you? In -2016 9.4.2.25.5 for example, the
spec says:

    The PMKID Count and List fields are used only in the RSNE in the
    (Re)Association Request frame to an AP and in FT authentication
    sequence frames.

Why should it only be valid in roaming? You might turn off and on wifi
and still have a PMKSA.

> How does this mesh with operstates outlined in 
> Documentation/networking/operstates.txt?  Are you treating the
> 'roaming' case as 802.1x 'reauthentication'?

I think we have to, because otherwise DHCP/IPv6 could happen again
after roaming - we really can't set the oper state to dormant during
the roaming.

> > Assuming this assessment is correct, this opens up another
> > possibility:
> > tracking the PORT_AUTHORIZED state with a separate event:
> > 
> >   * new connection case - no PMKSA (usage)
> >     - CONNECT event
> >       - [if !eapol-over-nl: toggle oper state up]
> 
> Doesn't this go against operstates.txt, Section 4?

Why?

> Also, I must be dense, but why is the behavior different between 
> eapol-over-nl and not?

Because for EAPOL-over-data, we actually have to have IF_OPER_UP to be
able to TX/RX the EAPOL frames.

> >       - initialize 1X state machines/timeouts
> >     - 1X handshake
> >     - send PMK to device for 4-way-HS
> >     - AUTHORIZED event
> >       - [if eapol-over-nl: toggle oper state up]
> > 
> >   * new connection case - PMKSA usage
> >     - CONNECT event
> >       - [if !eapol-over-nl: toggle oper state up]
> >       - initialize 1X state machines/timeouts
> >     - AUTHORIZED event
> >       - stop 1X state machine/timeouts
> >       - [if eapol-over-nl: toggle oper state up]
> > 
> >   * roaming case - no PMKSA (usage)
> >     - ROAM event
> >       - [no touching oper state]
> 
> My understanding is that oper state goes back to dormant in case we 
> re-associate.  At least we needed to set it back to UP after a fast 
> transition?

Like I said above, I really don't think we should/can do this, I think
we'd lose at least IPv6 connectivity in the meantime?

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/14/2017 06:44 AM, Johannes Berg wrote:
> On Thu, 2017-09-14 at 13:21 +0200, Arend van Spriel wrote:
> 
>> Yep. Toggling the OPER_STATE seems to go against what roaming is
>> about.
> 
> Agree.

The question is whether all APs are actually sane after a roam.  E.g. 
can the STA assume that the same IP address, DHCP lease, etc is still 
valid?  I heard from various people that this might not be the case, but 
we haven't had a chance to verify those claims...

> 
>> Come to think of it, is it a good idea to tightly couple
>> PORT_AUTHORIZED to OPER_STATE. Aren't these separate concepts in
>> different layers of the network stack.
> 
> Well, I think that coupling would make the most sense, since once you
> have oper state UP you'll try to get IPv6 etc., no? And before being
> authorized there's no point.
> 

I think it does make sense to tie one into the other.  However, do we 
have a race condition here?  E.g. AUTHORIZED is sent on one socket, then 
OPER_STATE is signaled on rtnl.  Which one do applications rely on?

> Note that we *can't* do this right now, otherwise we can't transfer the
> EAPOL frames; but once we do that over nl80211 we'd be able to.
> 
>> In earlier discussions the proposal for a separate event was made by
>> Jithu (colleague). In brcmfmac it would become a bit less
>> complicated with a separate event so it has my vote as well. So the
>> AUTHORIZED event will have no attributes, right? So if the event
>> occurs it is AUTHORIZED.
> 
> I think so, yes. I pondered having the attribute in there so you could
> explicitly have a "not authorized" event, but do we really need that?
> If you get disconnected that's pretty much implied, so ... I don't
> think we need it.
> 
> 
>>> (*) is anyone working on that? I'll throw it on my list if not.
> 
> ["that" being EAPOL-over-nl80211]
> 
>> The last I saw on this was Denis Kenzior volunteering for it, but
>> that was about it.
> 
> Oh, thanks for the reminder, I'd forgotten entirely...
> Denis?

*wakes up*

Ah I now seem to remember that I volunteered to look into this before my 
sabbatical :)  I think this was in early June?  I'm certainly still 
interested in doing so.   Let me dust off that portion of my brain and 
come up with a proposal.  Unless you already have a clear idea of how 
things should work?

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/14/2017 01:36 PM, Johannes Berg wrote:
> Hi Denis,
> 
> I'd actually only Cc'ed you to see if you were actually working on
> EAPOL-over-nl80211 :-)
> 
>> Curious, isn't sending a PMKID for a non-roaming case not strictly
>> per spec?  Is this just to avoid running 802.1x?
> 
> I don't think so, what makes you? In -2016 9.4.2.25.5 for example, the
> spec says:
> 
>      The PMKID Count and List fields are used only in the RSNE in the
>      (Re)Association Request frame to an AP and in FT authentication
>      sequence frames.
> 
> Why should it only be valid in roaming? You might turn off and on wifi
> and still have a PMKSA.

Yep, but I seem to recall there was some vague language that said the AP 
would delete the PMKSA if the client disconnected.  Sorry, getting back 
on track:

> 
>> How does this mesh with operstates outlined in
>> Documentation/networking/operstates.txt?  Are you treating the
>> 'roaming' case as 802.1x 'reauthentication'?
> 
> I think we have to, because otherwise DHCP/IPv6 could happen again
> after roaming - we really can't set the oper state to dormant during
> the roaming.
> 

Okay, I can buy this interpretation...

>>> Assuming this assessment is correct, this opens up another
>>> possibility:
>>> tracking the PORT_AUTHORIZED state with a separate event:
>>>
>>>    * new connection case - no PMKSA (usage)
>>>      - CONNECT event
>>>        - [if !eapol-over-nl: toggle oper state up]
>>
>> Doesn't this go against operstates.txt, Section 4?
> 
> Why?

operstates.txt states that for new connections, operstate should be 
dormant until 802.1x is complete & successful.  So the !eapol-over-nl 
condition would violate that, no?

> 
>> Also, I must be dense, but why is the behavior different between
>> eapol-over-nl and not?
> 
> Because for EAPOL-over-data, we actually have to have IF_OPER_UP to be
> able to TX/RX the EAPOL frames.
> 

Okay.  But then wouldn't userspace now have to deal with two different 
behaviors now?

>>>        - initialize 1X state machines/timeouts
>>>      - 1X handshake
>>>      - send PMK to device for 4-way-HS
>>>      - AUTHORIZED event
>>>        - [if eapol-over-nl: toggle oper state up]
>>>

Given your explanation above, should this be [if !eapol-over-nl ..?

>>>    * new connection case - PMKSA usage
>>>      - CONNECT event
>>>        - [if !eapol-over-nl: toggle oper state up]
>>>        - initialize 1X state machines/timeouts
>>>      - AUTHORIZED event
>>>        - stop 1X state machine/timeouts
>>>        - [if eapol-over-nl: toggle oper state up]
>>>
>>>    * roaming case - no PMKSA (usage)
>>>      - ROAM event
>>>        - [no touching oper state]
>>
>> My understanding is that oper state goes back to dormant in case we
>> re-associate.  At least we needed to set it back to UP after a fast
>> transition?
> 
> Like I said above, I really don't think we should/can do this, I think
> we'd lose at least IPv6 connectivity in the meantime?
> 

So I agree that OPERSTATE_UP should not change on a roam.  I think we're 
both in agreement here.

My earlier point is that software roams need to have the exact same 
behavior as well.  And my understanding is that when we try to 
Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no longer UP.

At the very least there's lots of confusion with what is supposed to 
happen with operstate and when.  So if we can work out & document a 
consistent behavior, I'm all for it.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 13:37 -0500, Denis Kenzior wrote:

> The question is whether all APs are actually sane after a
> roam.  E.g. can the STA assume that the same IP address, DHCP lease,
> etc is still valid?  I heard from various people that this might not
> be the case, but we haven't had a chance to verify those claims...

I think you pretty much have to assume that, otherwise there's no point
in roaming at all - you want your connections to stay, possibly voice
calls to continue, etc.

> I think it does make sense to tie one into the other.  However, do
> we have a race condition here?  E.g. AUTHORIZED is sent on one
> socket, then OPER_STATE is signaled on rtnl.  Which one do
> applications rely on?

Regular applications wouldn't really look at nl80211.

> > Note that we *can't* do this right now, otherwise we can't transfer
> > the EAPOL frames; but once we do that over nl80211 we'd be able to.

However, I'm not really convinced (any more) that this is actually
correct. If I'm reading the supplicant code correctly, then it sets
IF_OPER_UP only once the connection is *completed*, so it's already
doing what I thought it should be doing and couldn't.

> *wakes up*
> 
> Ah I now seem to remember that I volunteered to look into this before
> my sabbatical :)  I think this was in early June?  I'm certainly
> still interested in doing so.   Let me dust off that portion of my
> brain and come up with a proposal.  Unless you already have a clear
> idea of how things should work?

Not really. I guess a new command/event with the frame, and some flags,
I know that at least we want a "don't encrypt" flag, for example.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

Hi,

> Yep, but I seem to recall there was some vague language that said the
> AP would delete the PMKSA if the client disconnected.

Ok, not sure about that. But even if the AP does, we could try to send
it and it just can't use it :)

> operstates.txt states that for new connections, operstate should be 
> dormant until 802.1x is complete & successful.  So the !eapol-over-
> nl condition would violate that, no?

As I just wrote in my other email, I think I'm totally confused
regarding this, and the supplicant already does it correctly - and you
can ignore the whole "!eapol-over-nl" conditions, and just read it like
what I thought we could only do in the eapol-over-nl case.

No idea how I ended up with the idea that you could only send data
frames when the netdev was IF_OPER_UP - that doesn't seem to have any
basis in reality.

> > > >        - initialize 1X state machines/timeouts
> > > >      - 1X handshake
> > > >      - send PMK to device for 4-way-HS
> > > >      - AUTHORIZED event
> > > >        - [if eapol-over-nl: toggle oper state up]
> > > > 
> 
> Given your explanation above, should this be [if !eapol-over-nl ..?


> So I agree that OPERSTATE_UP should not change on a roam.  I think
> we're both in agreement here.

Great.

> My earlier point is that software roams need to have the exact same 
> behavior as well.  And my understanding is that when we try to 
> Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no longer
> UP.

I'm not sure - I don't know what the state machine in wpa_s goes
through here. Probably easier to test than try to reason about the
code...

> At the very least there's lots of confusion with what is supposed to 
> happen with operstate and when.  So if we can work out & document a 
> consistent behavior, I'm all for it.

:-)

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/14/2017 02:17 PM, Johannes Berg wrote:
> On Thu, 2017-09-14 at 13:37 -0500, Denis Kenzior wrote:
> 
>> The question is whether all APs are actually sane after a
>> roam.  E.g. can the STA assume that the same IP address, DHCP lease,
>> etc is still valid?  I heard from various people that this might not
>> be the case, but we haven't had a chance to verify those claims...
> 
> I think you pretty much have to assume that, otherwise there's no point
> in roaming at all - you want your connections to stay, possibly voice
> calls to continue, etc.

I'm all for using this assumption.  I just wonder if real world 
disagrees? :)

> However, I'm not really convinced (any more) that this is actually
> correct. If I'm reading the supplicant code correctly, then it sets
> IF_OPER_UP only once the connection is *completed*, so it's already
> doing what I thought it should be doing and couldn't.
> 

Yes.  For a new connection it does something like:

New Key
Set Key
New Key (group)
Set Station (Authorized) (which fails on some drivers)
Set OperState to UP

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

>> My earlier point is that software roams need to have the exact same
>> behavior as well.  And my understanding is that when we try to
>> Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no longer
>> UP.
> 
> I'm not sure - I don't know what the state machine in wpa_s goes
> through here. Probably easier to test than try to reason about the
> code...

I'm talking about the kernel behavior, not wpa_s.  My guys discovered 
that the kernel seems to twiddle operstate automagically?  E.g. see 
description of 
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=4d20db05d7c8806749db574e9231bd5d1c476c7f

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 12:34 PM, Denis Kenzior wrote:
> Hi Johannes,
>
> On 09/14/2017 02:17 PM, Johannes Berg wrote:
>> On Thu, 2017-09-14 at 13:37 -0500, Denis Kenzior wrote:
>>
>>> The question is whether all APs are actually sane after a
>>> roam.  E.g. can the STA assume that the same IP address, DHCP lease,
>>> etc is still valid?  I heard from various people that this might not
>>> be the case, but we haven't had a chance to verify those claims...
>>
>> I think you pretty much have to assume that, otherwise there's no point
>> in roaming at all - you want your connections to stay, possibly voice
>> calls to continue, etc.
>
> I'm all for using this assumption.  I just wonder if real world disagrees? :)

There are different meanings for 'roam'.  Are you just talking about
fast-transition roaming?

I would think that the decision to restart DHCP (at least ipv4) should
be in user-space.  I'm less sure about how IPv6 should deal with this.

I have tested roaming using FT and normal-ish wpa_supplicant without
doing DHCP, and it works fine.  Of course, it also works if you
choose to re-do DHCP.

Thanks,
Ben

>
>> However, I'm not really convinced (any more) that this is actually
>> correct. If I'm reading the supplicant code correctly, then it sets
>> IF_OPER_UP only once the connection is *completed*, so it's already
>> doing what I thought it should be doing and couldn't.
>>
>
> Yes.  For a new connection it does something like:
>
> New Key
> Set Key
> New Key (group)
> Set Station (Authorized) (which fails on some drivers)
> Set OperState to UP
>
> Regards,
> -Denis
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 14:34 -0500, Denis Kenzior wrote:

> > I think you pretty much have to assume that, otherwise there's no
> > point
> > in roaming at all - you want your connections to stay, possibly
> > voice
> > calls to continue, etc.
> 
> I'm all for using this assumption.  I just wonder if real world 
> disagrees? :)

I think you can probably find networks where this doesn't work, but I
don't think we should cater for that. And corporate networks done with
Cisco, Aruba or similar should have it work correctly, and in fact I'd
assume that it's pretty much only broken if you take two consumer APs
and configure them to the same SSID or something ...

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 14:37 -0500, Denis Kenzior wrote:

> > > My earlier point is that software roams need to have the exact
> > > same behavior as well.  And my understanding is that when we try
> > > to Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no
> > > longer UP.

> I'm talking about the kernel behavior, not wpa_s.

Oh.

> My guys discovered that the kernel seems to twiddle operstate
> automagically?  E.g. see description of 
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=4d
> 20db05d7c8806749db574e9231bd5d1c476c7f

Well I guess any time that the carrier does in fact go down, you'd also
reset oper state...

And now that I think about it, that does in fact happen in
ieee80211_set_disassoc(), which we even go through for FT roaming.

Sounds like something we should fix?

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 21:41 +0200, Johannes Berg wrote:
> 
> And now that I think about it, that does in fact happen in
> ieee80211_set_disassoc(), which we even go through for FT roaming.
> 
> Sounds like something we should fix?

Not simple though - we'd have to remember to do it later if the
auth/assoc fails or so ...

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

> Well I guess any time that the carrier does in fact go down, you'd also
> reset oper state...
> 
> And now that I think about it, that does in fact happen in
> ieee80211_set_disassoc(), which we even go through for FT roaming.
> 
> Sounds like something we should fix?
> 

If you want roaming to keep oper state UP in all cases, then yes.  Does 
this work on full mac cards as well?

E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue a 
CMD_CONNECT to AP2?

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Ben,
>
> There are different meanings for 'roam'.  Are you just talking about
> fast-transition roaming?
> 

I'm using 'roam' as any transition between BSSes in the same 
SSID/Security type.  So regular re-association, pre-authenticated 
association, fast transition.

> I would think that the decision to restart DHCP (at least ipv4) should
> be in user-space.  I'm less sure about how IPv6 should deal with this.
> 
> I have tested roaming using FT and normal-ish wpa_supplicant without
> doing DHCP, and it works fine.  Of course, it also works if you
> choose to re-do DHCP.
> 

Our thinking on this was to assume that DHCP parameters are still valid 
after a roam, but re-confirm them just in case.  If the confirmation 
fails, then we can fall back to requesting a new DHCP lease.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 01:05 PM, Denis Kenzior wrote:
> Hi Ben,
>>
>> There are different meanings for 'roam'.  Are you just talking about
>> fast-transition roaming?
>>
>
> I'm using 'roam' as any transition between BSSes in the same SSID/Security type.  So regular re-association, pre-authenticated association, fast transition.
>
>> I would think that the decision to restart DHCP (at least ipv4) should
>> be in user-space.  I'm less sure about how IPv6 should deal with this.
>>
>> I have tested roaming using FT and normal-ish wpa_supplicant without
>> doing DHCP, and it works fine.  Of course, it also works if you
>> choose to re-do DHCP.
>>
>
> Our thinking on this was to assume that DHCP parameters are still valid after a roam, but re-confirm them just in case.  If the confirmation fails, then we can
> fall back to requesting a new DHCP lease.

How do you re-confirm them?  There are definitely cases where SSID/Security is the same but each
AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
the same (NAT'd) subnet and with same gateway, likely as not).

Thanks,
Ben

>
> Regards,
> -Denis
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Ben,
> 
> How do you re-confirm them?  There are definitely cases where 
> SSID/Security is the same but each
> AP has its own DHCP server and roaming between them will require getting 
> a new DHCP address (on
> the same (NAT'd) subnet and with same gateway, likely as not).
> 

Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 
equivalent Confirm message.  This obviously requires some integration 
between the dhcp daemon and the supplicant.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 01:26 PM, Denis Kenzior wrote:
> Hi Ben,
>>
>> How do you re-confirm them?  There are definitely cases where SSID/Security is the same but each
>> AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
>> the same (NAT'd) subnet and with same gateway, likely as not).
>>
>
> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 equivalent Confirm message.  This obviously requires some integration between the dhcp daemon and
> the supplicant.

Do you want to allow the just-now-roamed station to use its old IP address(es) while you are
confirming?

If not, how is this different from just re-doing DHCP like normal?

And if so, you will in some cases be allowing duplicate IP addresses on
a network?

Thanks,
Ben

>
> Regards,
> -Denis
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Ben,

On 09/14/2017 03:29 PM, Ben Greear wrote:
> On 09/14/2017 01:26 PM, Denis Kenzior wrote:
>> Hi Ben,
>>>
>>> How do you re-confirm them?  There are definitely cases where 
>>> SSID/Security is the same but each
>>> AP has its own DHCP server and roaming between them will require 
>>> getting a new DHCP address (on
>>> the same (NAT'd) subnet and with same gateway, likely as not).
>>>
>>
>> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 
>> equivalent Confirm message.  This obviously requires some integration 
>> between the dhcp daemon and
>> the supplicant.
> 
> Do you want to allow the just-now-roamed station to use its old IP 
> address(es) while you are
> confirming?

I think it is sane to assume that the IP address _should_ be the same. 
The 802.11 spec expects this even.  This is to handle bizarre networks 
that don't do this properly.

> 
> If not, how is this different from just re-doing DHCP like normal?
> 

You get to use your old IP address.  So e.g. your VoIP call doesn't 
disappear if you decide to switch access points.

> And if so, you will in some cases be allowing duplicate IP addresses on
> a network?
> 

Life is never perfect ;)

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 01:35 PM, Denis Kenzior wrote:
> Hi Ben,
>
> On 09/14/2017 03:29 PM, Ben Greear wrote:
>> On 09/14/2017 01:26 PM, Denis Kenzior wrote:
>>> Hi Ben,
>>>>
>>>> How do you re-confirm them?  There are definitely cases where SSID/Security is the same but each
>>>> AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
>>>> the same (NAT'd) subnet and with same gateway, likely as not).
>>>>
>>>
>>> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 equivalent Confirm message.  This obviously requires some integration between the dhcp daemon and
>>> the supplicant.
>>
>> Do you want to allow the just-now-roamed station to use its old IP address(es) while you are
>> confirming?
>
> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even.  This is to handle bizarre networks that don't do this
> properly.

Can you point me to the section in the spec about this?

>> If not, how is this different from just re-doing DHCP like normal?
>>
>
> You get to use your old IP address.  So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>
>> And if so, you will in some cases be allowing duplicate IP addresses on
>> a network?
>>
>
> Life is never perfect ;)

If you are breaking networks while trying to optimize something, then I think you
are going about it wrong.

Seems like we would need some way for the DHCP server and/or AP to proactively
notify the station that they can skip DHCP, and default to not skipping.

I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
or not, but honestly, it has been a long time since I read through that...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Ben,

>> I think it is sane to assume that the IP address _should_ be the same. 
>> The 802.11 spec expects this even.  This is to handle bizarre networks 
>> that don't do this
>> properly.
> 
> Can you point me to the section in the spec about this?
> 

Lets see, 802.11-2012, Section 4.3.4.2:
"The key concept is that the ESS network appears the same to an LLC 
layer as an IBSS network. STAs within an ESS may communicate and mobile 
STAs may move from one BSS to another (within the same ESS) 
transparently to LLC."

Section 4.5.3.2,

etc.

>>> If not, how is this different from just re-doing DHCP like normal?
>>>
>>
>> You get to use your old IP address.  So e.g. your VoIP call doesn't 
>> disappear if you decide to switch access points.
>>
>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>> a network?
>>>
>>
>> Life is never perfect ;)
> 
> If you are breaking networks while trying to optimize something, then I 
> think you
> are going about it wrong.
> 
> Seems like we would need some way for the DHCP server and/or AP to 
> proactively
> notify the station that they can skip DHCP, and default to not skipping.

Not unless you're planning to extend the spec?  802.11 doesn't even 
mention DHCP in any real manner.

> 
> I vaguely recall that FT had some way to verify you were roaming to the 
> same dhcp-domain
> or not, but honestly, it has been a long time since I read through that...
> 

Do you mean a mobility domain?  This has nothing to do with DHCP...

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 02:35 PM, Denis Kenzior wrote:
> Hi Ben,
>
>>> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even.  This is to handle bizarre networks that don't do this
>>> properly.
>>
>> Can you point me to the section in the spec about this?
>>
>
> Lets see, 802.11-2012, Section 4.3.4.2:
> "The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. STAs within an ESS may communicate and mobile STAs may move from
> one BSS to another (within the same ESS) transparently to LLC."
>
> Section 4.5.3.2,

Thanks for the pointer.

It looks to me like having same SSID/auth is a requirement to be in the same ESS, but
just having the same ESSID/auth does not mean it is definitely in the same ESS.

> etc.
>
>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>
>>>
>>> You get to use your old IP address.  So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>>>
>>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>>> a network?
>>>>
>>>
>>> Life is never perfect ;)
>>
>> If you are breaking networks while trying to optimize something, then I think you
>> are going about it wrong.
>>
>> Seems like we would need some way for the DHCP server and/or AP to proactively
>> notify the station that they can skip DHCP, and default to not skipping.
>
> Not unless you're planning to extend the spec?  802.11 doesn't even mention DHCP in any real manner.

So, it could be given out by the DHCP server then.  There are ways to add custom
options to it, right?

User-space can remember the option and use that to decide whether to re-do DHCP
when a station roams to another AP in (the probable) same ESS.  Since this is
a new option, you should not have backwards-compatibility issues.

>> I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
>> or not, but honestly, it has been a long time since I read through that...
>>
>
> Do you mean a mobility domain?  This has nothing to do with DHCP...

It seems to be a very convenient way to identify a group of APs that share
common infrastructure, more so that just having the same SSID/auth...

Do you think there would ever be a mobility domain that did not share
a common DHCP server pool?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Ben,

On 09/14/2017 05:15 PM, Ben Greear wrote:
> On 09/14/2017 02:35 PM, Denis Kenzior wrote:
>> Hi Ben,
>>
>>>> I think it is sane to assume that the IP address _should_ be the 
>>>> same. The 802.11 spec expects this even.  This is to handle bizarre 
>>>> networks that don't do this
>>>> properly.
>>>
>>> Can you point me to the section in the spec about this?
>>>
>>
>> Lets see, 802.11-2012, Section 4.3.4.2:
>> "The key concept is that the ESS network appears the same to an LLC 
>> layer as an IBSS network. STAs within an ESS may communicate and 
>> mobile STAs may move from
>> one BSS to another (within the same ESS) transparently to LLC."
>>
>> Section 4.5.3.2,
> 
> Thanks for the pointer.
> 
> It looks to me like having same SSID/auth is a requirement to be in the 
> same ESS, but
> just having the same ESSID/auth does not mean it is definitely in the 
> same ESS.
> 

Sure. But then your PSK has to match, or your credentials need to be 
accepted.  I suppose you can have two separate ESSes operating with the 
same SSID and security type.  But man, how likely is that?  That is 
fundamentally broken and we should not slow everything down just to take 
care of a broken case.

>> etc.
>>
>>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>>
>>>>
>>>> You get to use your old IP address.  So e.g. your VoIP call doesn't 
>>>> disappear if you decide to switch access points.
>>>>
>>>>> And if so, you will in some cases be allowing duplicate IP 
>>>>> addresses on
>>>>> a network?
>>>>>
>>>>
>>>> Life is never perfect ;)
>>>
>>> If you are breaking networks while trying to optimize something, then 
>>> I think you
>>> are going about it wrong.
>>>
>>> Seems like we would need some way for the DHCP server and/or AP to 
>>> proactively
>>> notify the station that they can skip DHCP, and default to not skipping.
>>
>> Not unless you're planning to extend the spec?  802.11 doesn't even 
>> mention DHCP in any real manner.
> 
> So, it could be given out by the DHCP server then.  There are ways to 
> add custom
> options to it, right?
> 
> User-space can remember the option and use that to decide whether to 
> re-do DHCP
> when a station roams to another AP in (the probable) same ESS.  Since 
> this is
> a new option, you should not have backwards-compatibility issues.

And now you're breaking layering even more.  DHCP shouldn't care that a 
given client is connecting via ethernet or wifi.  And you're still 
relying on DHCP.

Think about it, with a normal roam, you're probably 40-70 ms latency. 
If you have to do 802.1x, that's probably 150+ms.  With a 
fast-transition you're down to maybe 20 ms?  If you need to rely on 
DHCP, that's 1 second or more.  A user can detect latency of 100ms 
easily.  So if their VoIP call drops for for 1 second or more, you have 
failed.

> 
>>> I vaguely recall that FT had some way to verify you were roaming to 
>>> the same dhcp-domain
>>> or not, but honestly, it has been a long time since I read through 
>>> that...
>>>
>>
>> Do you mean a mobility domain?  This has nothing to do with DHCP...
> 
> It seems to be a very convenient way to identify a group of APs that share
> common infrastructure, more so that just having the same SSID/auth...
> 
> Do you think there would ever be a mobility domain that did not share
> a common DHCP server pool?
> 

I would expect fast transitions to work exactly like any other 
transition within an ESS.  Just faster.  And there's nothing stopping 
one from configuring 2 FT capable ESSes with the same MDID, leading to a 
yet another bizarre case.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Ben Greear]

On 09/14/2017 03:42 PM, Denis Kenzior wrote:
> Hi Ben,
>
> On 09/14/2017 05:15 PM, Ben Greear wrote:
>> On 09/14/2017 02:35 PM, Denis Kenzior wrote:
>>> Hi Ben,
>>>
>>>>> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even.  This is to handle bizarre networks that don't do
>>>>> this
>>>>> properly.
>>>>
>>>> Can you point me to the section in the spec about this?
>>>>
>>>
>>> Lets see, 802.11-2012, Section 4.3.4.2:
>>> "The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. STAs within an ESS may communicate and mobile STAs may move from
>>> one BSS to another (within the same ESS) transparently to LLC."
>>>
>>> Section 4.5.3.2,
>>
>> Thanks for the pointer.
>>
>> It looks to me like having same SSID/auth is a requirement to be in the same ESS, but
>> just having the same ESSID/auth does not mean it is definitely in the same ESS.
>>
>
> Sure. But then your PSK has to match, or your credentials need to be accepted.  I suppose you can have two separate ESSes operating with the same SSID and
> security type.  But man, how likely is that?  That is fundamentally broken and we should not slow everything down just to take care of a broken case.

What about two APs with ssid LEDE and open-auth, each serving DHCP, each
connected to a switch that connects to a cable modem, etc.

>
>>> etc.
>>>
>>>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>>>
>>>>>
>>>>> You get to use your old IP address.  So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>>>>>
>>>>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>>>>> a network?
>>>>>>
>>>>>
>>>>> Life is never perfect ;)
>>>>
>>>> If you are breaking networks while trying to optimize something, then I think you
>>>> are going about it wrong.
>>>>
>>>> Seems like we would need some way for the DHCP server and/or AP to proactively
>>>> notify the station that they can skip DHCP, and default to not skipping.
>>>
>>> Not unless you're planning to extend the spec?  802.11 doesn't even mention DHCP in any real manner.
>>
>> So, it could be given out by the DHCP server then.  There are ways to add custom
>> options to it, right?
>>
>> User-space can remember the option and use that to decide whether to re-do DHCP
>> when a station roams to another AP in (the probable) same ESS.  Since this is
>> a new option, you should not have backwards-compatibility issues.
>
> And now you're breaking layering even more.  DHCP shouldn't care that a given client is connecting via ethernet or wifi.  And you're still relying on DHCP.
>
> Think about it, with a normal roam, you're probably 40-70 ms latency. If you have to do 802.1x, that's probably 150+ms.  With a fast-transition you're down to
> maybe 20 ms?  If you need to rely on DHCP, that's 1 second or more.  A user can detect latency of 100ms easily.  So if their VoIP call drops for for 1 second or
> more, you have failed.

On initial connection to the network, the station does DHCP and gets a response, like normal.
But, that response has a special message in it that says "you don't need to re-do dhcp if you roam here".
User-space remembers this response for future roams...

After that, then you skip DHCP on roam to this SSID/auth network, so you have zero extra network
overhead when roaming.

You could also tell IPv6 to not drop/re-acquite its IP addresses on link-down, and then everything
works w/out having to hack on the mac80211 state, I think?


>>>> I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
>>>> or not, but honestly, it has been a long time since I read through that...
>>>>
>>>
>>> Do you mean a mobility domain?  This has nothing to do with DHCP...
>>
>> It seems to be a very convenient way to identify a group of APs that share
>> common infrastructure, more so that just having the same SSID/auth...
>>
>> Do you think there would ever be a mobility domain that did not share
>> a common DHCP server pool?
>>
>
> I would expect fast transitions to work exactly like any other transition within an ESS.  Just faster.  And there's nothing stopping one from configuring 2 FT
> capable ESSes with the same MDID, leading to a yet another bizarre case.

Well, if we are being very paranoid, then you have to look for some specific and purposeful
identifier, such as the DHCP option I mentioned.  But, I know that at least some larger
entities are (or were a year or two ago) treating a mobility domain roam to mean that DHCP
is not needed on roam.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:

> If you want roaming to keep oper state UP in all cases, then
> yes.  Does this work on full mac cards as well?

I don't see why not.

> E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue
> a CMD_CONNECT to AP2?

That's not something you can do with full-MAC cards?

And even mac80211 doesn't really support pre-authentication (unless you
mean over-the-DS)

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 13:47 -0700, Ben Greear wrote:

> Seems like we would need some way for the DHCP server and/or AP to
> proactively notify the station that they can skip DHCP, and default
> to not skipping.

I really disagree with that - every sane network should behave the
proper way, trying to push workarounds for stupid networks into all
layers of the stack seems like a really bad idea.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 15:57 -0700, Ben Greear wrote:
> 
> What about two APs with ssid LEDE and open-auth, each serving DHCP,
> each connected to a switch that connects to a cable modem, etc.

Take a cluebat to the adminstrator?

It's really simple to disable DHCP on one of them, and if you properly
connect them to the same switch, everything works. I've done that in a
few places (not my own house because a single AP covers it well enough
for me, so ...).

> On initial connection to the network, the station does DHCP and gets
> a response, like normal.
> But, that response has a special message in it that says "you don't
> need to re-do dhcp if you roam here".
> User-space remembers this response for future roams...
> 
> After that, then you skip DHCP on roam to this SSID/auth network, so
> you have zero extra network overhead when roaming.

That will be so much harder to configure.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/15/2017 02:19 AM, Johannes Berg wrote:
> On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:
> 
>> If you want roaming to keep oper state UP in all cases, then
>> yes.  Does this work on full mac cards as well?
> 
> I don't see why not.
> 
>> E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue
>> a CMD_CONNECT to AP2?
> 
> That's not something you can do with full-MAC cards?

Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So we 
should get these just like regular PAE frames.  But forget 
pre-authentication, one can still force a roam between BSSes within the 
same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's what 
the docs say ;)

> 
> And even mac80211 doesn't really support pre-authentication (unless you
> mean over-the-DS)
> 

There's only one kind of preauthentication?  Are you confusing this with 
FT?  We use FT-over-Air just fine on mac80211 and on real hardware.  We 
even have an autotest for this based on mac80211_hwsim.  FT-over-DS 
should work as well.

Full macs don't support FT due to lack of 
CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:

> > > E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
> > > issue a CMD_CONNECT to AP2?
> > 
> > That's not something you can do with full-MAC cards?
> 
> Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So
> we should get these just like regular PAE frames.  But forget 
> pre-authentication, one can still force a roam between BSSes within
> the same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's
> what the docs say ;)

Oh, you meant that kind of pre-authentication :-)

I thought you meant sending an 802.11 auth frame to the new AP before
breaking the connection to the old AP.

> > And even mac80211 doesn't really support pre-authentication (unless
> > you mean over-the-DS)

> 
> There's only one kind of preauthentication? Are you confusing this
> with FT?

No, see above.

> We use FT-over-Air just fine on mac80211 and on real hardware.  We 
> even have an autotest for this based on mac80211_hwsim.  FT-over-DS 
> should work as well.
> 
> Full macs don't support FT due to lack of 
> CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?

Well, with full MAC devices you should let the device decide on the
BSS?

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/15/2017 08:29 AM, Johannes Berg wrote:
> On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:
> 
>>>> E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
>>>> issue a CMD_CONNECT to AP2?
>>>
>>> That's not something you can do with full-MAC cards?
>>
>> Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So
>> we should get these just like regular PAE frames.  But forget
>> pre-authentication, one can still force a roam between BSSes within
>> the same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's
>> what the docs say ;)
> 
> Oh, you meant that kind of pre-authentication :-)
> 
> I thought you meant sending an 802.11 auth frame to the new AP before
> breaking the connection to the old AP.
> 

I mean 802.11-2012 Section 11.5.9.2 type preauthentication.

And AFAIK the kernel generates a disconnected event as soon as we send a 
CMD_AUTHENTICATE, so not sure how you envision 'your' preauthentication 
working...

However, you're not answering my question...

>>> And even mac80211 doesn't really support pre-authentication (unless
>>> you mean over-the-DS)
> 
>>
>> There's only one kind of preauthentication? Are you confusing this
>> with FT?
> 
> No, see above.
> 
>> We use FT-over-Air just fine on mac80211 and on real hardware.  We
>> even have an autotest for this based on mac80211_hwsim.  FT-over-DS
>> should work as well.
>>
>> Full macs don't support FT due to lack of
>> CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?
> 
> Well, with full MAC devices you should let the device decide on the
> BSS?
> 

Why? So we can deal with the various ways a vendor firmware can screw 
up?  Besides, you have an asymmetry in the kernel API.  One can use 
regular roaming on a full mac but not FT.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 08:50 -0500, Denis Kenzior wrote:

> > I thought you meant sending an 802.11 auth frame to the new AP
> > before breaking the connection to the old AP.
> > 
> 
> I mean 802.11-2012 Section 11.5.9.2 type preauthentication.

Yeha, OK.

> And AFAIK the kernel generates a disconnected event as soon as we
> send a CMD_AUTHENTICATE, so not sure how you envision 'your'
> preauthentication working...

That's what I was trying to say - it doesn't. A few years ago we tried
to support that but it's not really possible to do well.

> However, you're not answering my question...

Which was?

> > Well, with full MAC devices you should let the device decide on the
> > BSS?
> > 
> 
> Why? So we can deal with the various ways a vendor firmware can
> screw up?  Besides, you have an asymmetry in the kernel API. 

:)

> One can use regular roaming on a full mac but not FT.

We had intended to have NL80211_CMD_ROAM to make that decision once,
but never really used it for that... I think it could be implemented
but I don't really know how well drivers were to support it.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

>> And AFAIK the kernel generates a disconnected event as soon as we
>> send a CMD_AUTHENTICATE, so not sure how you envision 'your'
>> preauthentication working...
> 
> That's what I was trying to say - it doesn't. A few years ago we tried
> to support that but it's not really possible to do well.

Okay, *now* I'm with you :)

> 
>> However, you're not answering my question...
> 
> Which was?

So if we issue CMD_CONNECT with a PREV_BSSID, does/should OPERSTATE 
still stay UP?

>> One can use regular roaming on a full mac but not FT.
> 
> We had intended to have NL80211_CMD_ROAM to make that decision once,
> but never really used it for that... I think it could be implemented
> but I don't really know how well drivers were to support it.

I think it would be nice.  Worst case a driver won't implement it, but 
we can use FT on those that do.

Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 09:27 -0500, Denis Kenzior wrote:

> > > However, you're not answering my question...
> > 
> > Which was?
> 
> So if we issue CMD_CONNECT with a PREV_BSSID, does/should OPERSTATE 
> still stay UP?

It's difficult to do, but from a higher-layer POV I'd argue that it
should? I'd basically argue that it's no different from 802.1X
reauthentication, and the operstate docs say:

-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
 fails

> > We had intended to have NL80211_CMD_ROAM to make that decision
> > once,
> > but never really used it for that... I think it could be
> > implemented
> > but I don't really know how well drivers were to support it.
> 
> I think it would be nice.  Worst case a driver won't implement it,
> but we can use FT on those that do.

I have no idea how you'd ask them to do FT or just normal reassoc? I
guess they don't really care as long as the supplicant is in the host.

johannes