Pfsense 2.2.3 portal form posts to port 8000

[re0]

After upgrading to 2.2.3 the captive portal is broken on my installation.
First, unfortunately I had to figure out via this forum the captive portal changed port numbers. Used to be 8000, now suddenly is 8001.
Not very pleased with this, since the captive portal form at port 8001 still wants to post the form details to port 8000.
The form has the $PORTAL_ACTION$ variable, which apparently does not respect the new port rule.
I now hard coded the custom portal page at my site with the correct action port, but this is not a solid solution.
Either the upgrade was not complete, or there is a bug in pfsense captive portal port handling.

[cmb]

It was not using the variable if it was still trying to go to 8000. Where that happens it's because people remove the variable and hard code where it's posting.

[Gertjan]

@re0:

After upgrading to 2.2.3 the captive portal is broken on my installation.
First, unfortunately I had to figure out via this forum the captive portal changed port numbers. Used to be 8000, now suddenly is 8001.

I don't thing it's a hardware issue. Neither software, probably a setup thing.
From the visitor/user/client side, nothing has be done or setup so it works (although initial surfer to a https site can/is/should break things)

Why do you think this '8000' & '8001' is important ?

I never told to a visitor/user/client that he should surf to http://something-here.tld:800x
Just "http://www.google.com" will do just fine (https://www.google.com is bad).

@re0:

The form has the $PORTAL_ACTION$ variable, which apparently does not respect the new port rule.

Do you use the build login page or a home made one ?

@re0:

I now hard coded the custom portal page at my site with the correct action port, but this is not a solid solution.
Either the upgrade was not complete, or there is a bug in pfsense captive portal port handling.

The build-in one works just fine for me.
What and where do you hard code ?

I came from 2.2.2 (works fine), upgraded to 2.2.3 : still works, otherwise I might loose my job.
Proof : real time : http://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html
Btw: I'm using my own login- and error-pages.

[re0]

@cmb:

It was not using the variable if it was still trying to go to 8000. Where that happens it's because people remove the variable and hard code where it's posting.

The page is definitely using the variable I mentioned before. Uploaded 3 different versions, in all cases the variable is replaced by the url containing port 8000 instead of 8001.

[re0]

@Gertjan:

Why do you think this '8000' & '8001' is important ?

It gets important if 1) it breaks things, 2) it is a change in use.
The 2) is not so much of an issue, unless the network owner has some restrictions of want to know of any changes.

1. is currently the case, and it is an extra hassle to have to figure out why the portal is even using 8001 instead of port 8000 in the first place.

Your right the user just notices the captive portal does not work anymore when trying to get beyond the cp form to reach whatever site the user wants to visit.

Do you use the build login page or a home made one ?

tried 3 (bare) pages. All custom build containing the variable. The variable is replaced by the cp with port 8000.
The forms work just fine, when reviewing the POST requests made by the clients. They just want to reach the cp at hxxp://cp_ip:8000/
Last version tried was the bare build-in form.
Since the variable is wrongly replaced by the hxxp://cp_ip:8000/ I removed the variable and replaced it with the correct URL in the form. Of course that works fine, but it kind of takes the usefulness out of the variable.

Now for the debugging part, where is the original port number build. I assume the coded default is 8000, adding the id of the captive portal somewhere. Any file names as suggestion? I like to debug this and report back.

edit:
additional bug: $PORTAL_REDIRURL$ is  using an old value. The cp shows the new cp page, but apperantly 'old' values.
Best guess so far pfsense is using an old cp profile with id 0 with the same name, which does not show in the gui?

[Gertjan]

Check you config.xml - export only Captive portal settings.
Do you have a <listenporthttp>defined (I haven't - it part of the old config)

Have a look at /etc/inc/captiveportal.inc, serach for '8000' and '$listenporthttp'

Every portal instance has an unique ID ($cpzoneid) or <zoneid>in the config. This ID is aded to 8000 (http) or 8001 (https) to get a listener port for the captive portal web interface web interface.

See also : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting ?iframe=true&width=100%&height=100%</zoneid></listenporthttp>

[re0]

The exported cp config did not show configured ports. Only the current.

Quick fix nr 2 for me:
disable the cp, replace custom page with default form, enable cp, disable cp, upload original custom page 1, enable cp.
Custom page 1 is exactly as before the upgrade, however now the cp does replace $PORTAL_ACTION$ with the correct port.

[cmb]

Could you send me a backup of your impacted config? Not sure what could be happening there but there's clearly something wrong. Can email to cmb at pfsense dot org with a link to this thread.