I can not concur. I have built up my network over many years with m0n0wall prior to t1n1wall and did not see this bug. In fact, the bug is not present in t1n1wall 1.8.2b branch, but is present in the 1.10.2b branch. On 12/1/2015 1:34 AM, Anonymous wrote: I recall running into this issue before with m0n0wall. This isn't a new bug introduced since the t1n1wall fork. Looks like some old code needs to be reworked.
fixup system.inc after commenting out kldload aesni
build aesni into kernel
more freebsd12 changes
changes for freebsd 12
add freebsd 12 branch
update trust anchor for dnssec
fix ip6 port display in state table view
fix clear log button when displaying raw logs
set hostname before starting syslogd
remove libpkg, remove dupe libipsec
fix syslog formatting
update syslogd.c.patch
update scripts to support r351411 (libpcap on amd64 links libs we don't need, syslogd changes)
update Mk in ports
add some new storage, usb and network drivers
fix NAT port range behavior
add kernel support for sdhci for SD card support on APU2, APU3
Firewall Log Display Filtering
will mark as fixed
Possible memory leak in snmpd
i'll mark this as fixed, I don't see a leak after it running either
Status: Traffic graph Rates
can you try r163, this should be fixed
DHCP option boot-filename is invalid
I've just posted a 'fix'. this will require both a filename and next server to be set. next-server and tftp-server and clients that use bootp vs dhcp seems to be an area of mixed results. there are old clients like some ip phones, that might need dhcp and bootp options. hopefully with setting dhcp-no-override, it will work with all clients.
fix typo in pfmon.c
DHCP option boot-filename is invalid
fix boot race for ntp server resolution
fix up pfmon.c
fix traffic graph stats.c
can you try r162, this should be fixed
can you try r162 , this should be fixed