Ramdom MAC users disconected (Vouchers) after reboot



  • I've been using pfsense for some time now…

    I use pfsense as a captive portal with built in voucher system as authentication system..

    I have the "Enable Pass-through MAC automatic additions" checkmark checked and the "Enable Pass-through MAC automatic addition with username" checkmark also checked... and what it does is... when a user logs in via voucher, a passthrough mac is added to the mac tab with the mac address of the equipment that used that mac with the Voucher code as the description for that user.... almost everything is working perfect (vouchers can only be used by one machine, the vouchers expire on time)...

    but there is one problem... when I have to reboot the firewall... or when there is an energy failure... some vouchers and the mac associated  dissappear from the mac tab ramdomly... and I have to have the user log in again...

    I'd like some help on how to solve this issue... or at least to know why it happens.... many thanks in advanced...



  • Go to Diag>Backup/restore, Config History tab. If any entries were actually removed, you'll see it in the config diff there. It's highly unlikely any of them were removed by a reboot (reboots don't change the config), either they weren't there to begin with, or an admin removed them.



  • Thanks for that fast reply…

    actually it has never happend "NEVER" with a user that I had added manually through the "mac" tab...

    but it has always happened "ALWAYS" with with users added by vouchers (always six or serven user get disconnected everytime the firewall reboots... no matter if rebooted manually or by power failure... some "Auto-added for user XxXxXxX" are not there after the firewall is fully back on...



  • What's the diff between config revisions show? If some went missing, it'll show what made the change.



  • my firewall was last rebooted 8 days ago…

    I went to the back up history and all I can find is: see image below...

    and also I forgot to mention that it also happens when I click on save any changes on the "Captive portal(s)" tab...
    (there's a note down there that says that saving changes will disconnect users... but I know that doesnt remove any macs from the mac list... yet some "auto added passtrhough macs for user XXXXX" are eliminated...




  • about the picture above… the "Diagnostics: Configuration History..." shows more lines... but they are all about the same.....
    every minute 4 or 5 backups are created...... I don't know if that should be...



  • @cmb:

    What's the diff between config revisions show? If some went missing, it'll show what made the change.

    I rebooted my fireall and this is the difference showed by the config history

    attached below… I was using my phone...








  • Emmm Hellow again….

    there is an inconsistency with the system...

    I took one of the devices that was disconected after a reboot... and another device that was not... and did the following:

    1rst ***erasedfrom the mac tab... and expired any vuocher associated with them both...

    2nd ***then I logged in with the one that after a reboot got disconnected from Captive Portal...
    and then looked up at the config history and it showed no change associated to adding that mac to the config history... (it seem strange to me... and then I went to the mac tab and searched for the mac that I had just logged in... and didin't find it... so basically "the phone got internet access after using the vuocher, there was a log on the Status: System logs: Portal Auth about the voucher and the mac address login... BUT.. there was no passthrough mac on the CP mac tab... nor was it on the config.xml file

    with the other device the difference was.. that it showed on the on config history... and it is on the mac passtrhough tab....



  • @hardy_rafael17:

    ….. there was a log on the Status: System logs: Portal Auth about the voucher and the mac address login... BUT.. there was no passthrough mac on the CP mac tab... nor was it on the config.xml file

    When you logged in, does the log line contains:
    "Auto-added for user {$username}"
    or simply
    "Auto-added"
    ?

    edit : also inspect current ipfw rules with the help of https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
    You found your MAC in the rules (table 1,2,3 or 4 probably) ?



  • On the mac tab, this is one of the entries
    34:4d:f7:5b:3f:d1 Auto-added for user bLURVRB

    but all the macs that I can see on the mac tab are on the config file… so actually none of them are removed after a reboot...


    this is one of the macs that don't go to the config file after a succesfull voucher login...

    94:d8:59:56:1c:4a

    [2.2.4-RELEASE][root@Hardy.NET]/root: ipfw zone list
    Currently defined contexts and their members:
    2: re2_vlan5, 
    4: re2_vlan6, << <that woud="" be="" the="" zone="" named="" "test"="" **the="" problem="" is="" with="" all="" zones<br="">This is on the logs portal auth (all succesful login look just like that)
    Nov 1 17:52:30 logportalauth[83715]: Zone: test - Voucher login good for 21600 min.: jxAk2Pa, 94:d8:59:56:1c:4a, 172.16.240.132

    (ipfw -x 4 show) the output from that command shows the logged in mac
    Line 240: 00244    38606    7325503 pipe 10290 ip from any to any MAC any 94:d8:59:56:1c:4a
    Line 241: 00245    39709    34493381 pipe 10291 ip from any to any MAC 94:d8:59:56:1c:4a any

    how come this mac is not on the config file…???.</that>



  • @hardy_rafael17:

    how come this mac is not on the config file…???.

    It's time to dig a little bit deeper ;)

    This line:

    Nov 1 17:52:30  logportalauth[83715]: Zone: test - Voucher login good for 21600 min.: jxAk2Pa, 94:d8:59:56:1c:4a, 172.16.240.132

    comes from the main PHP liogin page /usr/local/captiveportal/index.php. It will be logged when portal_allow returns 'true' (== a $sessionid)

    Open /etc/inc/captiveportal.inc and locate the function portal_allow()
    [ function portal_allow($clientip,$clientmac,$username,$password = null, $attributes = null, $pipeno = null, $radiusctx = null) ]
    In this function you will find ONE "write_config()"
    You will see this

    	if ($writecfg == true)
    		write_config();
    
    

    Change this for

    	if ($writecfg == true) {
    		captiveportal_logportalauth($username,$clientmac,$clientip,$type,"The config file is about to be written");
    		write_config();
    	}
    
    

    This will log a line for every portal login …..

    Alternative, more select:
    Change the code for 
    To see if it works, FIRST change "94:d8:59:56:1c:4a" with a a MAC that is you own, and login using your device on your portal 'test', a line should be logged.
    If ok, change back to "94:d8:59:56:1c:4a" -save - and wait until the line shows up (user with "94:d8:59:56:1c:4a" is logging in).

    	if ($writecfg == true) {
    		if ($clientmac == "94:d8:59:56:1c:4a") {
    			captiveportal_logportalauth($username,$clientmac,$clientip,$type,"The config file is about to be written");
    		}
    		write_config();
    	}
    
    

    All this to be sure that write_config(); is called when needed.

    After that, you could dig lower, into the write_config(); function. It's here /etc/inc/config.lib.inc



  • 	if ($writecfg == true)
    		write_config();
    
    

    Change this for

    	if ($writecfg == true) {
    		captiveportal_logportalauth($username,$clientmac,$clientip,$type,"The config file is about to be written");
    		write_config();
    	}
    
    

    This will log a line for every portal login …..

    I did as you told me…. I checked the code "I'm not a coder, that's for sure...."  now I get a new line on the logs... like this "Zone: test - : es3n6YA, cc:3a:61:32:96:dd, 172.16.100.100, The config file is about to be written"...

    But now I have another point of view on the matter... I think the "write_config()" function is being called correctly and every time needed... but... what happens if a fucntion is called while at use by another part of the code of pfsense... say vouchers for example....

    I mean... I can see on Diagnostics: Configuration History... many backups in a period of only one minute caused by  :(system): Syncing vouchers

    ![write_conf being called many times.PNG](/public/imported_attachments/1/write_conf being called many times.PNG)
    ![write_conf being called many times.PNG_thumb](/public/imported_attachments/1/write_conf being called many times.PNG_thumb)



  • @hardy_rafael17:

    But now I have another point of view on the matter… I think the "write_config()" function is being called correctly and every time needed... but... what happens if a fucntion is called while at use by another part of the code of pfsense... say vouchers for example....
    I mean... I can see on Diagnostics: Configuration History... many backups in a period of only one minute caused by  :(system): Syncing vouchers

    Depending hardware used, writing out the file could take several milliseconds, or far more …
    Checking out the write_config() function will show you the conf_mount_rw(); and counterpart.
    Also: config file access is on a one to one basis: during file modification, the access is locked. Another access on the same time (just after the first, succeeded access) will ... faill, which means the situation will not be saved to disk if another 'write_config()' is already busy doing the same thing.

    All this doesn't explains WHY you only have issues when it concerns the MAC "cc:3a:61:32:96:dd" ....

    You could try to:
    replace:

    	if ($writecfg == true)
    		write_config();
    

    for

    	if ($writecfg == true) {
    		write_config();
    		if ($clientmac == "0c:77:1a:2b:13:xx")
    		{
    			captiveportal_logportalauth($username,$clientmac,$clientip,$type,"The config file is about to be written");
    
    			$xmlconfig = dump_xml_config($config, $g['xml_rootobj']);
    			$fd = fopen("/tmp/config-dump-001", "w");
    			if ($fd != 0)
    			{
    				fwrite($fd, $xmlconfig);
    				fclose($fd);
    			}
    		}
    	}	
    
    

    You will find a file /tmp/config-dump-001 with a copy of the latest config, as it was in memory, when a the MAC was
    "0c:77:1a:2b:13:xx".
    Change
    "0c:77:1a:2b:13:xx"
    for the MAC your's after.

    Question : was it in the config array in memory before writing to disk ?

    Btw : your 'test zone' has (must !) also "Enable Pass-through MAC automatic additions" set on the Captive portal page ?! Aka: https://forum.pfsense.org/index.php?topic=101782.0



  • All this doesn't explains WHY you only have issues when it concerns the MAC "cc:3a:61:32:96:dd" ….

    Emmmmm Sorry Gertjan…. there was a miscomunication from my part...

    the problem is not with that mac only.... the problem is random...  that´s my phone´s mac address which I used to test some vouchers...

    (I tested a couple of vouchers in order to see if the problem was related to vouchers and thsis is what I found)
    *the problem is not the mac address ¨because I tested several vouchers and for some the mac got written to the config file and for some others it didin´t...
    *the problem is not vouchers because once a voucher didn´t get to the config file... I retried once or twice with the same voucher and it got writen to the config file....

    .....

    Btw : your 'test zone' has (must !) also "Enable Pass-through MAC automatic additions" set on the Captive portal page ?! Aka: https://forum.pfsense.org/index.php?topic=101782.0

    yep… I´ll attach my set up... that part is working just perfect




  • In that case : when the config.xml is written, that cycle locks another 'nearly write the same config.xml on the same time' to protect the system from race conditions.
    But : if the in memory $config isn't written right away to disk, then a next 'write_config()' will do so. …. this is what I was thinking ....

    The thing is: a new PHP instance, launched when another client visits the portal, will 'init' the in-memory $config array with what it find on … disk.

    Drop some log lines in write_config() (or lower), to see if the lock aborts because the config.xml is about to be written. If that happens, then you know that the info about that special login will be lost.

    (My saying should be confirmed be a more knowledgeable pfSense user ;))

    What are you using as a disk system ?



  • I bought from the pfsense portal a Netgate APU4 and also bought an Industrial Grade SD Card 8GB…
    well...

    at first I had NanoBSD installed on the apu4... but I was having this same problem and I thought it was due to the fact that Nanobsd wasnt always on write mode....  I managed to install full version of pfsense.... and the problem persisted...

    So my file system is on an SDCard...

    Drop some log lines in write_config() (or lower), to see if the lock aborts because the config.xml is about to be written. If that happens, then you know that the info about that special login will be lost.

    I don't know how to do that… (I'm very good at following instructions and at learning...) but you've helped too much anyways... so "thank you" if you don't feel like telling me how to do it..  (I think I would be asking too much...)


    what i'm doing now.. is making sure the voucher and mac got to the config file...
    I do that with the same device I use the voucher with....
    for example... for voucher that have been used already or expired... I have a different landing page...
    so I login with voucher XXXxXXXX... and after a succesful login I use the vouche again on the same device... and a reppeat the process once or twice intil I get the error from the portal telling me that the voucher has been used or expired...

    for some reason it only tells me that if the voucher is on the mac tab already...

    My saying should be confirmed be a more knowledgeable pfSense user ;)

    I'm on it ;)
    thanks



  • :)
    It's not that I do not want to give more 'check code' - just afraid that you might 'f*ck' up your system ;)

    A simple test - /etc/inc/captiveportal.inc:

    Change

    	if ($writecfg == true)
    		write_config();
    

    to

    	if ($writecfg == true)
    		write_config('captiveportal-portal_allow', false);
    

    This will SKIP the config.xml BACKUP generation.
    Disadvantage : no more backup file.
    Advantage : this will speed up …

    Try a little while with this patch and see what happens.

    I'm preparing a new test:
    When entering write_config(), take the time.
    When exiting write_config(), check the time again, and log the time spend in this function, to see what it takes with my system (a Dell Dimension ancient desktop PC with standard SATA interface).

    Btw, here it is :
    Change

    	if ($writecfg == true)
    		write_config();
    

    to
    Change

    	if ($writecfg == true) {
    
    		$starttime = microtime();
    
    		write_config();
    
    		$mt = "write_config took " . (microtime() - $starttime) . " milli secondes.";
    		log_error($mt);
    	}
    

    This will give you lines like this in the main log:
    Nov 5 09:58:22 php[40400]: /index.php: write_config took 0.237506 milli secondes.

    Note:
    Using:

    	write_config('captiveportal-portal_allow', false);
    

    instead of

    	write_config();
    

    didn't show any timing difference for me.


  • Banned

    Or, just get an SSD. Even the most shitty cheapo one will work wonders compared to SD/CF and similar.



  • Thanks Gertjan… I've been to busy lately....

    What I'm doing now... I'm just making sure the config file is actually getting written... that's until I get an SSD...

    Ill do as doktornotor says...

    I was actually trying to thank Gertjan not Doktornotor...


Log in to reply