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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
