janisk - yes in my case I am talking about several different hotspot interfaces (attached to different vlans)
I have an open support ticket on this with sergejs at the moment - 2009030566000104
What are the current numbers being seen as maximum concurrent connections capacity for MT acting as Hotspot alone (no OSPF, no BGP, no wireless cards, no PPPoE server) ?
We are considering both dual-core Xeon PC and RB-1000 for the task, but whas hoping to achieve two/five/ten thousand connections.
What version is more stable for only running Hotspot with MAC-based provisioning, i.e., customer MAC address is used as RADIUS login instead of presenting a web page ?
You can see connections in the webproxy’s connections tab when the hotspot is enabled regardless of if the proxy is turned on or off.
Anyone got updates from MT on this?
I suspect that it is still using the same single instance of Squid as a proxy, just not the same ports. I.e. the hotspot and “your” proxy that “you” can control are actually two separate proxy servers shared by the same engine. Not very well explained, but hopefully you’ll understand! That is why when you try to configure the hotspot proxy, you can’t. You can only configure “your own” one. However as they share the same engine, you see the data packets incrementing etc. as Mikrotik didn’t stop the screen from seeing the hotspot proxy. Maybe because to separate the logging of the data into two would have meant even more work. May have even been impossible?
I understand, either way its handy to have there as it’s a good indication for when the hotspot server proxy does crash (you’ll see hundreds of connections all with transfer amounts under 1kb)
Well I have always had problems here and there using the DNS name. Since the problems I never have re-enabled it and all went well. One of the biggest problems that I had in the past was with the hotspot DNS name ending in local. Like this: hotspot.desertgate.local .. This did not work and I lost 26 hours plus of sleep until I changed that local ending to a .com or something else. Then everything had cleared up. Now-a-days I do not have a fancy DNS entry name on my hotspots and they seem to work fine if not better with not compatibility issues at all.
the problem with not using a dns name is that you can’t then use a valid SSL cert for your login page.. not a good idea allowing unencrypted logins if you’re running a wireless hotspot.
True but my point was more that you can not use the dns name ending in .local ( a none encrypted splash page.) Not sure if this is a bug or not. I do agree that all auth pages must be encrypted.
If you use an unencrypted login page, the username and password is still encrypted and passed from the client to the hotspot encrypted with MD5.
I appreciate a MD5 password can be brute forced, but the point I am making is that the login traffic itself IS encrypted and not sent in the clear. Unlike the login page itself. Therefore you can use internal DNS names “if you want to” and you will still have a secure login.
I agree that best practise is to use a fully SSL encrypted page and then of course you are quite correct that you can’t use an internal DNS name if you want the Certificate to be automatically trusted by the client web browser. Self-signed certificates now create headaches for clients as they don’t understand all the ‘nasty’ warning messages from their browser, especially since Firefox 3.x. They are easily confused and instead of reading and following the click-by-click instructions, they just panic and disconnect from the hotspot.