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