Are other people still having problems with this? Has any reliable workaround surfaced?

This is meant to be a sort of survey, so even if you have no info to offer, just reply saying yes or no.

No problem here. But that is vague. Are you having a problem?
ROS V3.11 with the transparent proxy disabled seems to be working.

ADD: I had a challenge with the redirect when I set the hotspot dns name in the setup, then connected the box to the internet and a couple of "real" dns servers. If that hotspot dns name is not a valid url, the redirect will fail.

We have a 'splash' page served directly from the router that then redirects to our web server. It'll work fine for a while, and then just stop redirecting un-auth'd users to that splash page. My understanding is the transparent-proxy option applies to authenticated users; this problem occurs with un-auth'd users.

When it happens, un-auth'd users get either a general could-not-connect error in their browser, or an MT proxy error (the one that says 'your cache administrator is...'). Reboots fix the latter (proxy error) issue. In the former case, though, even a reboot doesn't fix things. I've tried using the default hotspot as well, with no customization, to rule out some sort of bad config in our stuff, but even that eventually fails.

That transparent proxy fault applies to all users. It cut off my un-authed users from connecting to Authorize.Net (walled garden) to pay me so they could get authed. That is very, very bad!

ADD: Here was the really bad part. It takes a day or two before it starts to fail. But when it does, it is GONE!! And that will be Friday afternoon...

I already have transparent-proxy disabled, btw.

I thought about the hotspot dns-name, too. But why would it work for a while, and then stop? The static entry is in the router's dns cache, and the dynamic nat/fw rules are supposed to redirect un'auth'd dns requests to the hotspot.

I am not certain in your case, but in mine, setting the hotspot-dns-name="" resolved the issue for me. This unblocked the login page failure, but not the walled garden fault.

So whats really going on here ?
We run multiple hotspot sites with exactly the same config on each, excepting some basic text for webpage titles and stuff, and redirect all hotspot logins to our webservers.
We are currently running ROS3.11 on routerboard 433's.

All of sudden with no changes one system has failed to redirect and gives the use a proxy error.

We don't have proxy enabled, or transparent proxy enabled on any sites, and never have, how can the user get a damn proxy error when the proxy is not even turned on ??

I have rebooted this unit multiple times to no avail, come on Mikrotik, we are running businesses from your equipment not toys, these problems just shouldn't happen.

Has anybody got any suggestions on a workaround besides disabling the hotspot function and giving users unauthorised access ?

Regards
Paul

Same problem with failure to redirect to hotspot and cache administrator error messages. After three days of running perfectly on my 433AH (latest firmware, and ROS 3.11), I am feeling very bamboozled, and would wager a guess in saying this is a bug, since it does run fine for at least a couple days. It's time for Mikrotik to step in and help. The sooner the better. Cold booting every day is not a solution I'm willing to live with much longer.

Cold booting hasn't even helped mine, has anybody else got a workaround ?

Regards
Paul

Just to clarify where the bug is, and how to disable the proxy in question:
/ip hotspot user profile set default transparent-proxy=no
and set any other hotspot user profiles you created the same.
This is only V3.11 as far as I am aware.
MikroTik team assures me they are working on it.

The transparent-proxy setting is pretty well known around here already. Plus, the user profile settings apply only for authenticated users. If you have MAC-auth enabled on your hotspot, or if you manually pass-through a user, they'll work just fine.

This problem occurs before a user can authenticate -- there's no disabling the proxy for unauthenticated users because that's what's used to catch requests to the hotspot. For unauthenticated users, the NAT rules redirect port 80 traffic to another port on which the proxy listens. And that's where things break down. Sniffer sessions show some packets being redirected, but not all of them, and no response from the translated port on the hotspot.

These are EXACTLY the symptoms I had. To my extreme embarrasment, I jumped Authorize.net after sniffing a few packets, and got no response when the clients were supposed to go through the walled garden . My client were unauthenticated, and could not access anything (eventually) on the walled garden list. That appears to be enough to use the hotspot default user profile proxy.

ADD: I just completed a little experiment. I allowed Google and a couple other sites through the hotspot via the walled garden. It does not matter what the setting on "/ip proxy enabled" is (mine is set enabled=no), the hotspot uses it for the walled garden. Any 404 Errors have MikroTik HttpProxy and the webmaster setting. It is unaffected by the "/ip hotspot user profile" setting. Mine is "no", but it looks as if it is still using the proxy.

Just a question for all here:
How many of you have SSL sites in your walled garden?

I have two V3.11 boxes. Both have SSL sites in the walled garden.

One box (RB333) has the SSL sites in
/ip hotspot walled-garden ip
after doing a nslookup on the servers,

The other box (RB433AH) has the SSL sites in
/ip hotspot walled-garden

I just checked them both, and here are the results:
The one with the SSL sites in "walled-garden ip" is still up and running after two weeks.
The one with the same SSL sites in "walled-garden" is crashed after two days. The SSL sites hit counts stopped a while ago.
Besides that, all is similar, including the proxy and hotspot settings.

I have the a couple SSL sites in there, but this is affecting people well before that even comes into play. The first page unauthenticated users should see is served directly from the hotspot itself. Sometimes they get nothing, other times they get the proxy error.

Same with me. The SSL sites are just the FIRST TO GO! The others follow in quick succession. I had NO login page at all (page cannot be displayed) on the "walled-garden" box, but logged in and paid on the box with the "walled-garden ip".

I have now changed "Mr. Crash" to the walled-garden ip settings. Guess I will know in about three days.

ADD: I have witnessed the deterioration of the login sequence. First, the SSL payment pages at Authorize.Net fail (page cannot be displayed). Then my prepayment pages start failing (page cannot be displayed). Then the login page fails (page cannot be displayed). But you gotta be there, It happened in a couple hours. Fortunately this time of year, I have enough clients that someone is going to call and say "why won't you take my money?".

Well the cold booting didn't work for me, and I have to wait for the client to test the hotspot for me as it's in another state so I can try the IP-Walled garden setting where I have added our auth servers into.

Has anybody come up with a method of testing the hotspot functionality from a remote location as yet ?
I was thinking of putting a PPTP server interface into the bridge we use for the hotspot but you can;t add that interface type into the bridge port list.

It would be nice to be able to test all of the functions of the hotspot remotely to see if was working.

Regards
Paul

Greetings!

I think it is time for a router check. My "2 week" box is showing signs that, without the "walled-garden ip" settings, it would have crashed this weekend. The hit counts in walled-garden after a counter reset two days ago:
secure sites = 0
clear-text sites = 674
The secure site hit count stop was the first indication of a failure.
BTW, it is still taking payments many times a day, despite the count.

ADD: Here is the count from my "Day and a half" (Mr. Crash from previous post) box:
secure sites = 0
clear-text sites = 84
... and I just made a payment (test mode), then logged in, and no increment of the secure site hit count.
Two days ago, I could not even get a login page with this count.

Normis:
This is the walled-garden traffic over a 2 day period. This hotspot has taken a few dozen payments, according to Authorize.Net. Only this afternoon did any SSL traffic show up at all, and that was under the walled-garden ip entries. RB333/V3.11

[admin@HDMom] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
# SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 D ;;; secure.authorize.net
allow 0
1 D ;;; secure.authorize.net
allow 7
2 D ;;; verify.authorize.net
allow 3
3 X ;;; place hotspot rules here
allow 0
4 http://www.wififory... allow 694
5 secure.autho... allow 0
6 verify.autho... allow 0
[admin@HDMom] /ip hotspot walled-garden>

Note: entry 4 does not have the http:// in the entry. The forum software puts it there.

ADD: Here is a much more remote RB433/v3.10. It has taken about a dozen payments in the week this has been up:

[admin@hdroof] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
# SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 http://www.wififory... allow 175
1 secure.autho... allow 61
2 verify.autho... allow 35
[admin@hdroof] /ip hotspot walled-garden>

Note: Line 0 has no http://

The second one looks much cleaner, and a lot more accurate. Any way I can get that back in V3.12?

ADD 08/11/2008: Mr. Crash is still running fine, taking payments like crazy (I have made 4, including one just a few minutes ago just to check). But the traffic shows this:
[admin@MikroTik] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
# SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 D ;;; secure.authorize.net
allow 0
1 D ;;; secure.authorize.net
allow 0
2 D ;;; verify.authorize.net
allow 0
3 X ;;; place hotspot rules here
allow 0
4 http://www.wififory... allow 115
[admin@MikroTik] /ip hotspot walled-garden>

Nothing SSL at all.

Just an update. RB433AH/v3.11 "Mr. Crash" was working so well after 4+ days, despite the hotspot walled-garden clear-text site hits=134 and the SSL sites hits=0 after several payments (sure crash before), I re-enabled the transparent proxy on the hotspot. And, once again, it let me make a payment, and login. The only hit increase was the clear-text site. No SSL traffic hits shown. All still 0. Another few days and I will enable the transparent proxy on the busy hotspot.

Are you able to confirm which changes you made as I have added the IP of our server serving the login page and I still get the proxy errors.

Thanks
Paul

I am not certain which is the working patch. That is why I am doing things a step at a time. If this rather slow-traffic hotspot does ok with the proxy enabled, I will try it on my busy hotspot. The busy hotspot is still running fine after almost three weeks, but it has both the "walled-garden ip" and the transparent-proxy=no. I want to know which is the fix. Just the transparent-proxy=no did not save my RB433AH/V3.11 from a crash. It has all the signs that it should be crashed already. The first sign of an impending crash was the SSL hits stopped. But they have never really started again. They still show a total of 10 hits, when the real total should be over 100, considering the number of SSL site payments it has taken.

ADD: I got proxy errors too before I found that Authorize.Net required three IPs to insure all got through. Once I got them all in there, it has been working fine.

I'm not having any problem with my walled garden sites. I'm using IPs for some, and domain names for others (without specifying http or https). For example, for authorize.net, I'm using dst-host=*.authorize.net.

trs80: You are still having problems with your login page tho? You don't have the "dns-name" value set on the hotspot profile, do you?

pjulian: The only changes I made after the initial crash was the transparent-proxy=no and the walled-garden ip. All else remains the same, except the walled-garden SSL hits never really came back on any of the affected machines.

I am using dns-name (as well as hotspot-address), and will continue doing so. This works most of the time. It seems it's the busier hotspots that eventually crap out on the redirect, but I'm hoping 3.12 deals with that [from changelog: *) fixed bug - web server could lock up at startup (no access to hotspot login page after that);], even if it means rebooting.

OK with me...but I had real challenges with the dns-name. The dns name you are using is a legitimate name that you can nslookup and it resolves to the hotspot-address?

Guess I will never know which was the good patch now. I have upgraded "Mr. Crash" to V3.12, and all seems ok for now. SSL traffic hits are back.

I'll have to get back to you about dns-name reliability, but if i remember correctly, if the redirect fails I can have a user enter the dns-name into their browser and it'll bring up the login page.

we do have the hotspot walled garden and redirect problem on 2.9.x and 3.x on upgraded or fresh installation

any idea solution for this?

trs80: Didn't think of that reason, and it is a good one. I will try some experiments when I get a free box to play with.

Hellbound: Under
/ip hotspot profile
how is your dns-name set?

What V3.x have you tried? The exact version is important now.

trs80: Didn't think of that reason, and it is a good one. I will try some experiments when I get a free box to play with.

Hellbound: Under
/ip hotspot profile
how is your dns-name set?

What V3.x have you tried? The exact version is important now.

I've tried 3.7 and 3.11 and 2.9.x

it says:

Well V3.11 had its challenges, so that doesn't count. It was bad. I use V2.49 to V2.51 without problems. V3.9 and 3.10 ok too.
Does all work ok if the hotspot is disabled? dns, dhcp, gateway, etc?

And your hotspot is using the "default" profile? Mine always tries to use hsprof1 if I don't change it.
Also check that 10.1.1.3/24 (or appropriate netmask) is assigned to your hotspot interface.

For trs80: I just setup a test box and tried what I thought might work, and it does.
I set the hotspot profile dns-name as "test.prolectron.net" (not assigned in my dns server).
Then:
/ip dns static add name=test.prolectron.net address=192.168.0.1
192.168.0.1 is the hotspot-address for my box.
And it works like a champ!

Now

http://test.prolectron.net
in the browser address bar redirects to
http://192.168.0.1/login
and the login page if you are not logged in, and status if you are

http://test.prolectron.net/login
goes to the login page if you are not logged in, and status if you are

SurferTim:
You don't have to manually add the static DNS entry; it's added automatically when you enable the hotspot. BUT, you do have to set the hotspot-address too, to be sure it's mapping to the IP address on the interface on which your hotspot runs.

Otherwise the router will look up the dns-name and use whatever address it finds (check the 'ip-of-dns-name' property under /ip hotspot print detail). This is guaranteed to happen if you use DNS servers that return a 'catch-all' IP for any names that do not have valid DNS records (OpenDNS does this, as do many ISPs). It will also happen if the provider hosting your domain has a wildcard record for your domain, which in most cases will resolve to the IP of your website (Yahoo does this by default, but I think you can remove the wildcard).

Thanks, trs80. I think that is what my dns server was doing to me. Or what I was doing to me to be technically correct. That is why I picked something I had not assigned. My .com dns has the shotgun catch-all.

Also in my blundering through this, I found that the dns-name must be at least a "something.something" format. Anything. I even used "testname.bad". It even resolved and got the login page. But just "testname" would not.

Interesting comments, I have always used the DNS name and added the entry manually into the static DNs settings, then I set my DHCP for the hotspot clients to be the MT box itself and have never had issues until V3.11

I will have to try your suggestion of manually connecting to the address and try that, so is the general consensus that 3.12 is solving this issue or are you guys still not really sure ?

Regards
Paul

I have just realised also that it is only my 3.11 boxes having this issue, nobody else has complained and we have a mix of 3.0 to 3.9 versions out there.

Regards
Paul

I know there are various incarnations of this problem, but let me just clarify that I haven't had walled-garden issues or any problems with the hotspot dns-name setting.

My problem specifically is that the hotspot stops redirecting un-authenticated users to the local login page, present in every version of 3.x we've used.

The 3.12 changelog lists a fix that may be relevant, but I won't know for sure unless the redirect fails again -- I have not been able to reproduce this problem at all, so I can't force a test, unfortunately.

Yes that's what I am having as well, it just doesn't redirect, if you disable the hotspot access through the router is fine on all occasions. I have only seen this problem twice do far, both on 3.11, one seemed to be OK after a reboot, the other is persisting. We run the same config across all of our hotspots so I know it isn't config related at all.

Regards
Paul

Hi

We have the same problem on all v.3.x and it has affected all hardware systems from RB333 to our 1U core routers, RB1000 and x86.
We have swapped out our RB1000 with other hotspot gateways and downgrade systems which are able to use 2.9.51

We have +100.000 hotspot users a year and this bug in version 3 have been a pain in the a.. cost a lot of time and money

We have 3 small sites which has the RB433AH as a hotspot gateway and after 2 days tests of v.3.13 we upgrade tonight these sites nevermind that our procedure is always to wait 2 weeks before deploying a new firmware on a production gateway and hopefully this version contain the fix very very big issue. I will let you know if this will bring down the support calls.

Ken

Thinking of doing the same, please let us know your findings ASAP clink

Regards
Paul

Just chiming in and confirming that I am seeing the exact same problems. We attempted to upgrade a working 2.9.51 hotspot to 3.10 and 3.11 and we saw the same problems with a crash. We had about 200+ users going all at once, so we saw the deterioration happen very rapidly (about 1 minute) as was described by other users over longer periods of time.

Any word on a fix for this bug?

Does 3.13 actually address this?

Hi Folks,

just putting in my 2c worth.

I'm back here again with a RB/433 with v3.13 on the bench behaving badly.

Just to clarify, we have hotspot enabled, the login page is set to redirect to a remote splash page allowed through walled garden. The unauthenticated client successfuly gets the local login.html, successfully resolves the address of the remote, but can't get the reply due to proxy failing.

As mentioned already in this thread several times, the transparent proxy setting in user profile makes no difference (as this is pre-auth)

This is an infuriating issue that has plagued us since RB133 became unavailable, and we moved to 433 as the standard platform. The most frustrating thing is that the issue has so far evaded any attempt to reliably reproduce it.

We have a standard configuration that we load to a device - usually it will pass tests after load, but fail with this proxy issue after it is installed to site.

The solution is generally reset to factiory default and re-load the config from scratch. Sometimes it is good, somtimes the problem is still there.

We have seen this issue from 3.9 through to 3.13

I have made a concerted effort today to solve it, but to no avail (yet!

Cheers.

hey!

I just discovered something!

Part of our standard load is to have a dhcp client attached to the internet interface.

I discovered that when the problem shows up, the dhcp client did NOT pick up a default route. I checked the dhcp client settings, but the "add default route" was correctly set. I disabled/enabled the dhcp-client a few times, yet the default route did not come up. I disabled "add default route", refresh the dhcp client, re-enable the default route, refresh - there it is. default route is brought up, and away it goes.

So, bad dhcp server? I don't think so - the dhcp server in this case is another rb433 v3.13 - plus this problem shows up on other locations with other dhcp servers as well.

Is this the root cause of the "not found: your cache administrator is...."? I don't know - All I can say for sure is that this unit I have on the bench here had the problem, and now it is gone.

Why does the dhcp client fail to get the default gateway? Don't know that either. Maybe MT support can tell us.

Cheers!

What should we configure for HotSpot to reproduce the problem ?
Are there any specific option or configuration, when proxy is stopping to respond ? It would be great we can reproduce the same problem here locally in our lab.

Thanks for your reply sergejs.

We run a number of hotspots and see them partially crash at various times. The crashes are not always catastrophic and it usually seems that some portion of the firewall or proxy stops functioning. With all of the hotspots that we run, I can't find a common condition for the crashes, but I have noticed some similarities.

Just last night, one of them seems to have stopped letting some traffic through the walled garden, but it does let people login. Once people are logged in, they can access everything just fine. We will send you a suppout of this hotspot before we reboot it. This is a RB411 with about 12 - 15 users on it and it is running 3.11. Once we reboot it, I'm sure it will start working normally.

Also, we have another hotspot that has a high number of users on it (usually around 300 simultaneous users at any one time). The box is an x86 and is running 2.9.51. This one constantly leaks memory until eventually there is no memory left (it uses a full 1GB of Ram at the end) and it will not be able to process logins. It usually last about 30 days or so, then we reboot it and it works fine for another 30 days. We tried to upgrade this box to 3.11, but it quickly failed and would not allow people to access our login page through the walled garden. We had to roll it back to 2.9.51 just to get it stable again.

We also have another half dozen or so hotspots that we are using the IP Binding on to let traffic pass through to managed switches behind the hotspot. We use this for management and monitoring of the switches behind them. Occasionally after a week or two, the hotspot will stop passing traffic to and from the managed switches behind the hotspot. Sometimes, we put an "accept" rule for this traffic in the firewall and that will then allow the traffic to start passing again. Other times, we have to disable and re-enable the hotspot and this traffic will again start flowing. In these cases, it just seems like something in the hotspot firewall has just crashed or partially crashed or something.

Some facts situations:

* We always run our Hotspots on a bridge
* Our hotspots are configured to redirect users to an external splash page through the walled garden, which frames in a login box that is hosted locally on the router
* It seems like these problems exist whether we have transparent proxy enabled or not
* It always takes some time and usage for the problems to develop
* The problems seem to develop faster when there is a higher number of users logging on and off
* We have seen similar problems on 2.9x and 3.x
* 3.x seems fully incapable of handling high load hotspots that have external login pages that must be accessed through a walled garden

If you are interested in getting into our network and taking a look at some of these boxes in action, we would be happy to help you do this and provide you with logins. Maybe seeing these problems in real world situations will help you figure out what is going on since it is so hard for us or you to reproduce in a lab environment.