2.0.3 Image Testing

Slam

jikjik101: I saw your post last night just before I planned a clean reinstall of pfSense and thought I'd try the auto config restore from USB

http://doc.pfsense.org/index.php/Automatically_Restore_During_Install

It worked fine except my package reinstalls were bungled, but apart from that it restored all my settings.

jimp

I just ran two tests on the latest snapshot:

1. I edited the config down to just the DHCP section ( <dhcpd>[…]</dhcpd> ) made some obvious changes and then restored that using the DHCP Server section selection. It worked.
2. I restored the original full config from before I made the DHCP edits, and it rebooted and came up with the right config.

No problems that I can see.

Perhaps you fed it the full config and chose only a specific section? That doesn't work on 2.0.x. If you restore a single section you have to edit the file so it only contains that single section. That does work on 2.1 though.

heper

saw something in system log that seems a bit odd.
it doesn't seem to cause many problems, but i figured i'd better post it in case it is something to be worried about.

see screenshot

enjoy :)

lighttpd_ssl_error.png_thumb

jimp

Not really worth worrying about. We started putting the lighttpd logs into syslog now, those kinds of errors are normal from time to time people just never saw them before.

Lighty will log an SSL error like that if a client connects that doesn't do SSL, or resets the connection, etc. Could be any of a few things that result in that error, but it's not usually worth digging at since it's more of a browser-vs-web server issue.

Xon

@jimp:

Switch to quagga. :-)

OpenOSPFD will often try to add and/or remove routes multiple times. Which works on OpenBSD, but not on FreeBSD, which is one of the reasons we chose to move away from it.

Last time I tried to install quagga, it nuked the OpenBGPD bgpd binary. I know the quagga package has a warning about interaction with OpenOSPFD, but it would be nice for that to be updated to include OpenBGPD too.

A warning that OpenBGPD and RIP routed dont play nicely together would be a nice to have.

jimp

@Xon:

@jimp:

Switch to quagga. :-)

OpenOSPFD will often try to add and/or remove routes multiple times. Which works on OpenBSD, but not on FreeBSD, which is one of the reasons we chose to move away from it.

Last time I tried to install quagga, it nuked the OpenBGPD bgpd binary. I know the quagga package has a warning about interaction with OpenOSPFD, but it would be nice for that to be updated to include OpenBGPD too.

A warning that OpenBGPD and RIP routed dont play nicely together would be a nice to have.

I added a note to the pkg descriptions, but that is really an issue for the package repo that doesn't have anything to do with 2.0.3 images.

jimp

A new set of images went up a bit ago that has a completely recompiled set of ports, so it would help if everyone could give everything a good shake-down again to make sure nothing regressed.

webdawg

Does this have any fixes for the mpd/ppp client? I am having a problem with the UML260 USB modem that I never had with any previous releases.

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

radius_voucher_disconnect.png_thumb

radius_voucher_re-auth.png_thumb

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.