2.0.3 Image Testing

[jimp]

Not that I recall specifically.

http://doc.pfsense.org/index.php/2.0.3_New_Features_and_Changes
https://github.com/bsdperimeter/pfsense/commits/RELENG_2_0

[heper]

I've just noticed a possible captive portal issue.
i can't say if this existed in previous releases because it's my first time using Captive Portal with vouchers + win2008r2 radius for user auth.

situation:
Wednesday last week i've implemented a school-wide CP+voucher+AD auth. (I've installed the pre-release because there were CP issues on 2.0.2)
All appears to be working well.

• I can connect a client(laptop/smartphone) using vouchers or AD-login

• I disconnect this client

• After a while (couple of minutes) the client disappears from the CP-status-GUI

the issue is this:
The idle timeout field is set to 10minutes
For whatever reason, it appears that (some) idle client-sessions don't get removed, and stay "active" until I restart the CP service.
On monday i first noticed this, restarted CP. Today i checked again and there were 60+ "active" sessions that were started more then 24h's earlier.

idle timeout field in the cp gui is not (allways)respected. Today (2013-02-07) i've seen "active" sessions that got started this monday (2013-02-04).

I've tried the GUI option to use the idle-timeout from radius server … This makes the CP unusable with vouchers. It appears that when said CP tries to auth vouchers to the AD?

Hope someone can clarify this. This could be a configuration issue, but as basic functionality appears to be working, my gut tells me it's something else.

Kind regards,

Jeroen

[jimp]

That should be fixed in the snapshot that is up now, Ermal made commits to fix it yesterday.

[heper]

it's amazing that your question gets answered when you are still re-editing your post because it was filled with typos

thanks for the heads up on the new snapshot … will attempt an update tomorrow and will report back if needed

[heper]

I can confirm that the CP Idle-timeout issue has been fixed, but it might have created a different problem.

With the new update i'm unable to use 'reauthenticate users every minute'.
Since last snapshot (2013-02-06), whenever i enable that option the vouchers stop working. After a minute the vouchers get disconnected by RADIUS ?
Radius disconnects them because the use 'ACLKwskqzj12434XSlksk' is not found in Active Directory =)

When i disable 'reauthenticate users every minute' vouchers seem to work again, but i lose my ability to use a radius-time-schedule for my AD users.
Could anyone involved have another look

See screenshots for clarification

Kind regards

[Nachtfalke]

@heper:
Could this be related to this ?
http://redmine.pfsense.org/issues/2155

[heper]

@Nachtfalke:

@heper:
Could this be related to this ?
http://redmine.pfsense.org/issues/2155

EDIT:that appears to be the exact issue yes. It's not the exact issue, it is related tho. Vouchers work for around 1 minute, then they get "disconnected". I think the initial voucher-authentication works fine. the re-authentication (every minute) however, is also applied to vouchers and send to Radius/AD. Radius is unfamiliar with the voucher-code-user and sends "disconnect"

for whatever reason last weeks snapshot didn't have the issue, but perhaps it just didn't send auth requests every minute, and the new builds do ?

[Nachtfalke]

@heper:

@Nachtfalke:

@heper:
Could this be related to this ?
http://redmine.pfsense.org/issues/2155

EDIT:that appears to be the exact issue yes. It's not the exact issue, it is related tho. Vouchers work for around 1 minute, then they get "disconnected". I think the initial voucher-authentication works fine. the re-authentication (every minute) however, is also applied to vouchers and send to Radius/AD. Radius is unfamiliar with the voucher-code-user and sends "disconnect"

for whatever reason last weeks snapshot didn't have the issue, but perhaps it just didn't send auth requests every minute, and the new builds do ?

For curiosity I opened this bug on redmine when there was only pfsense 2.0.0 available if I remember correct. So this bug must have been gone and now is there again !?
Perhaps this is a sideeffect of something else.

[heper]

i've just noticed something very similar is happening with "Use RADIUS Session-Timeout attributes"

Vouchers being checked against radius timeout,  resulting in disconnect

[webdawg]

The MPD issue I am having has to do with the auto reconnect (dial on demand mode).  I have found the only way I can get my ppp to reconnect is if I check it and set idle to 0.  I think it was like this in the previous releases.

The directions for the dial on demand mode are misleading.  They say not to check this box if you want your connection to be up all the time.

[heper]

anyone can confirm if the CP radius things can still be fixed for 2.0.3 or will it have to wait for 2.1/2.2 ?

[cmb]

2.0.3 will fix only regressions between 2.0.1 and 2.0.2, and a few minor fixes that have little chance of creating fallout. The above voucher+RADIUS issue won't.

[senser]

I am currently using the nanobsd 2.0.2 4G version. Can I use the upgrade file to only update one of the two slices?

[jimp]

@senser:

I am currently using the nanobsd 2.0.2 4G version. Can I use the upgrade file to only update one of the two slices?

Update files only update one NanoBSD slice. That's how they've always worked. You can boot back to the other slice if needed.

[senser]

great, I didn't know that. Not a whole lot of commits to the 2.0 release branch for some time now.
when I install a prerelease - how would i update to 2.0.3 once it's released? would I have to reinstall? Thx

[jimp]

Regular firmware update like any other. If your auto update url is pointed to the 'stable' updates, you'll get it when it's released.

[senser]

I've updated! The only issue for me was a long delay at boottime because my packages didn't reinstall. Or did they? Directly after the update i accidently loaded my old slice and all my packages got reinstalled into that one. Then, next reboot, i booted into the "new" slice and the firewall took ages to load and all packages were missing. I manually the packages and all is good now. It seems strange though that the package update was triggered when I was booting the old slice (I have updated running from slice number two, maybe thats related).

just to clarify, here are my messy upgrade steps:

i was running slice 2 when i started the update.
on reboot i chose to boot slice 2 ouch* and it reinstalled all packages
reboot into slice1: no packages

[jsquyres]

FWIW, I upgraded to the latest image (13 Feb 1243), but I'm still having the problem that I initially reported here:

http://forum.pfsense.org/index.php/topic,57258.0.html

That thread eventually got hijacked to be a different issue (but also related to DHCP), but the original problem still remains.  This is a regression since pfsense 2.0.1.

[jimp]

That thread didn't get hijacked, it was the main issue. The interface going down/up wasn't properly relaunching dhclient, and that should be fixed now. Several others with that same issue confirmed it was fixed for them. If there is a separate issue, then you can keep posting in that thread to continue investigating, or start a new one. The symptoms will be (at least slightly) different now, and it warrants further diagnosis.

[senser]

php: /system_advanced_sysctl.php: The command '/sbin/sysctl hw.syscons.kbd_reboot="0"' returned exit code '1', the output was 'sysctl: unknown oid 'hw.syscons.kbd_reboot''

smallish glitch in current 2.0.3 pre. That variable is gone I guess?