Yeah i fixed the issues you mentioned just 2 days before.
For same filename you might have issues and i have to give a look for that.

@DerTrickreiche:

What I found out ist, that it won't boot from a fresh copyed nanobsd-Image if there ist no USB-keyboard detected.

Hi Harry, thanks for the suggestion. I tried plugging an Apple USB keyboard into my pfSense box. The keyboard was detected, but pfSense still failed to boot with the same Root Mount Error:

Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 ugen4.2: <apple, inc.="">at usbus4 uhub5: <apple, 2="" 9="" inc.="" keyboard="" hub,="" class="" 0,="" rev="" 2.00="" 96.15,="" addr="">on usbus4 uhub5: 3 ports with 2 removable, bus powered Root mount waiting for: usbus4 ugen4.3: <apple, inc="">at usbus4 Trying to mount root from ufs:/dev/ufs/pfsense0 ROOT MOUNT ERROR:</apple,></apple,></apple,>

Pete

Kernel and GUI patches made it into the latest build. Everything working fine as far as I can see so far, except that code point VA went missing from the drop-down-box. Sorry, my fault. Will add it when time permits during the next few days.

@Klaws:

I don't have the issue. Is it perhaps present only on systems with ipv6 enabled?

Well, not here with HE IPv6 tunnel with IPv6 enabled on WAN, LAN, WLAN and OpenVPN.

@pfSenseRocks:

I reproduce the issue. I worked around it by selecting the interfaces on the NTP settings page.

I did that on my system and the only difference was that my system is now listening on an interface I did add later. So that was a good advice  ;)

But according to the log file the TS posted the last line said that NTPD is listening and running.

Ok i think i found what caused this : the set tos of packet option was selected, it seems that if i remove that option, restart of openvpn doesn't fail… quite odd it doesn't fail at the first start.

This bug https://redmine.pfsense.org/issues/3062

I have recently upgraded to July 2 version and am now experiencing the same problems.

From the Diag -> Ping on the WAN interface I can get to google… but not from a device on the LAN.

Yes and I have a rule for rsync which uses the gateway group.

The problem revolved around an error in a function in the captiveportal.inc, is corrected in this link. http://redmine.pfsense.org/issues/3062

After studying a little PHP I could find the problem and fix it myself, here is the solution.
;)

http://redmine.pfsense.org/issues/3062

There should be a mechanism for udp sockets like nat uses to choose the right source ip or the application can overwrite the source ip.

For linux there is a multihome option for openvpn which uses source ip routing.

@jimp:

Open a ticket on http://redmine.pfsense.org/ and point to the patch, or if you can work out our patch format, you can submit a pull request that integrates the patch.

Thanks Jimp, I will see what I can figure out regarding the patch format, I'm a linux guy but I will give it a whirl, thanks. :)

This is pfSense and we like to do things from the GUI :)
Go to advanced tunables and set the value there.

Maybe it is related : I have a permanent rate of interrupt (detected by Munin) which is really high : 70% of my first CPU. Usually, the rate is arround 0.

How can I debug this issue ?

Thanks

Dom

Large ranges of forwarded ports can interfere with DNS answers. Typically, DNS clients use UDP and then try TCP if UDP failed, but I have observed a case where this didn't work (but wasn't on pfSense…).

Yup, works.