Hi guys, I was wondering who has done some playing around with CAPSMan so far ?? We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ? Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ? What approach would you take in this situation ? Thanks Paul
I've used CAPsMAN, and while it had some problems in Beta, they were quickly fixed when I reported them. It'll definitely simplify the implementation (configure once, push out to others). The latest versions can automatically adjust the frequency too. I've got a client using a CRS (rack mountable, no wireless) as the CAPsMAN manager, and 4x RB951G-2HnD's connecting to it. I don't know if it'd handle something like VoIP transitioning between APs, but we've tested with streaming video walking around the house, and it worked smoothly. Regards Russell Hurren Managing Director Zero Point Networks PTY LTD +61 8 6262 9376 On 1 July 2014 18:16, Paul Julian <paul@oxygennetworks.com.au> wrote:
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Thanks Russell, I appreciate the feedback, as I said in my reply to Mike I think it's probably worthwhile trying the system but I think I will quote the customer on something which is definitely going to work as a fall-back. Regards Paul -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Russell Hurren Sent: Tuesday, 1 July 2014 8:45 PM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan I've used CAPsMAN, and while it had some problems in Beta, they were quickly fixed when I reported them. It'll definitely simplify the implementation (configure once, push out to others). The latest versions can automatically adjust the frequency too. I've got a client using a CRS (rack mountable, no wireless) as the CAPsMAN manager, and 4x RB951G-2HnD's connecting to it. I don't know if it'd handle something like VoIP transitioning between APs, but we've tested with streaming video walking around the house, and it worked smoothly. Regards Russell Hurren Managing Director Zero Point Networks PTY LTD +61 8 6262 9376 On 1 July 2014 18:16, Paul Julian <paul@oxygennetworks.com.au> wrote:
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly
from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and
Hi Paul, Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do. Unfortunately, smooth transition between APs is not one of the things it is designed for. That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller. Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs. When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-) In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it! Hope this info helps (and not too disappointing! ;-) Cheers! Mike. transition they
seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly
from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and
Hi Mike, really you have answered the question perfectly, thanks. I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair. I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though. At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance. Regards Paul -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan Hi Paul, Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do. Unfortunately, smooth transition between APs is not one of the things it is designed for. That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller. Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs. When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-) In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it! Hope this info helps (and not too disappointing! ;-) Cheers! Mike. transition they
seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly
from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and
Paul Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective. Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan Hi Mike, really you have answered the question perfectly, thanks. I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair. I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though. At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance. Regards Paul -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan Hi Paul, Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do. Unfortunately, smooth transition between APs is not one of the things it is designed for. That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller. Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs. When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-) In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it! Hope this info helps (and not too disappointing! ;-) Cheers! Mike. transition they
seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by
Hi Paul, Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution. I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out. Cheers! Mike. this
email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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
_______________________________________________ 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
To be fair "roaming" between AP's with the same SSID and security options is supposed to be a fundimental part of the 802.11 protocol however at times it depends on the clients device/drivers/feature support as to how well this works. In the case of 802.1X WPA authentication types; most of the wireless controller managed solutions can cache responses to provide speedy roaming between AP's (I know Ruckus does this) so clients can roam without having to refer back to the RADIUS at each jump. Without this roaming can still occur but is delayed by the RADIUS response times. The next standard in plays was 802.11r <http://www.codealias.info/technotes/the_ieee_802.11r_standard_for_fast_wireless_handoffs> which specified methods for fast and secure roaming by changing the key negotiation protocol (once again you now much have a driver that implements and supports this for it to work for you though) allowing part of the key to be cached in the wireless network. Without this the client must completely reauth each time it roams (which is where the Ruckus Zonedirector caching comes in handy at speeding this up). The third solution to this is Dynamic PSK's. Using 802.1x security + a dynamically generated passphrase for each client that is generated after initial authentication vs the 802.1X system (be that RADIUS, LDAP, AD etc). This key can then remain valid so long as needed or invalidated as soon as the users access is revoked. There's a similar Aerohive function known as "Private PSK" that opts to shift clients to a "dynamically generated" PSK for clients incapable of performing 802.1X authentication. TLDR: There are existing standards for roaming between AP's but not all of them are equal and many of them aren't as seamless as you would expect. Hopefully this bit of homework has been enlightening to some :-) - Andrew On 2 July 2014 09:48, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution.
I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out.
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
I think the issue with roaming is the association between the client and the AP, and the association of the MAC address, and DHCP. I cant remember the specific details, but remember that much of it from the Cisco wireless training. Also as of the open-mesh firmware 481, it now supports roaming. Here is what I read on their help centre (but would much rather use Mikrotik!): " All Open-Mesh access points running 481 or later firmware have seamless roaming capabilities, even on networks with multiple gateways." Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox Sent: Wednesday, 2 July 2014 11:26 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan To be fair "roaming" between AP's with the same SSID and security options is supposed to be a fundimental part of the 802.11 protocol however at times it depends on the clients device/drivers/feature support as to how well this works. In the case of 802.1X WPA authentication types; most of the wireless controller managed solutions can cache responses to provide speedy roaming between AP's (I know Ruckus does this) so clients can roam without having to refer back to the RADIUS at each jump. Without this roaming can still occur but is delayed by the RADIUS response times. The next standard in plays was 802.11r <http://www.codealias.info/technotes/the_ieee_802.11r_standard_for_fast_wireless_handoffs> which specified methods for fast and secure roaming by changing the key negotiation protocol (once again you now much have a driver that implements and supports this for it to work for you though) allowing part of the key to be cached in the wireless network. Without this the client must completely reauth each time it roams (which is where the Ruckus Zonedirector caching comes in handy at speeding this up). The third solution to this is Dynamic PSK's. Using 802.1x security + a dynamically generated passphrase for each client that is generated after initial authentication vs the 802.1X system (be that RADIUS, LDAP, AD etc). This key can then remain valid so long as needed or invalidated as soon as the users access is revoked. There's a similar Aerohive function known as "Private PSK" that opts to shift clients to a "dynamically generated" PSK for clients incapable of performing 802.1X authentication. TLDR: There are existing standards for roaming between AP's but not all of them are equal and many of them aren't as seamless as you would expect. Hopefully this bit of homework has been enlightening to some :-) - Andrew On 2 July 2014 09:48, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution.
I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out.
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ 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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 11:51 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
I think the issue with roaming is the association between the client and
and the association of the MAC address, and DHCP. I cant remember the specific details, but remember that much of it from the Cisco wireless
Hi, The issue with roaming is all about the client side. Since 802.11 was originally designed as an autonomous system, there are no inherent control of the client available to the AP. Therefore any functionality affecting the behaviour of wireless clients can only be implemented as a kind of fudge. Some clients will roam neatly and effectively via clever coding of the step-up/down mechanism. 'hardware retry' is a required part of the 802.11 family specifications - when the retry count is reached, client is supposed to 'retrain' with the AP and select an appropriate data rate. Similarly, long duration error-free operation will allow the re-training to try stepping up the data rate. This allows the client to deal with irregular signal strength, or changing signal as the distance between AP and client changes. Some wireless clients are smart, and during that re-training process they will also attempt to detect other APs with same ssid that may have a better signal - if it does, then it will switch to the 'optimum' AP. Most wireless clients do not do it. Some are particularly bad (I'm talking about YOU mr. iPhone) in that they will insist on staying connected to the first AP found even if the signal level is crap, and there is a 'full 5 bars' AP right next to it! :-D To deal with that bad behaviour, the ideal fudge is to make the mac address of an AP portable. After all, it is the AP mac address that determines which AP accepts a packet transmitted on the network, so the trick is to manage the APs so that you can select which one accepts the packets from a particular client. Moving a wireless registration entry from one AP to another will achieve that kind of outcome, and is best achieved via some kind of central controller type solution. The alternative is to /force/ the client to find an alternative AP by simply refusing to accept a connection when the signal is below some level defined. Once again, there are good clients and bad clients when it comes to that kind of thing (my windows tablet is quite good at this, my iPhone is abysmal). Well behaved clients quickly figure out that the 'current' base station is no longer accepting connections and switch to another one in 1 or 2 seconds. Others will take ages - my iPhone sometimes takes up more than 10 seconds to work. MikroTik CAPsMAN already has the ability to forward all wireless packets to the controller for forwarding by the local bridge on the controller (see http://wiki.mikrotik.com/wiki/Manual:CAPsMAN#Datapath_Configuration ) and I suspect that this feature will eventually become the means to deal with hand-offs since this mechanism allows the client registration to be exposed direct to the CAPs manager. Out of interest, I have again asked my MT contact point whether there is any progress on this feature. I'll report back here if I get any comment that I am allowed to repeat :-) Cheers, Mike. the AP, training.
Also as of the open-mesh firmware 481, it now supports roaming. Here is
I read on their help centre (but would much rather use Mikrotik!):
" All Open-Mesh access points running 481 or later firmware have seamless roaming capabilities, even on networks with multiple gateways."
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by
email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox Sent: Wednesday, 2 July 2014 11:26 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
To be fair "roaming" between AP's with the same SSID and security options is supposed to be a fundimental part of the 802.11 protocol however at times it depends on the clients device/drivers/feature support as to how well this works. In the case of 802.1X WPA authentication types; most of the wireless controller managed solutions can cache responses to provide speedy roaming between AP's (I know Ruckus does this) so clients can roam without having to refer back to the RADIUS at each jump. Without this roaming can still occur but is delayed by the RADIUS response times.
The next standard in plays was 802.11r <http://www.codealias.info/technotes/the_ieee_802.11r_standard_for_fast_wi reless_handoffs> which specified methods for fast and secure roaming by changing the key negotiation protocol (once again you now much have a driver that implements and supports this for it to work for you though) allowing part of the key to be cached in the wireless network. Without this the client must completely reauth each time it roams (which is where the Ruckus Zonedirector caching comes in handy at speeding this up).
The third solution to this is Dynamic PSK's. Using 802.1x security + a dynamically generated passphrase for each client that is generated after initial authentication vs the 802.1X system (be that RADIUS, LDAP, AD etc). This key can then remain valid so long as needed or invalidated as soon as
what this the
users access is revoked. There's a similar Aerohive function known as "Private PSK" that opts to shift clients to a "dynamically generated" PSK for clients incapable of performing 802.1X authentication.
TLDR: There are existing standards for roaming between AP's but not all of them are equal and many of them aren't as seamless as you would expect.
Hopefully this bit of homework has been enlightening to some :-)
- Andrew
On 2 July 2014 09:48, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution.
I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out.
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ 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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 11:51 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
I think the issue with roaming is the association between the client and
and the association of the MAC address, and DHCP. I cant remember the specific details, but remember that much of it from the Cisco wireless
Mike Thanks for that very informative insight. Would this allow for a zero packet loss scenario where a VoIP handset can move from one AP to another without dropping the call? Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Wednesday, 2 July 2014 12:30 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan Hi, The issue with roaming is all about the client side. Since 802.11 was originally designed as an autonomous system, there are no inherent control of the client available to the AP. Therefore any functionality affecting the behaviour of wireless clients can only be implemented as a kind of fudge. Some clients will roam neatly and effectively via clever coding of the step-up/down mechanism. 'hardware retry' is a required part of the 802.11 family specifications - when the retry count is reached, client is supposed to 'retrain' with the AP and select an appropriate data rate. Similarly, long duration error-free operation will allow the re-training to try stepping up the data rate. This allows the client to deal with irregular signal strength, or changing signal as the distance between AP and client changes. Some wireless clients are smart, and during that re-training process they will also attempt to detect other APs with same ssid that may have a better signal - if it does, then it will switch to the 'optimum' AP. Most wireless clients do not do it. Some are particularly bad (I'm talking about YOU mr. iPhone) in that they will insist on staying connected to the first AP found even if the signal level is crap, and there is a 'full 5 bars' AP right next to it! :-D To deal with that bad behaviour, the ideal fudge is to make the mac address of an AP portable. After all, it is the AP mac address that determines which AP accepts a packet transmitted on the network, so the trick is to manage the APs so that you can select which one accepts the packets from a particular client. Moving a wireless registration entry from one AP to another will achieve that kind of outcome, and is best achieved via some kind of central controller type solution. The alternative is to /force/ the client to find an alternative AP by simply refusing to accept a connection when the signal is below some level defined. Once again, there are good clients and bad clients when it comes to that kind of thing (my windows tablet is quite good at this, my iPhone is abysmal). Well behaved clients quickly figure out that the 'current' base station is no longer accepting connections and switch to another one in 1 or 2 seconds. Others will take ages - my iPhone sometimes takes up more than 10 seconds to work. MikroTik CAPsMAN already has the ability to forward all wireless packets to the controller for forwarding by the local bridge on the controller (see http://wiki.mikrotik.com/wiki/Manual:CAPsMAN#Datapath_Configuration ) and I suspect that this feature will eventually become the means to deal with hand-offs since this mechanism allows the client registration to be exposed direct to the CAPs manager. Out of interest, I have again asked my MT contact point whether there is any progress on this feature. I'll report back here if I get any comment that I am allowed to repeat :-) Cheers, Mike. the AP, training.
Also as of the open-mesh firmware 481, it now supports roaming. Here is
I read on their help centre (but would much rather use Mikrotik!):
" All Open-Mesh access points running 481 or later firmware have seamless roaming capabilities, even on networks with multiple gateways."
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by
email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox Sent: Wednesday, 2 July 2014 11:26 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
To be fair "roaming" between AP's with the same SSID and security options is supposed to be a fundimental part of the 802.11 protocol however at times it depends on the clients device/drivers/feature support as to how well this works. In the case of 802.1X WPA authentication types; most of the wireless controller managed solutions can cache responses to provide speedy roaming between AP's (I know Ruckus does this) so clients can roam without having to refer back to the RADIUS at each jump. Without this roaming can still occur but is delayed by the RADIUS response times.
The next standard in plays was 802.11r <http://www.codealias.info/technotes/the_ieee_802.11r_standard_for_fas t_wi reless_handoffs> which specified methods for fast and secure roaming by changing the key negotiation protocol (once again you now much have a driver that implements and supports this for it to work for you though) allowing part of the key to be cached in the wireless network. Without this the client must completely reauth each time it roams (which is where the Ruckus Zonedirector caching comes in handy at speeding this up).
The third solution to this is Dynamic PSK's. Using 802.1x security + a dynamically generated passphrase for each client that is generated after initial authentication vs the 802.1X system (be that RADIUS, LDAP, AD etc). This key can then remain valid so long as needed or invalidated as soon as
what this the
users access is revoked. There's a similar Aerohive function known as "Private PSK" that opts to shift clients to a "dynamically generated" PSK for clients incapable of performing 802.1X authentication.
TLDR: There are existing standards for roaming between AP's but not all of them are equal and many of them aren't as seamless as you would expect.
Hopefully this bit of homework has been enlightening to some :-)
- Andrew
On 2 July 2014 09:48, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution.
I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out.
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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. co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik. co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik. co m.au
_______________________________________________ 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
_______________________________________________ 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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 2:43 PM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Mike
Thanks for that very informative insight. Would this allow for a zero
scenario where a VoIP handset can move from one AP to another without dropping the call?
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by
email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Wednesday, 2 July 2014 12:30 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi,
The issue with roaming is all about the client side. Since 802.11 was originally designed as an autonomous system, there are no inherent control of the client available to the AP. Therefore any functionality affecting the behaviour of wireless clients can only be implemented as a kind of fudge.
Some clients will roam neatly and effectively via clever coding of the step- up/down mechanism. 'hardware retry' is a required part of the 802.11 family specifications - when the retry count is reached, client is supposed to 'retrain' with the AP and select an appropriate data rate. Similarly, long duration error- free operation will allow the re-training to try stepping up the data rate. This allows the client to deal with irregular signal strength, or changing signal as the distance between AP and client changes.
Some wireless clients are smart, and during that re-training process they will also attempt to detect other APs with same ssid that may have a better signal - if it does, then it will switch to the 'optimum' AP. Most wireless clients do not do it. Some are particularly bad (I'm talking about YOU mr. iPhone) in that they will insist on staying connected to the first AP found even if the signal level is crap, and there is a 'full 5 bars' AP right next to it! :-D
To deal with that bad behaviour, the ideal fudge is to make the mac address of an AP portable. After all, it is the AP mac address that determines which AP accepts a packet transmitted on the network, so the trick is to manage the APs so that you can select which one accepts the packets from a particular client. Moving a wireless registration entry from one AP to another will achieve
kind of outcome, and is best achieved via some kind of central controller type solution.
The alternative is to /force/ the client to find an alternative AP by simply refusing to accept a connection when the signal is below some level defined. Once again, there are good clients and bad clients when it comes to that kind of thing (my windows tablet is quite good at this, my iPhone is abysmal). Well behaved clients quickly figure out that the 'current' base station is no longer accepting connections and switch to another one in 1 or 2 seconds. Others will take ages - my iPhone sometimes takes up more than 10 seconds to work.
MikroTik CAPsMAN already has the ability to forward all wireless packets to the controller for forwarding by the local bridge on the controller (see http://wiki.mikrotik.com/wiki/Manual:CAPsMAN#Datapath_Configuration ) and I suspect that this feature will eventually become the means to deal with hand- offs since this mechanism allows the client registration to be exposed
Hi Paul, Yes - that's the idea! :-) At the moment, because we need to wait for the client to play ball, time can be way too long for interactive traffic like voice. Once we can automate passing of control from one AP to another, then it is just a matter of sending instruction to the right access point to take over the communications. From perspective of the client, he doesn't care WHERE the transmission is coming from, only that it is loud and clear ;-) Cheers, Mike. packet loss this that direct to
the CAPs manager.
Out of interest, I have again asked my MT contact point whether there is any progress on this feature. I'll report back here if I get any comment that I am allowed to repeat :-)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 11:51 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
I think the issue with roaming is the association between the client and the AP, and the association of the MAC address, and DHCP. I cant remember the specific details, but remember that much of it from the Cisco wireless training.
Also as of the open-mesh firmware 481, it now supports roaming. Here is what I read on their help centre (but would much rather use Mikrotik!):
" All Open-Mesh access points running 481 or later firmware have seamless roaming capabilities, even on networks with multiple gateways."
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox Sent: Wednesday, 2 July 2014 11:26 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
To be fair "roaming" between AP's with the same SSID and security options is supposed to be a fundimental part of the 802.11 protocol however at times it depends on the clients device/drivers/feature support as to how well this works. In the case of 802.1X WPA authentication types; most of the wireless controller managed solutions can cache responses to provide speedy roaming between AP's (I know Ruckus does this) so clients can roam without having to refer back to the RADIUS at each jump. Without this roaming can still occur but is delayed by the RADIUS response times.
The next standard in plays was 802.11r <http://www.codealias.info/technotes/the_ieee_802.11r_standard_for_fas t_wi reless_handoffs> which specified methods for fast and secure roaming by changing the key negotiation protocol (once again you now much have a driver that implements and supports this for it to work for you though) allowing part of the key to be cached in the wireless network. Without this the client must completely reauth each time it roams (which is where the Ruckus Zonedirector caching comes in handy at speeding this up).
The third solution to this is Dynamic PSK's. Using 802.1x security + a dynamically generated passphrase for each client that is generated after initial authentication vs the 802.1X system (be that RADIUS, LDAP, AD etc). This key can then remain valid so long as needed or invalidated as soon as the users access is revoked. There's a similar Aerohive function known as "Private PSK" that opts to shift clients to a "dynamically generated" PSK for clients incapable of performing 802.1X authentication.
TLDR: There are existing standards for roaming between AP's but not all of them are equal and many of them aren't as seamless as you would expect.
Hopefully this bit of homework has been enlightening to some :-)
- Andrew
On 2 July 2014 09:48, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
Openmesh apparently does not (and doesn't claim to) feature seamless hand-off between devices. It is simply an optimised WDS bridge solution similar to mikrotik 'dynamic mesh' solution.
I don't make comment on whether it is good or bad (I have heard some good things about it ;) but thought it worth pointing out.
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Azad Sent: Wednesday, 2 July 2014 9:04 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] CAPSMan
Paul
Until Mikrotik can offer this, you can try using the open-mesh APs, they have seamless handoff. They very cost effective.
Paul Azad Enterprise Architect m: 0425 727 768 p: 03 8689 9711 f: 03 9018 8022 e: paul@thissolution.com
This Solution P/L Disclaimer The information contained in this e-mail is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this e-mail is unauthorised and strictly prohibited. If you received this e-mail in error, please promptly inform us by reply e-mail or telephone. You should also delete and destroy any hard copies produced. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 10:38 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Mike, really you have answered the question perfectly, thanks.
I really need that seamless handoff and I am a bit surprised that something referred to as a wireless controller cannot help with this, other wireless controllers seem to do that and the config for multiple AP's as standard fair.
I was thinking about access lists but the environment is going to be reasonably compact but with quite a few obstructions as it's in a warehouse so I really need the signal penetration due to rows of pallet racking, maybe I might have to go with the Ruckess stuff this time and hope that the CAPSMan system improves quickly, I was hoping to be able to use the cost effective option from Mikrotik though, perhaps it's worth a try with the access lists and see what happens though.
At this stage I really need to quote the customer so might just quote the expensive stuff and try the Mikrotik stuff first and then fallback to the Ruckess if I can't get the Mikrotik to go the distance.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 1 July 2014 9:09 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CAPSMan
Hi Paul,
Like Russell already said, CAPsMAN works quite well for jobs that it is designed to do.
Unfortunately, smooth transition between APs is not one of the things it is designed for.
That was a surprise for me when I played around with the original release, because it was my assumption that this was precisely one of the reasons we need a wireless controller.
Instead, what it does do (and does it well) is to offer a single interface for management of many wireless APs. CAPS manager can be on one of the APs or even on a router with no wireless. On the manager, it is possible to create 'configuration sets' where a set is made up of wireless properties (channel, protocol, etc) security profiles, and access/connection lists. You then assign the configuration set to one or more 'slave' APs, and then when you change the config on the master, it automatically updates the assigned slaves. This is great for maintaining wireless passwords for multiple APs or rolling out a new mac address to access lists throughout a group of APs.
When I discovered that there was no function for hand-off between APs, I immediately asked MT direct. The reply I got was that this is functionally 'planned for future release' of CAPsMAN - but as per usual MT style, there is no estimated approximated or rumoured release date ;-)
In the meantime, the most effective way I have found to deal with roaming client is to use 'access list' to set a minimum signal required to connect to the AP. What this does is to refuse connection from clients that are too far away (say -70dBm) and force the client to find a closer AP to connect to. You don't need CAPsMAN to do that, but when there are lots of APs, and you want to adjust those signal limits from time to time, CAPsMAN is very handy tool to do it!
Hope this info helps (and not too disappointing! ;-)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Tuesday, 1 July 2014 8:16 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] CAPSMan
Hi guys, I was wondering who has done some playing around with CAPSMan so far ??
We have a wireless network we need to build for a customer but they need a couple of AP's on the same SSID in reasonably close proximity which means they will interfere with each other. I was wondering, with the limited amount I have researched this new component, will it help in this situation and allow users to smoothly transition from one AP to another ?
Previously we have worked with Ruckess wireless AP's and controllers and they seem to handle having AP's close to each other without any issues for users roaming, will CAPSMan help in situations like this as well ?
What approach would you take in this situation ?
Thanks Paul _______________________________________________ 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. co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik. co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik. co m.au
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (5)
-
Andrew Cox -
Mike Everest -
Paul Azad -
Paul Julian -
Russell Hurren