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
-- --