hotspot redirect blocked by mt proxy

omega-00 · Sun Mar 23, 2008 5:39 am

Having a problem with the hotspot setup on one of our routers.
The hotspot page that we've loaded onto the device is supposed to redirect users to a remote login page (I'll use login.example.tld as an example)

login.example.tld has been added to the walled garden list but whenever I activate the hotspot and try to go somewhere I get a page saying:

ERROR: Not Found
-------------------------------------------------------------------------------
Your cache administrator is webmaster.
-------------------------------------------------------------------------------
Generated Sun, 23 Mar 2008 11:20:27 GMT by 10.60.4.1 (Mikrotik HttpProxy)

The system is setup with a dns name hotspots.example.tld which has been added into the static dns list, and the server profile also has this set as the dns name.

I'm stumped as a very similar configuration is working fine on a seperate device.

omega-00 · Sun Mar 23, 2008 6:24 am

also, I can't access the mikrotik web page from the outside. tried changing it to a different port with no luck there either.

savagedavid · Wed Apr 30, 2008 6:37 pm

I am currently experiencing similar problems after moving from 2.9.50 to 3.6 - walled garden entries gives a proxy timeout even after disabling all web proxy / transparent proxy features.

omega-00 · Thu May 01, 2008 2:44 am

Hey david, I ended up reseting the configuration on the devices and doing the following

Firstly, set the hotspot server address pool to none, then only specify a dns name for the hotspot server profile, don't put in an IP address.
Then head to the user profiles and modify the default one so that transparent proxy is disabled.

Regards,
Omega-00

savagedavid · Sun May 04, 2008 11:24 pm

Quite a process to fix it seems. I tested the walled garden on a stock router running a new install and it works fine - it seems the problem might be an upgrade issue from 2.9 to 3. I cant restore the production hotspot as easily, but I will let you know what happens when I get to it.

dsobin · Wed May 14, 2008 7:00 pm

I'm having the same problem. I first did a netinstall of ROS 3.8, which was working ok. Then I upgraded to 3.9, and the proxy server
started itself up and now intercepts all of my redirect requests. Requests for URL's in the walled garden work fine. Only redirects get the "Error: Not Found" from the proxy server.

I tried what you suggested, omega-00, but unfortunately the proxy server is still running and is still intercepting my redirects.

Under ip -> web proxy -> settings you can see the 'running' indicator in the lower left of the page. As soon as I start up the
hotspot server, the proxy server starts up. If I disable the hotspot server, the proxy server stops.

I have the hotspot default user profile set to not proxy and the other items you suggested, but that proxy server just keeps on running.

I sent a supout.rif to mikrotik. I hope they can get this fixed quickly or at least supply a work-around that works consistently.

If anyone else is seeing this problem, please post so we can get a sense of how widespread it is.

omega-00 · Thu May 15, 2008 6:00 am

hello dsobin,
try the following as well..

since version 3 mt has created a new proxy system which is still quite buggy (imho)
to stop the majority of traffic passing through this, head firstly to the default user profile for the hotspots and untick "use transparent proxy" this should now mean that the only pages passing through the proxy are the ones that redirect you to the login page initially.

Regards,
Omega-00

savagedavid · Thu May 15, 2008 11:43 am

Hi

Omega00 I tried all options for disabling the proxy. New information I have suggests that the custom website we use for the hotspot is based on version2.9 files, and there are now altered / additional files in version 3. We are updating the custom pages with a ver3 template to see if that solves the problem.

I will let everyone know how it works out

dsobin · Thu May 15, 2008 6:08 pm

Thanks for the suggestions, but, as I said in my previous post,

I have the hotspot default user profile set to not proxy and the other items you suggested, but that proxy server just keeps on running.

However, I finally got the hotspot to work by re-booting the router. I had first tried stopping/starting the hotspot server, but
that still didn't help. Only the reboot got it to stop the proxy server.

BTW, I wasn't using the default user profile. I have a separate one that had "Transparent Proxy" unchecked from the beginning.
I guess just having the default profile with the proxy box checked, even though I wasn't using that profile, broke the redirect.

Savagedavid, regarding the servlet files, we don't use the MikroTik ones at all. We replace all of them with our own files which just redirect the user to our webserver. I'll be interested to hear if you see any difference. Also, if you follow omega-00's suggestions and then reboot, you may see the problem go away. That's assuming, of course, you don't want to use the proxy server at all.

kjagus · Fri May 16, 2008 12:22 am

I won't say anything more. Just - I have the same problem and nothing solves this. F...cked shit.
I'm loosing money with theese v.3 experiments
I think, that the best method will be downgrade to 2.9.51 and do not touch it anymore.
It's crazy!
kj

k3dt · Fri May 16, 2008 1:29 pm

bump T_T any comments from MT devs?

We have same problems with 40 hotspots and 1500+ users (RB333s/RB600s) its quite annoying cuz while we are rebooting our hotspots we must wait until some customers are logged in on every hotspot.

omega-00 · Fri May 16, 2008 4:11 pm

k3dt: I've noticed on our systems it seems to hit a limit at around 80 connections to the router (people logging in or the status page reloading etc)

Unfortunatley we have 350~ users per hotspot for 3 sites.. so it gets bogged down quite easily .. just waiting and crossing fingers for a fix

BulleriNET · Wed May 21, 2008 8:51 pm

just got hit buy this today we use the hot spot on some cpes to define a proxy server under 2.9 it worked just fine now It kinda works on the rb411 but if you put it on a rb133 you will have to hyperterm it to disable the hotspot i am emailing a supout to mikrotik in hopes that it can be fixed ASAP for now i am down grading 133 boards to 2.9.51

dsobin · Wed May 21, 2008 9:55 pm

I just got a reply from Sergejs at MikroTik, responding to my support request about this issue.

Transparent-proxy is enabled for all HotSpot users, which are using 'ip
hotspot user profile' default one.
HotSpot uses embedded proxy by default, set transparent-proxy=no to disable it
for HotSpot clients.

I responded that I had already unchecked the transparent proxy box, but I had to reboot and that the bug appears to be
the requirement to reboot the router to get the proxy to stop.

If I hear anything back, I'll post it. Of course, if you are reading this, Sergejs, you can respond to this topic.

Thu May 22, 2008 11:36 am

How many users and what kind of traffic should we try with HotSpot [when transparent-proxy is enabled], to reproduce your problem ?

omega-00 · Thu May 22, 2008 6:56 pm

Hello sergejs,

our sites have around 300 users each, and the hotspot system is setup to only use 2 pages directly off of the router
1 is the inital page they're redirected to, which in turn redirects them to a remote page they login on
2 is the status window that pops up when they login

these are now the only 2 pages loading via the web-proxy and at peak times users report that the status page gives the connection reset message when refreshing.

looking now (12 at night at the site itself) there are 121 users currently logged in and web-proxy shows around 50 web-proxy connections, this rises higher during the day.

hope this helps.

Regards,
Omega-00

dsobin · Thu May 22, 2008 7:00 pm

I encountered this problem with a test box (ROS 3.9) on my desk with no traffic and only one wireless client. My wireless client was able to reach any URL in the walled garden with no problem. If the wireless client tried to access a URL that was not in the walled garden, the client's web browser displayed the built-in error message from the proxy server, "ERROR: Not Found".

Un-checking the "transparent proxy" box did not eliminate the error. Stopping and starting the hotspot did not fix the error. Rebooting the node fixed the problem.

This problem does not appear to be load related at all. However, perhaps other users are having different problems with the proxy server enabled under load. I just wanted to turn it off and have it stay off.

omega-00 · Fri May 23, 2008 2:11 am

dsobin, there are 2 seperate proxy issues that I have come across, the "Error Not found" and the "connection reset" messages.
As you have noted, the error not found occurs even with no load on the router, while the connection reset requires a number of connections to be made before the proxy stops responding to them

Fri May 23, 2008 4:07 pm

Thank you for the reports.
We are looking for the ways to reproduce your issues [find the reason, why do you get such errors].

omega-00 · Mon May 26, 2008 3:39 pm

Hello sergejs

don't know if this gives you any more ideas but i just received 2 support calls about users not being able to get up the Login page and instead receiving the "ERROR: Not Found" message. I then went over to have a look at the current proxy connections an noticed there are masses of connections showing up from the same IP's.

If I clear these out they are all replaced within seconds. (Note no dst-address as they are connections trying to be made to the hotspot/status pages)

I have forwarded you a suppout.rif also.

Flags: S - server, C - client 
 #   SRC-ADDRESS     DST-ADDRESS     PROTOCOL                                                                                                         STATE      TX-BYTES   RX-BYTES  
 0 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
 1 C 10.60.0.121                     HTTP/1.0                                                                                                         rx-body    0          72        
 2 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
 3 C 10.60.1.21                                                                                                                                       rx-header  0          83        
 4 C 10.60.0.121                     HTTP/1.0                                                                                                         rx-body    0          72        
 5 C 10.60.0.121                                                                                                                                      rx-header  0          36        
...
25 C 10.60.0.121                                                                                                                                      rx-header  0          38        
26 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
27 C 10.60.0.19                      HTTP/1.0                                                                                                         rx-body    0          56        
28 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
29 C 10.60.0.121                                                                                                                                      rx-header  0          28        
30 C 10.60.0.121                                                                                                                                      rx-header  0          37          
...     
72 C 10.60.0.19                                                                                                                                       rx-header  0          34        
73 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
74 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
75 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127       
76 C 10.60.0.164                     HTTP/1.0                                                                                                         rx-body    0          127

omega-00 · Mon May 26, 2008 4:13 pm

I've just restarted the site that was having this issue with no such luck in fixing the problem.

About 300 uni students rely on this site and 600 more for 2 others just like it .. we really do need a fix asap please

Have had to turn the hotspot off which means we're losing money hand over fist again until we can again find something to temporarily resolve the issue... nothing in the site has changed in the last 30 days.

savagedavid · Tue May 27, 2008 1:06 am

Today I did a system reset, upgraded the unit to 3.9 and installed from scratch. I still have the same problem - no walled garden entries work - eventually it gives a proxy timeout. I have disabled the transparent proxy setting under the default user profile. Since all authentication comes from Radius there is no point in creating a custom user profile. In desperation I tried enabling the Mikrotik Web Proxy on the unit and specifying those settings under Server Profile HTTP Proxy settings. All that hapenned is that I received a "Request Denied" instead of a Proxy timeout message.

Very frustrating! Eventually I disabled all Walled Garden features which means nobody can do credit card purchases. I wangled around that by using the trial feature to give users a 20 minute trial when they click on Purchase. Not the correct solution, but at least clients can purchase vouchers.

Is there any way to completely disable the Hotspot Proxy feature?

omega-00 · Tue May 27, 2008 1:18 am

none at the moment that I've been informed of as it appears the web-proxy is part of the built in webserver and therefore hands all it's requests out via the proxy.
Have a look at the webproxy connections tab when trying to connect and you'll see what I mean

omega-00 · Sat May 31, 2008 4:46 pm

just to update others, problem is still occuring in 3.10 - I've been emailing sergejs supout files each time it happens
(to solve I just downgrade to 3.9 until it occurs on that then upgrade again.. by no means a good solution, but it works)

DuDuS · Thu Jun 05, 2008 11:06 am

Hello.

I have exacly disame problam as You.
And I haven't found any solution.

MT we need You help...

Best regards
Michal

omega-00 · Thu Jun 05, 2008 12:36 pm

DuDus have you tried turning of the transparent proxy for the moment?
If you have only a few users per hotspot this should help you in the meantime.

If however you're in my shoes and have 300+ users per site, try turning the status refresh on the hotspot page up to 5 or 10 minutes (the less load to the proxy the better) and you should be able to continue.

You can tell if the proxy has died completely quites easily too, just go into IP -> Webproxy - Connections Tab

You'll start seeing 10-20 connections per IP address with under 1kb per connection (ours would show anywhere from 20-500 bytes)

To temporarily fix this, dump the 3.9 npk file on the router and hit downgrade.. if it happens again after a day or 2 just upgrade to 3.10 again.. not pretty but better than losing a client.

clink · Fri Jun 06, 2008 5:15 pm

Hello

We have the same problem on ROS 3.6, 3.7, 3.9 and 3.10. We have success by removing the DNS name in the /ip hotspot server profile and then disable transparent Proxy. Problem is that it is not all time we see this error, but approxmately 40-50% of our customers which can't access the remote login pages when DNS name and transparent proxy is enabled on the Hotspot.

Omega-00 you wrote about disable the transparent Proxy if you have a few users! We have replaced a ISS6000 gateway with Mikrotik during the tests it seems to work fine. But normally we have around 100 concurrent users online, now we have 10-20 users. We can't see any errors in the logs, but is 100 concurrent users to much for mikrotik when transparent proxy is disabled?

We are not running proxy at all. We are using traffic flow as user-session trace, and if we use proxy we are just able to see the Mikrotik Routers hotspot address and not the destination address on the internet.

Cheers
Kenneth

omega-00 · Sat Jun 07, 2008 8:35 am

I haven't been able to figure out exactly when its going to fail, as mentioned we have 300 users on a single device which works for anywhere between 24 hours and 7 days without issue.

Funny you mention the ISS6000 thou, we had salespeople here demonstrating it to us yesterday lol.. IMHO still no where near as good as a Mikrotik unit and too overpriced.

clink · Sat Jun 07, 2008 9:49 am

We got the job from another company which had used the ISS, we are swapping these units out to MT because as you mentioned MT is much better.

omega-00 pls. tell me if there are any problems running large hotspot on MT when Proxy is disabled?

As I wrote we have 100 concurrent users, but this is the average, some days we have 200+ online and we are planning to adapt MT to another site. This University have +500 concurrent users, but I must be sure that ROS 3 is capable to handle this before we overtake the site.

HW we use are RB1000 (small sites) and SuperMicro 1U (large sites)

omega-00 · Sat Jun 07, 2008 10:50 am

If I were you just rolling these out, I would only use 2.9.51 until we have a new version out and have got confirmed reports that it fixes these issues.

omega-00 · Mon Jun 16, 2008 7:55 pm

*bump* Anyone heard from the MT staff?

Haven't had any reply back to my last emails.

clink · Mon Jun 16, 2008 8:01 pm

Nope. Still waiting too....

Akangage · Wed Jun 18, 2008 4:17 am

Hi.. guys!! I do have some problem with that, after i try loadbalance my 3 lines to get Full Line Download 3 Mbps, 1 line 1 mbps. I tried many ways but seems it didn't work at all.... sigh

is it needed more rule to bypass the hotspot servlet page running again?

ebruni · Mon Jul 07, 2008 5:26 pm

I don't know if it's the same problem. However I solved MY hotspot + webproxy problem here

http://forum.mikrotik.com/viewtopic.php ... 29#p121429

I found there is change in webproxy behaviour where in routeros < 3.0 webproxy connections have external interface source ip. In routeros >=3.0 they have internal interface source ip

omega-00 · Tue Jul 08, 2008 12:09 pm

hello. thanks for the suggestion but I've already tried this previously with no luck
the thing is that it will work fine for a period and then die for no reason.

omega-00 · Fri Jul 11, 2008 1:39 am

So, 3.11 has been released and the only fix I can see mentioned is

*) fixed bug - in some cases web proxy https with parent-proxy did not work;

can any MT reps reply if there has been any changes that affect the error we have been seeing?
The proxy is still horrible to use with over 50 people.

meverest · Fri Jul 11, 2008 4:59 am

Hi Folks,

we saw this problem recently with rOS3.10 and found a work around with assistance of MT suppt is to use a fully qualified hostname as the login host.

under ip->hotspot->profile->hsprof1 we had dns-name = "login.hotspot"

changing this to dns-name="login.hotspot.com.au" fixed the problem and it now works like it used to with rOS2.9.x

note that hotspot.com.au is not our domain, but it will work regardless (as it still puts a static entry to the DNS subsystem)

We still say that this is a bug in 3.10 and we would like to see it fixed, but this work around makes us operational again.

Cheers, Mike.

omega-00 · Sat Jul 12, 2008 3:33 am

we're already using similar on all our sites - hotspots.<companyname>.com.au which has a static dns entry as 172.16.11.1 (being the inside IP of the hotspot interface) but still encounter this issue.

As you've said, there *is* still a bug there that needs to be fixed, I would just like MT to update those of us who are waiting on any progress.

dsobin · Sat Jul 12, 2008 5:58 am

We also have been having problems with hotspot/proxy interactions on ROS 3.x.

We are on 3.10 and 3.11 and I have one site where sometimes it works and sometimes it doesn't. I have transparent proxy turned off in the hotspot profile, but sometimes it still hangs.

We use a fully qualified name for the hotspot and it does show up as a static dns entry.

Our hotspot runs in https mode, and this seems to cause most of the problems. We allow users to reach our login page via a walled garden allow, but sometimes the hotspot doesn't recognize it as an allowed site. Once it gets into this mode, even a reboot won't fix it.

Right now, one of my sites in Florida is stuck in this mode and I can't get it to work.
I just upgraded it to 3.11 since the changelog mentioned https, but it didn't help.

I sure hope MT can figure out what's going on with this.

omega-00 · Sat Jul 12, 2008 8:43 am

I find the easiest way to fix the lockup you have mentioned is to just downgrade or updgrade 1 version.

I've been switching between 3.10 and 3.9 for the moment each time the issue occurs (as you noted a simple reboot won't fix this)

meverest · Sat Jul 12, 2008 9:25 am

I find the easiest way to fix the lockup you have mentioned is to just downgrade or updgrade 1 version.

I've been switching between 3.10 and 3.9 for the moment each time the issue occurs (as you noted a simple reboot won't fix this)

That is all very well in most cases, but all of our current sites are based on RB433 gateway, and there is no rOS2.9 for that platform

Cheers.

omega-00 · Sat Jul 12, 2008 9:54 am

That is all very well in most cases, but all of our current sites are based on RB433 gateway, and there is no rOS2.9 for that platform

Lol silly. Did you read all that I said?

Switch between 3.10 and 3.9
NOT 2.9.X

meverest · Sat Jul 12, 2008 11:32 am

oh!

just one minor step!? you are right, of course, I did mis-read that post.

Our latest batch of rb433 came with 3.4 which was terribly buggy, and upgrade to 3.10 fixed much of that. I didn't even think to try to go back to 3.9

Thanks, I must give that a shot (so long as I can lay my hands on a copy of 3.9)

Cheers!

cramerit · Thu Jul 17, 2008 10:47 pm

We are also experiencing this problem. We're trying everything mentioned here and nothing seems to be working. Walled Garden addresses in Hotspot on 3.x are not working.

Has anyone tried using an external proxy server?

SurferTim · Thu Jul 17, 2008 11:10 pm

This is from another post, but it might be helpful here also:

I found any attempt to use the standard walled garden list with SSL pages will cause problems. I am using 3.11 on a RB333 and had a serious problem trying to get authorize.net working. It seems to be a problem with the dns, since my cure was to use the
/ip hotspot walled-garden ip

All secure sites used in the walled garden I put in here after doing an nslookup. For authorize.net, I used:
/ip hotspot walled-garden ip add dst-host=secure.authorize.net dst-address=64.94.118.32/31 action=accept
/ip hotspot walled-garden ip add dst-host=verify.authorize.net dst-address=64.94.118.132 action=accept

Now all seems to be back to normal. Makes me uneasy tho...

cramerit · Fri Jul 18, 2008 12:33 am

Thanks for your reply. I actually saw that post earlier as we were trying to troubleshoot this and tried it. Things didn't seem to change at all and we were still having the problems.

Any other ideas? Is there a real issue with ROS 3.x hotspot that has not yet been resolved?

cramerit · Fri Jul 18, 2008 1:20 am

Update:

After downgrading from 3.11 to 3.10 the problem persisted.

We just downgraded from 3.10 to 2.9.51 and now the redirect through the Walled Garden is working again.

It appears that there is definitely a problem with 3.x hotspot and redirecting through walled garden. We suspect that it is based on load.

When we were on 3.x, we would set up the hotspot and test it on another port and everything worked great. Then after pushing the same hotspot out to 500+ users by moving it over to another port and loading it up, it would work for the first few seconds and then after that, you couldn't pull any pages down through the walled garden - or you could pull just the first part of the HTML page and it would get truncated.

That's what we're seeing - seems pretty clear to me that there IS a problem - what that problem is seems to be another matter all together. Hopefully MT can figure this one out. It's unfortunate that the only time we can reproduce it is with a load of 500 users trying to access the internet - I don't really have a willing group of testers to help us troubleshoot this.

We'll be staying on 2.9.51 until I hear of a resolution to this issue.

On another note - we do have 3.x hotspot working on smaller installations (under 20 users) without any problems.

Another tidbit: we are trying to pull down an https:// address through the walled garden - haven't done extensive testing with http:// when this is happening. I don't know if that is important in troubleshooting this, but I thought I would let you know.

omega-00 · Fri Jul 18, 2008 2:29 am

I agree with pretty much all of cramerit's post. Only difference is that I've still been able to keep our sites running by disabling the transparent proxy in the default user profile.

cramerit · Fri Jul 18, 2008 3:40 am

I remember turning on Transparent Proxy on the default user profile sometime during our testing, but the majority of testing was done with Transparent Proxy on.

What is the recommended configuration for this scenario? Is there some specific configuration involving Transparent Proxy on the default user profile being disabled that would cause hotspot 3.x to function adequately under this kind of load?

There may be a combination of settings that we did not try to that effect.

What is the "right" way to set up Hotspot in this scenario? Why is the Transparent Proxy option there to begin with (what would one gain by either enabling or disabling it)?

omega-00 · Fri Jul 18, 2008 11:18 am

Without having an up to date 3.1 manual, the 2.9 description of this is

transparent-proxy (yes | no; default: yes) - whether to use transparent HTTP proxy for the authorized users of this profile

Hence, disabling the transparent proxy means that the only requests that end up going via the inbuilt proxy are those to the router itself.
This means that sure, if you have 500 users all trying to login at once you're going to get the same problem, but having 500 users logged in at the same time shouldn't cause the issue.

This is probably the most workable fix I have found to date for the hotspot issue.

SurferTim · Fri Jul 18, 2008 1:11 pm

Hi omega-00

Is your hotspot box behind a router? Or is it direct-connect to the internet?
It seems all the boxes I am having trouble with are behind a router.

And just to verify, all you did to correct your problem was disable the hotspot user profile transparent proxy? Nothing else?

omega-00 · Fri Jul 18, 2008 1:18 pm

Hello tim, all our boxes have public subnets connecting to the hotspot but I don't see that it should make any difference.

Once again, hard to test as the issue only appears with bulk users, but yes disabling the transparent proxy was the key point that got us working again.

Second fix was: IF the proxy has locked up completely and generates multiple connections per user that have no/very little traffic, then upgrade or downgrade a version (3.10 -> 3.9)

SurferTim · Fri Jul 18, 2008 1:35 pm

I am using V3.11 now. So a downgrade to V3.9 may solve my challenge if nothing else works?

Now, how do I do that? There is no archive on MikroTik site to backup to a previous version. Since I did not download V3.9, I guess I am, how do you say, "SOL"?

ADD: European companies seem to have a different business approach than I do...NOT BAD, Normis, just different.

omega-00 · Fri Jul 18, 2008 2:25 pm

correct, shouldn't adversely affect anything on the router.

Let me know how it goes.

SurferTim · Fri Jul 18, 2008 2:59 pm

Well, I will presume my fix was not permanent. I am now on my way to one of my sites that apparently has failed again.

EDIT: False alarm. Looks like browser cache on this one. The fix is still working! Turn that frown upside-down!

SurferTim · Fri Jul 18, 2008 3:40 pm

I normally do not double-post, but I just noticed something in my Apache logs. There were NO calls to my welcome page prior to disabling the transparent proxy this morning at omega-00's advise. Now the hit count is rolling up like crazy again!

Thanks, omega-00!

To the MikroTik team: My welcome page has "Pragma: no-cache" and "Cache-Control: no-cache" headers. They work everywhere else.

omega-00 · Fri Jul 18, 2008 4:08 pm

You're most welcome. Please post back here if you hear anything further from mikrotik on the issue so other can benefit also.

SurferTim · Fri Jul 18, 2008 4:27 pm

Hi omega-00,

I found some other interesting things looking through my Apache logs. I see no calls to my "verify your info" (pre-Authorize.Net call) page either. This is where each purchaser needed to pick up a unique time-sensitive code from my server for Authorize.Net.

If there were no calls to that page, then I know now why my purchase attempts were failing.

omega-00 · Fri Jul 18, 2008 4:38 pm

Is that done server-side or from the clients computer, if client I would recommend just checking the walled garden listings and if you have any problems setting them up, add just the sitenames into the walled garden IP list (eg payment.authorize.net in the walled garden would allow https and http)

SurferTim · Fri Jul 18, 2008 4:56 pm

Until my upgrade to equipment using V3.0+, it did work. All my small sites using the RB133s are performing flawlessly, with the entries exactly as you suggest. And it worked on the new OS version for a couple of days.

I also use an "Expires: -1" header on these pages. That has always kept IE from caching them.

omega-00 · Fri Jul 18, 2008 5:09 pm

Hmmm. I have been able to get mine to work with 3.X for the moment but if you're having problems accessing the payment page then it may be time to think about going back to 2.9.51 for the moment.

Are there any major reasons you would need 3.X? As we can all atest this is a quite serious glitch, but I'm yet to see positive steps in fixing it from MT other than being told its being done (sorry sergejs but its true). Then again changing between 2.9 and 3.X can be quite a task also if it requires a site visit.

Regards,
Omega-00

SurferTim · Fri Jul 18, 2008 5:13 pm

I am now upgrading to 433s. The box that is giving me the most trouble is a RB333. I have read in other posts that you cannot downgrade these to a version below 3.0.

ADD: Does anyone know where to get archives of this OS? Like V3.9 maybe?

omega-00 · Fri Jul 18, 2008 5:27 pm

http://www.mikrotik.com/download/routeros-x86-3.11.npk
http://www.mikrotik.com/download/routeros-x86-3.10.npk
http://www.mikrotik.com/download/routeros-x86-3.9.npk
http://www.mikrotik.com/download/routeros-x86-3.8.npk

SurferTim · Fri Jul 18, 2008 9:12 pm

Got the pattern there. Took about a second.
The V3.9 for the RB333 is:
http://www.mikrotik.com/download/router ... pc-3.9.npk

SummonerSTX · Sun Jul 20, 2008 2:51 am

Omega, you seem to be a wealth of information on this ever so annoying topic. Hoping I can pick your brain a little...
We are in a bit of a tight situation at our tower sites. I have x86 systems running 2.9.51 at the moment that are responsible for running multiple hot spot interfaces as well as routing all tower traffic onto our back-haul via OSPF. Right now the system works GREAT and part of me wants to leave it as is, HOWEVER we are hitting very high loads on these routers and we are at a point of needing to step up the beef of the router. I did a test deployment of 3.4 on a system with multiple processor support enabled. Did not have the proxy issue at all, things worked great for about 45 minutes then the router hard locked on me. Re-booted and 45 minutes later had the same issue. I tried disabling multiple processor support and still the same thing. Anyway, told you that story to tell you this one.. I believe my issue with the lockups has to do with the older 3.0 version and I want to move to 3.10 I am just terrified of this proxy issue. We have well over 150 clients behind each of 3 hot spots running on this system. So long and short I want to go into this with the deck stacked in my favor.

1) we do not use transparent proxy, have always had it off in the user profile.
2) we have both host-name and IP entries for authorize in the walled garden.
3) I have prayed extensively in hopes that it will help me avoid this issue.

Steps 1 and 2 I have gathered from info here. Step 3 is just for good measure
Is there anything els you can possibly think of that we should do to avoid this problem??
I know one post you were involved in seemed to think that if you add a masquerade rule for your inside hotspot IP it will resolve the issue, not really sure I am on the logic train with this.

Anyway, any info you OR ANYONE ELSE can give me would be GREATLY appreciated!
Thanks in advance everyone..

omega-00 · Sun Jul 20, 2008 4:52 am

Hello summoner, welcome to the leaky boat

Sorry I took so long, didn't get notification of a new message.

We had similar issues with version 3.0 I would recommend upgrading to 3.10 if you're already in the 3.X versions as it does fix a number of issues that were introduced with 3.0

However, as you said you don't use the transparent proxy I would also recommend you change your default user profile status autorefresh time to around 5m rather than 1m (both the initial redirect page and the status window are comming from the mikrotik, hence they are forced to pass through the proxy)

I would recommend you keep the multiple processor support disabled for the time being.

SummonerSTX · Sun Jul 20, 2008 5:48 pm

Thanks for the info Omega I will ceratinly look at the refresh times in the user profiles, I think we are currently set to 5M but I will verify. I am going to bite the bullet in a just a few minutes and push my bench router with 3.10 out to the field. As i mentioned we are in need of more beef so I am going to attempt to run with multiple processor support enabled. If i have problems I will fall back to it being off and see how it goes.

I will let you know how it goes later today...wish me luck!

Thanks again for all the great info.. this community is what truly make Mikrotik work!

omega-00 · Sun Jul 20, 2008 6:15 pm

As i mentioned we are in need of more beef so I am going to attempt to run with multiple processor support enabled.

What are the specs of the device you're using (if you don't mind saying) there may be some other ways to drop overall usage if you don't have any success with the multiple processor option.

Edit: sleeptime now so you won't get any further replies until tomorrow

SummonerSTX · Mon Jul 21, 2008 1:23 am

Router went live over 5 hours ago and so far so good (knocking on wood PROFUSELY!)
No lockups or re-boots and throughput has been great.
Also I have periodically tested hotspot access with a laptop and all looks good.. hopefully those setting did the trick!

As for our configuration:
This particular tower site uses the following:
12 AP's (Combination of 2.4 and 5.

all Mikrotik feeding back to a managed switch.
We then break those 12 AP's into 3 switch groups then feed them into an RB44G on an x86 based PC.
The PC runs a socket 775 motherboard (SuperMicro) and an Intel 1.8GHZ core2 duo and 1 gig of RAM.
The PC then authenticates our traffic against a radius server and routes onto our back haul via OSPF.
At this site we have 3 backhaul links: 1 MT532 running dual N'streme 1 Dragon Wave licensed shot and 1 Motarola 150 Meg 5.8 link (Orthogon). All told the site services just a shade over 750 clients (this includes some downstream AP's that are WDS linked into the primary APs).

Soon we are going to move away from multiple hotspots and go to a VLAN system to authenticate and route most clients while leaving hotspots in place for roaming users.

Its never boring!
I will keep this thread posted on how my experiment unfolds.

omega-00 · Mon Jul 21, 2008 1:36 am

*whistles* Nice.

Good Luck!

SummonerSTX · Mon Jul 21, 2008 3:49 pm

Now at the 19 hour mark and all still looks good
Hotspot appears to be having no issues at all.
Thanks again for all the good info!!

adiantoz · Wed Jul 23, 2008 11:08 pm

Now at the 19 hour mark and all still looks good
Hotspot appears to be having no issues at all.
Thanks again for all the good info!!

Dear SummonerSTX,
Is it still working until now?

SummonerSTX · Wed Jul 23, 2008 11:25 pm

adiantoz,
As of right now we have been up for: 3Days 3Hours and 48Minutes with 0 failures or complaints.

Looks like the magic is working! Hope this helps others!
-SummonerSTX

adiantoz · Thu Jul 24, 2008 7:23 am

adiantoz,
As of right now we have been up for: 3Days 3Hours and 48Minutes with 0 failures or complaints.

Looks like the magic is working! Hope this helps others!
-SummonerSTX

wew.. sounds good.. Do you use MT 3.11?

SummonerSTX · Thu Jul 24, 2008 3:19 pm

wew.. sounds good.. Do you use MT 3.11?

Using 3.10 on this particular unit. I always like to stay at least a couple versions behind the curve since as we all know there is a bit of beta that still happens on the newest versions released.
I think the biggest tricks were:
A) Make sure transparent proxy is off (unless you are running a very small hotspot)
b) Make sure that you have the IP and hostnames of those sites you need for your authentication in the walled garden. (not just the hostnames).

Thanks again to everyone that contributed info to this and other threads!
I am going to give this unit another week to burn-in at this site and then I am going to start deploying more of these to other sites. By the time it is all said and done we should be running 8 of these beasts total. I will keep you guys posted if I see any problems pop up.

samsoft08 · Sun Jul 27, 2008 9:49 pm

3days - 5days - sometimes 10days , yes it works for that number of days , but the killing thing the ERROR could be happened Suddenly blocking all the clients !!!!
I think its a deep bug un the router os V3.xx , and it got nothing to deal with this form , we should see in the next version changelog : web-proxy blocking requests fixed !!!!
I wonder what MT team saying when they read all these topics ?
its not a trial and errors field , it should be a professional field , and this is a BUG .. its not somthing we are trying to invent ... or some routing method ... its a BUG .. we are waiting to be fixed , of course after MT team knows there is a bug ..

omega-00 · Mon Jul 28, 2008 12:09 am

They do know or at least should know.. I've forwarded a number of supout.rif's through and I encourage you all to do the same if possible. Perhaps they'll revert to the old working proxy..

clink · Mon Jul 28, 2008 12:49 am

Yes they should know. We are rolling back to 2.9.5 on our Supermicro servers and swapping our RB1000 1u to other Hotspot controllers until this has been fixed. We can't afford to use v3 and downgrading and upgrading to get the hotspots running. We have a lot of the 333, 433, 433AH and RB1000 and we have tried all the suggests in this fora and just concluded that we can't afford to loose our hotels caused to this bug. these units can't be downgraded to 2.9.5 so we are forced to set up other units. We preferre to work with Routeros, but the stability to our clients is a must. Right know it looks more like once we acted as a volontaire to tests a new firmware from a nother brand on one of our large spots, but we nearly lost the contract to this spot, caused to the testing. I think they do a great job, but the should mark in the release notes that the hotspot package which use the proxy are not stable yet!

Kenneth

samsoft08 · Tue Jul 29, 2008 11:14 am

any update for this problem !!!!

trs80 · Thu Jul 31, 2008 6:50 pm

No fix for this just yet, but I noticed something yesterday on one of my routers (3.11) while it was having this problem.

First, when things are working properly:
1) The entries under /ip proxy connections are only between hotspot clients and the server hosting the login page.
2) Free memory typically between 11MB and 13MB

When the redirect fails:
1) Proxy connection entries are for public IPs, presumably those a client is attempting to reach.
2) Free memory down to 5MB

After a reboot, things return to normal.

adiantoz · Fri Aug 08, 2008 5:10 pm

I have many MT routers for hotspot service.

After reading this forum, I'd try to upgrade one of my servers. I'd upgrade to 3.11.. and, no problem at all. I already have 4 servers with 3.11.

Other servers still using 2.9.46 (I prefer to using this version), and this day, I decided to upgrade my 2.9.46 to 3.11.. and after rebooting... bump... I cannot login to hotspot

I don't know why this happen (I use the same "all_packages-x86-3.11.zip").

I think using MT 3.x is depending on your luck

adiantoz · Tue Aug 12, 2008 6:32 pm

on 3.12 changelog:

*) fixed bug - web server could lock up at startup
(no access to hotspot login page after that);

hope it works

clink · Tue Aug 12, 2008 7:27 pm

It sounds nice. I really hope this fix will solve the problem

samsoft08 · Wed Aug 13, 2008 11:54 am

any one test the new 3.12 ?? does it solve this problem ??

clink · Wed Aug 13, 2008 12:17 pm

We upgraded two RB1000 1U yesterday and the upgrade seems to work fine on these 2 units, but we are not able to reproduce the redirect error in our test envirroment, here it seems to work just fine. We need to upgrade a production core router to test it, but caused to this tread http://forum.mikrotik.com/viewtopic.php?f=2&t=25921 we will have to wait until it is solved

Kenneth

SurferTim · Wed Aug 13, 2008 12:21 pm

I am testing V3.12 on a RB433AH. So far, so good, But the failures did not start for a couple days on my system. I installed it yesterday, so in a couple days, I will install it in a busy AP. Then I will be sure.

omega-00 · Wed Aug 13, 2008 12:45 pm

will do likewise.

interpoint · Wed Aug 13, 2008 4:24 pm

I have tested V3.12 and the problem is still there. Vista users do not get the MikroTik Hotspot Log in page, XP users do.. If I bypass the vista machine in bindings the Viata machine gets access and can surf the net.

What is going on ? I really could so without all the support calls that are coming in on a block of 80 apartments !!

omega-00 · Wed Aug 13, 2008 4:46 pm

I've been able to fix some Vista issues previous by trying the following.

- disabling IPv6 on vista (which seems to try and use peer dns if you have allowed interconnectivity between units)
- "netsh winsock reset" in cmd prompt (then do a restart)
- installing firefox, on quite a few of the Vista machines, IE just refuses to redirect to the hotspot page.

Regards,
Omega-00

interpoint · Wed Aug 13, 2008 11:55 pm

Thanks Omega-00,

I have tried some of that stuff but it is not a workable solution as this is just supposed to work without any support intervention.

I have sniffed the packets from a customer that could not get access. The sniff took place before and after bypassing the users mac in the hotspot bindings screen. I sent the sniff to mikrotik to see what they think.

It seems to be just affecting vista users.

In regard to:

- disabling IPv6 on vista (which seems to try and use peer dns if you have allowed interconnectivity between units)

We don't allow it..

interpoint · Thu Aug 21, 2008 10:22 pm

Guys, I changed the x86 machine to a RB600 and restored the backup onto the RB600. I am using ROS3.12 on both machines.

I replicated the MAC addresses of the x86 machine to the RB600 so that I would not disturb the DHCP based ATA's on the LAN.

Called some vista customers that could not access the login page and hey presto.. Guess what !! They are all able to login and the login screen appears perfectly. No configuration change was made to the ROS system other than change the hardware !!

Fri Aug 22, 2008 11:39 am

VERY weird

taylorc · Wed Aug 27, 2008 9:05 am

We have been fighting with a problem that causes some of our customers (about 2%) to be unable to get a login page. 3.13 seems to have nixed this problem finally, but after the 3.12 x86 disaster we're holding back on field deployment of 3.13 a bit longer, so we can't know for sure yet.

Anyways, I wanted to mention some things we found out about the Vista problems. We had a major problem with Vista customers not getting a login page. Upon further investigation, we noticed that Vista had flagged the interface "local only". This meant it wouldn't even try to reach the outside world, and therefore never hit the login page.

After some analysis, we learned that this condition is caused by some sort of DNS checking Vista likes to do (probably just to screw with Wireless ISPs such as ourselves). To fix it, we made sure our "DNS Domain" (also known as DNS suffix) was a nonsense domain (we use "wireless.network") and most importantly that your DNS server IP address is in your Walled Garden. Allow all traffic through, don't restrict it by port or anything. (We use a dedicated firewall down the line to protect our servers including DNS so this doesn't create any security concerns for us.)

Even if you're using the local DNS cache in your box, whitelist its IP. This makes the box directly pingable (which is also very convenient for diagnostics) and allows all DNS queries to be answered, even if the returned server IP isn't currently reachable because the customer isn't logged in.

These changes resolved just about all our Vista connection issues.

interpoint · Wed Aug 27, 2008 11:42 am

Thanks for the feedback. I have had no problems since I put the RB600 in place on the site.

I know that the config was the same as I restored it from the x86 machine and just had to re-enable the usual interfaces after the restore. The rest of the config was identical and I even turned back on the transparent proxy for the default hotspot profile.

I called some more customers since the replaced box and all is working perfectly.

The strange thing is that I was using a Dell Optiplex GX620 with genuine Intel Pro 1000 DT Network Cards. Very common hardward !!

I still have the machine on the floor beside me and when I get a moment will try and see if I can replicate the problem with a Vista Laptop.

omega-00 · Fri Aug 29, 2008 6:14 am

I just tried this on a remote site to fix a vista user with no luck, I have problems quite a bit still with either 'new' vista users or vista users who have been on a wireless network at home etc then come back to our connection.

The users seem to pickup a dhcp lease and have access to the walled garden with no problem but can't get to the hotspot page.

Jeeva · Wed Sep 10, 2008 3:34 pm

I am having trouble setting up a fresh install of a 133. I setup only the basics with the lan going to internet and wlan having the hotspot. No users are redirected to the login page unless it is typed in manually. I have turned proxy off, added the routers wlan ip to the walled garden and am using xxx.xxx.com as my dns. I won't have more than 10-12 users per AP at the same time should I rather just use 2.9 with all my 133's?

omega-00 · Fri Sep 12, 2008 5:30 am

Have you tried using the hotspot setup in winbox to make sure its not a problem with the config you did?

omega-00 · Wed Nov 05, 2008 5:46 pm

An update for anyone who has suffered from this issue previously, the issue is still present on versions up to v3.13 at this time, just upgraded a unit to v3.14 after the most recent failure, will post back in a couple of weeks to confirm this is ok.

Also, of interest to the majority of hotspot provides: this issue only appears (in my case) to sites with a large number of concurrent users, I have yet to see this occur on any site with an average of 10 users online.

omega-00 · Wed Jan 14, 2009 8:59 am

Issue just popped up again on version 3.18 - this time on a site with only an average of 10 users online at any time.

Seeing the usual web-proxy table filled with mutliple requests per IP address and responses all 10-200bytes

Forwarded through a supout.rif to mikrotik to look at.

omega-00 · Tue Jan 27, 2009 9:37 am

3.19 notes a fix to the web-proxy, I've been trying this on a couple of our hotspots and it seems ok. Will report back in a months time or so on current stability.

camilobom · Thu Apr 04, 2024 7:52 pm

Hey guys, I am using a CHR 6.49.10, and I am facing a similiar problem when I try to redirect the users to a external login page.

But I never face this problems configuring hotspots, if one one could help me I will be grateful.

ERROR: Gateway Timeout  
While you retrieve the URL http://loginpage/login  

- Connection Refused  

Your cache administrador is webmaster
 ------------------------------------------------------------- 
Generated ...... by 10.10.10.1 (Mikrotik httpProxy)

OBS: There is no transparent proxy enable

Who is online