Hi Mike, It must be a device operating system issue where the Wifi driver signals a link break of some kind to the TCPIP stack. One thing I have wondered but don't know the answer to, if a client switches AP's even on the same SSID is a DHCP request made at re-connection? I suppose the answer is yes - the client would reset all IP connections as the network settings *may* change with a new DHCP request. This is how a trick like keeping the AP MAC the same as a client roams would stop devices closing their connections as no new DHCP request is made. One thing to try would be to run OpenVPN on the sensitive clients. My limited experience in the past shows you can break and make your ethernet or ADSL connection and OpenVPN will resume any connections it's encapsulating like nothing happened. So, OpenVPN client paired with a Mikrotik OpenVPN server and set as the default route would ensure a client like Facetime or SIP VoIP would still keep running as the hullabaloo of switching AP's would be abstracted away from the client application and it won't drop the connection. Jason On 20 July 2015 at 00:40, Mike Everest <mike@duxtel.com> wrote:
Hi Jason!
Unfortunately, what you are seeing is the transport layer timing out the connection before the wifi has managed to re-negotiate the link. Since this is a client behaviour setting, there is nothing that can be done about it at the network infrastructure end, only at the client side AND server side. It may be possible to get some relief from this problem by increasing tcp time-out on the client - e.g:
https://www.google.com.au/?q=tcp%20increase%20timeout
Since either client or server can potentially time-out the session, even a change to client time-out may not help at all if the server is the end responsible for terminating the connection :-/
I had some correspondence with MikroTik software development team about CAPsMAN system before it was released, and there was some indication there about implementing some kind of managed hand-off between managed devices. That kind of feature will allow the target AP to take control of the session by masquerading the MAC address of the original AP which should result in a truly seamless roaming experience similar to the 3G/lte behaviour.
There has been no official work of potential release of such that I am aware of, so when (or IF) this will be released is a matter of pure speculation :-}
Cheers, Mike.
---------------------------------------------------------------------------- -------- Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel
---------------------------------------------------------------------------- -------- Follow our tweets for news and updates: http://twitter.com/duxtel
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Jason Hecker (Up & Running Tech) Sent: Saturday, 18 July 2015 9:12 AM To: MikroTik Australia Public List Subject: [MT-AU Public] Seamless roaming
I have here at home two Mikrotik devices set up with WIFI.
Each has: * The same SSID. * RSTP bridging with WIFI andf Eth as members. * Access list with the cutoff signal below -80.
The access list works well and it's easy to see the devices hop from one access point to the other instead of the device holding with a vice grip to the original but very weaker signal which is what would normally happen.
The issue is that Facetime drops when this access point transition occurs.
On client sites with multiple radios I haven't used something like Facetime to check signal transitions rather just wandered about with the laptop reloading web pages or playing Youtube videos with no discernible problems.
Is there anything I can do to mitigate the fickleness of Facetime and presumably other real time applications like Skype and SIP VoIP when switching access points?
Jason _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- --
That wouldn't be surprising - safari knows when the system connectivity comes up and will retry failed page loads automatically. James On Mon, 20 Jul 2015, at 06:58, Jason Hecker (Up & Running Tech) wrote:
Hi Mike,
It must be a device operating system issue where the Wifi driver signals a link break of some kind to the TCPIP stack.
One thing I have wondered but don't know the answer to, if a client switches AP's even on the same SSID is a DHCP request made at re-connection? I suppose the answer is yes - the client would reset all IP connections as the network settings *may* change with a new DHCP request. This is how a trick like keeping the AP MAC the same as a client roams would stop devices closing their connections as no new DHCP request is made.
One thing to try would be to run OpenVPN on the sensitive clients. My limited experience in the past shows you can break and make your ethernet or ADSL connection and OpenVPN will resume any connections it's encapsulating like nothing happened. So, OpenVPN client paired with a Mikrotik OpenVPN server and set as the default route would ensure a client like Facetime or SIP VoIP would still keep running as the hullabaloo of switching AP's would be abstracted away from the client application and it won't drop the connection.
Jason
On 20 July 2015 at 00:40, Mike Everest <mike@duxtel.com> wrote:
Hi Jason!
Unfortunately, what you are seeing is the transport layer timing out the connection before the wifi has managed to re-negotiate the link. Since this is a client behaviour setting, there is nothing that can be done about it at the network infrastructure end, only at the client side AND server side. It may be possible to get some relief from this problem by increasing tcp time-out on the client - e.g:
https://www.google.com.au/?q=tcp%20increase%20timeout
Since either client or server can potentially time-out the session, even a change to client time-out may not help at all if the server is the end responsible for terminating the connection :-/
I had some correspondence with MikroTik software development team about CAPsMAN system before it was released, and there was some indication there about implementing some kind of managed hand-off between managed devices. That kind of feature will allow the target AP to take control of the session by masquerading the MAC address of the original AP which should result in a truly seamless roaming experience similar to the 3G/lte behaviour.
There has been no official work of potential release of such that I am aware of, so when (or IF) this will be released is a matter of pure speculation :-}
Cheers, Mike.
---------------------------------------------------------------------------- -------- Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel
---------------------------------------------------------------------------- -------- Follow our tweets for news and updates: http://twitter.com/duxtel
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Jason Hecker (Up & Running Tech) Sent: Saturday, 18 July 2015 9:12 AM To: MikroTik Australia Public List Subject: [MT-AU Public] Seamless roaming
I have here at home two Mikrotik devices set up with WIFI.
Each has: * The same SSID. * RSTP bridging with WIFI andf Eth as members. * Access list with the cutoff signal below -80.
The access list works well and it's easy to see the devices hop from one access point to the other instead of the device holding with a vice grip to the original but very weaker signal which is what would normally happen.
The issue is that Facetime drops when this access point transition occurs.
On client sites with multiple radios I haven't used something like Facetime to check signal transitions rather just wandered about with the laptop reloading web pages or playing Youtube videos with no discernible problems.
Is there anything I can do to mitigate the fickleness of Facetime and presumably other real time applications like Skype and SIP VoIP when switching access points?
Jason _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
--
-- _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
It must be a device operating system issue where the Wifi driver signals a
Hi Jason, link
break of some kind to the TCPIP stack.
One thing I have wondered but don't know the answer to, if a client switches AP's even on the same SSID is a DHCP request made at re-connection? I suppose the answer is yes - the client would reset all IP connections as
Yes, quite probably - I have seen it happen relatively often that an application times out just as soon as a link goes off. Maybe it is a sensible thing for the OS to do from a general case perspective, but it doesn't help at all in context of wifi roaming behaviour ;) the
network settings *may* change with a new DHCP request.
Same deal, I think. If wireless networking stack considers re-training wifi connection to be same as interface-down - interface-up then DHCP lease WILL be renewed also. Maybe there might be some wifi adapter driver configuration options that can affect the way that works?
This is how a trick like keeping the AP MAC the same as a client roams would stop devices closing their connections as no new DHCP request is made.
Yes - the way I figure it, the gist of this scheme would be to implement some kind of mac-address lookup table on the AP that translates the source MAC value on outgoing packets, and dst-nats received packets to the real address. At the same time, I guess, the AP that really DOES have the destination mac address would need to filter out packets from that client. Although it is a realtively simple thing to do (I am sure it could already be done on a static/manual level using existing bridge filter feature of routerOS) I imagine that it would be far from trivial matter to actually implement on software ;)
One thing to try would be to run OpenVPN on the sensitive clients. My limited experience in the past shows you can break and make your ethernet or ADSL connection and OpenVPN will resume any connections it's encapsulating like nothing happened. So, OpenVPN client paired with a Mikrotik OpenVPN server and set as the default route would ensure a client like Facetime or SIP VoIP would still keep running as the hullabaloo of switching AP's would be abstracted away from the client application and it won't drop the connection.
Interesting idea - please report back once you've got it tested! :-D Cheers, Mike.
participants (3)
-
James Hodgkinson -
Jason Hecker (Up & Running Tech) -
Mike Everest