Bug 13152 - Captive Portal loosing client authentification
Summary: Captive Portal loosing client authentification
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 All
: - Unknown - Major Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL: https://community.ipfire.org/t/captiv...
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-19 21:00 UTC by lili Nator
Modified: 2024-03-14 21:21 UTC (History)
3 users (show)

See Also:
adolf.belka: needinfo+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lili Nator 2023-06-19 21:00:38 UTC
Captive Portal Users with unlimited vouchers are disconnected and the captive portal website appears. This Problem occours daily at 11PM(UTC+1 time zone).

 If I disable and reenable captive portal for blue it’s working again.

Version is IPFire 2.27 (x86_64) - Core-Update 171 - but older versions are also affected.
Comment 1 Michael Tremer 2023-06-20 11:24:17 UTC
Would you like to have a look at it? It is most likely that the timeout check that wipes all clients fails here.
Comment 2 Terry 2023-06-20 12:11:15 UTC
See forum: https://community.ipfire.org/t/captive-portal-loosing-client-authentification/8928

By using the captive portal with unlimited coupons, clients will be disconnected (session closed) between 11pm and 12pm from the network. The captive portal website comes up again.

Set up time zone: UTC+1
Comment 3 Adolf Belka 2023-06-21 11:20:20 UTC
(In reply to Michael Tremer from comment #1)
> Would you like to have a look at it? It is most likely that the timeout
> check that wipes all clients fails here.

I have put it on my list of bugs to work on.
Comment 4 Adolf Belka 2023-12-28 15:12:27 UTC
So I have had some time to have a go at this.

First step was to reproduce the problem on my vm testbed.

Unfortunately that did not work.

I set up a blue client to look for dynamic IP's and set up the Captive Portal on blue with coupons. I created an unlimited coupon.
This was all done yesterday.

The captive portal connection was successfully made.

It ran in the afternoon and into the evening, past 11:00pm and past midnight and went all night long with no problems. The captive portal connection continued working and there were no problems and no disconnections. I tried browsing via the captive portal connection on the blue client several times during the afternoon, between 11:00pm and midnight and at around 2:00am and I was always able to browse and access new sites etc.

It continued for over 24 hours with no problems.

In the forum there was a comment that the IPFire was rebooted at 3:00am so I tried rebooting the IPFire with the working captive portal connection on my blue client. After reboot, the blue captive portal connection was still working with no problems. No need to reconnect.

In the forum there was a comment about maybe the problem is when the blue client gets rebooted.

I tried that with my blue client with a connected working captive portal connection. After the blue client was rebooted the connection was working fine with no need to re-connect.

Everything that I have tried to do has been unable to reproduce the problem on my setup.

The only way to cause the captive portal connection to stop was to delete the coupon. However then the old coupon no longer worked and a new coupon had to be generated and the captive portal connection for the blue client remade.

In the forum it was mentioned that when the connection was lost the same coupon number could be used to re-connect for the blue client.

This test was carried out with Core Update 182 Testing Build 8064dce9

Could the people who reported this problem confirm that they are still experiencing the same issues with Core Update 181 or with Core Update 182 Testing?
Maybe something has resolved the problem, although no change was made to the captive portal code.

If the problem is still occurring then we will need to go into more details of the exact setup of the network involved to see what changes I might need to make on my network to be able to reproduce the problem.
Comment 5 lili Nator 2024-02-03 21:32:03 UTC
Hello Adolf, the problem is not only the captive portal. The LAN AND openVPN-Warrior-Connections are dropped daily at 23h. This happens everyday and also with the newest 2.27 CU182
Comment 6 Adolf Belka 2024-02-03 23:32:02 UTC
(In reply to lili Nator from comment #5)
> Hello Adolf, the problem is not only the captive portal. The LAN AND
> openVPN-Warrior-Connections are dropped daily at 23h. This happens everyday
> and also with the newest 2.27 CU182

This indicates that the problem is nothing to do with any timeout item on the Captive Portal page.

Can you provide a screenshot of your WUI Connection Scheduler page and also a copy of the fcrontab file.
You can get this by running fcrontab -e and copying the contents to a text file which can then be attached to this bug.

As I have not been able to reproduce this issue and it affects multiple systems on IPFire the only thing I can think of is that there must be some entry in the fcrontab that is triggering it that is not present in my fcrontab system.
Comment 7 Adolf Belka 2024-03-05 19:08:52 UTC
I am coming to believe that the problem experienced by @lilinator and @Terry are different problems with different causes.

@lilinator has the problem every day at 11:00pm but the problem is that the Captive Portal client and the LAN client and the OpenVPN Road Warrior client connections all get stopped at that time.
That is not a problem coming from the Captive Portal code. The issue has to be common to all three of the applications being affected.


@Terry has the problem only with the Captive Portal. The event does not occur every day and can have 8 months between occurrences or much quicker.
It also can occur between 11pm and 12pm.


Both users had their time zone set to UTC+1 which was the same as the time zone set on my vm machines.

I was unable to reproduce the problem in any way.


Were the clients having the problems Linux or Windows machines. My testing was all with Linux clients as I have no Windows based systems.

I have run out of ideas of how to fault find this. Without being able to reproduce it, it is not possible to identify what is causing the problem and hence fix it.
Comment 8 Terry 2024-03-06 16:51:23 UTC
(In reply to Adolf Belka from comment #7)
> @Terry has the problem only with the Captive Portal. The event does not
> occur every day and can have 8 months between occurrences or much quicker.
> It also can occur between 11pm and 12pm.

That's not right. I barly use WLAN and usually I'm in bed by 10pm. The issue accures every time I or others use WIFI between 11pm.

I don't usw VPN, but I can tell that samba is also loosing its connection. That happaned to me. I streamed a video from IPFire samba and the stream was interrupted. It's like every communication to IPFire is rejected.Reconnect and it's working again.
Comment 9 Adolf Belka 2024-03-06 18:29:21 UTC
(In reply to Terry from comment #8)

> That's not right. I barly use WLAN and usually I'm in bed by 10pm. The issue
> accures every time I or others use WIFI between 11pm.
> 
> I don't usw VPN, but I can tell that samba is also loosing its connection.
> That happaned to me. I streamed a video from IPFire samba and the stream was
> interrupted. It's like every communication to IPFire is rejected.Reconnect
> and it's working again.

Okay, then I had misunderstood that. Then it is similar to @lilinator except with different functions having their connections dropped.

Then that definitely indicates that the issue, whatever it is, is not in the code of the Captive Portal as it must be related to some other common aspects.

I also notice that you mention it is when accessing via wifi. Is this wifi, using a wifi card within IPFire or using an external Wireless Access Point.

In my testing on my vm testbed my Blue is effectively a virtual wired connection.

I could test things out on my production machine but that only has WAP's for the wifi connection.

If the problem is occurring with a wifi card built into IPFire then I can not reproduce that setup.

It would be good if @lilinator could feedback if the problem their setup has a wifi card in IPFire or uses a WAP for wifi connection to see if there is any commonality in setup between the two bug reporters.
Comment 10 lili Nator 2024-03-12 07:39:52 UTC
(In reply to Adolf Belka from comment #9)
Hello Adolf,
something has changed since last year. There are not longer internet connection-drops of the VPN or Ethernet-PCs.
Only WLAN-Clients are affected. We have Wlan clients with endless-vouchers and they lose connection between 11PM and midnight. Sometimes the CaptivePortal-Website is shown after this, sometimes not.
So for me its definitive a problem related with permanent-vouchers / CaptivePortal.
Comment 11 Adolf Belka 2024-03-14 21:21:29 UTC
(In reply to lili Nator from comment #10)
> (In reply to Adolf Belka from comment #9)
> Hello Adolf,
> something has changed since last year. There are not longer internet
> connection-drops of the VPN or Ethernet-PCs.

Nothing has changed in the captive.cgi code for 3 years, and that change was just a change of the system command to touch files to create them if not already present.
The change before that was 5 years ago and was a change to fix a potential Cross Site Scripting vulnerability in the Title box of the captive.cgi code.

> Only WLAN-Clients are affected. We have Wlan clients with endless-vouchers
> and they lose connection between 11PM and midnight. Sometimes the
> CaptivePortal-Website is shown after this, sometimes not.
> So for me its definitive a problem related with permanent-vouchers /
> CaptivePortal.

Everything I tried with permanent vouchers on the Captive Portal failed to duplicate what you and @Terry have experienced.

The common thing I have seen in your s and @Terry's input is that it was involving a wifi connection in IPFire itself.

The vm's I have set up are all using virtual cabled ethernet connections.
My production swystem has wifi connections but via WAP's that are connected to IPFire via cabled ethernet connections.

I think someone else needs to pick this bug up, that has access to an onboard wifi card connection in their IPFire system to try and duplicate the problem.

Therefore I am removing my name from the assigned aspect of this bug.