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
