If I'm not wrong, lighthhtpd is the daemon behind the webConfigurator (the http admin interface). Noone without me have access this, and I usually get access via ssh, exeptionally with http. Why this client get access to lighthhtpd? I think that if it is a normal issue, it doesn't print message in console.

Thank you jump. Your suggested stems seems to have worked. Now my DHCP demon is running.

Yes, that definitely fixed the issue… [image: 14y3cid.png]

@athurdent: And now I don't know why something like that would work at all. Well, technically it can work with SO_REUSEADDR however it still is not something I'd do in this case… :-) Say, you have this: 0.0.0.0:443   127.0.0.1:443 will be OK and working with SO_REUSEADDR enabled on a socket before binding it However, this: 127.0.0.1:443   127.0.0.1:443 or this combo: 0.0.0.0:443   0.0.0.0:443 will result in EADDRINUSE no matter whether SO_REUSEADDR is on or off.

@phil.davis: That happens to me sometimes, I have systems upgrading on slow links. If a new build finishes while the upgrade is downloading, then you get the upgrade file (maybe half of it is the end of the new file?), but the sha256 checksum by then is one for the new upgrade file. It's tough after I leave a system downloading 78MB over an hour or more, ke garne? pheri koshis garnu par6 - what to do? have to try again. Yep, that is exactly what happened. While downloading July 10 build, new snapshots of July 11 released and that could be the case. Right now I am upgrading to July 11 build. Thanks Phil for sharing your experience.

Is this the way it's supposed to be?

@jimp: OK I confirmed that adding a rule to pass IPv6 from LAN subnet to any does pick up the correct delegated prefix subnet, so those rules really don't need to exist. I just pushed a commit to take them out. Cool, thanks. 8)

This is strange, because mpd should start after system recognizes the usb devices…

Today accidentally I found that I have the same problem like described here - http://forum.pfsense.org/index.php?action=profile;u=232265;sa=showPosts and the reason why CUPS really wants directory to be created manually is that I am using ramdisk feature. When I disable it, CUPS logs are empty and directories are created automatically. This looks like some non critical "cosmetic" bug/feature that can affect other packages too, so be  careful  before adding something that uses var or tmp.

After doing more testing, even when using the main interface as the local endpoint for the GRE tunnels, the devices are not put into the running state upon boot, I see the devices created and configured, but they dont have the running flag. If i login to the console and do a ifconfig gre0 up, they receive the running flag and pass traffic. The issue with them not being configured at all if the local endpoint is a CARP interface still exists as well. Thanks, Jon

Thanks jimp! I shall go the classic FreeBSD way (my preferred way, too) ;-)

Should I make new bug reports for my issues?

As of know no. Probably can be discussed for 2.2

@stephenw10: http://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write  :) Steve /etc/rc.conf_mount_rw and /etc/rc.conf_mount_ro makes me feel easy. :-) Thanks, Steve! :-)