similar to: build world failed on pflogd

Dear ALL! Maybe someone can help me with my problem? I have no adea what is happening with my packets :( I have 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 box running pf. And i have ipcad daemon running (installed from ports) pf.conf says pass quick on lo0 all and when i'm trying to rsh to ipcad that is listening on anna# netstat -a|grep shell tcp4 0 0 localhost.shell *.*

Hello from ealier 6.0 there is problem with synproxy in pf filter: this one 6.1-PRERELEASE #2: Wed Mar 15 02:02:37 MSK 2006 pf.conf just with single rule pass in quick on lo0 proto tcp from any to any port 22 flags S/SA synproxy state result telnet 127.0.0.1 22 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. and it's hangs pfctl -s rules -v No ALTQ support in

>Submitter-Id: current-users >Originator: Janos Mohacsi >Organization: NIIF/HUNGARNET >Confidential: no >Synopsis: pf does not use IPv6 interface addresses at startups >Severity: serious >Priority: low >Category: bin >Class: sw-bug >Release: FreeBSD 6.2-STABLE i386 >Environment: System: FreeBSD scone.ki.iif.hu 6.2-STABLE FreeBSD 6.2-STABLE #23: Wed May 9 18:23:24

This looks like a very cool feature addition to RELENG_7! Are there any performance penalties that you know of with this built in ? ---Mike At 09:13 PM 7/23/2008, Julian Elischer wrote: >julian 2008-07-24 01:13:22 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > contrib/pf/pfctl parse.y > lib/libc/sys

Tinc OpenBSD masquerading firewall users: I just found that in OpenBSD's 3.2 and greater kernel, the packet filter (pf) added the ability to specify a source port for NATing. Therefore, my UDP rig outlined in my last post is not a desirable solution for OpenBSD users. I am unsure if Darren Reed's ipf has a similar function (pf's syntax was originally based on Darren Reed's

Hello, I've sent a similar query before, but didn't receive any answers. When upgrading from 9.1 to 9-STABLE, the buildworld fails with: ===> usr.bin/xinstall (all) cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall

TB --- 2013-11-19 23:00:41 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-19 23:00:41 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-19 23:00:41 - starting RELENG_10 tinderbox run for sparc64/sparc64 TB --- 2013-11-19 23:00:41 - cleaning the

Hi all. When building procstat I get this: clang -O2 -pipe -march=athlon-xp -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs

Older GCC versions (e.g. < 4.9) may complain about inline functions that cannot be inlined (growing the generated code). It is not really a problem for us, so just suppress again the warning. Followup of commit c37c554fc56151b709882b382bb5fa26d9083449. --- m4/guestfs_c.m4 | 1 + 1 file changed, 1 insertion(+) diff --git a/m4/guestfs_c.m4 b/m4/guestfs_c.m4 index 7250294..ea26202 100644 ---

On 2020-04-01 15:12, Greg Troxel wrote: > D'Arcy Cain <darcy at VybeNetworks.com> writes: > But yet, new packets from that IP address reach asterisk. It seems > almost entirely clear to me that you have a firewall problem, not an > asterisk problem. This could well be but Asterisk is the only thing that continues to communicate. > I would test this out with a remote

Dear Sirs, we're having some inconviniences on files used in a private system, developed to "suit" the company. this system's files are located in /var/wsystems and permissions are granted 4777 acordingly to all files. When we start up and work in this system with ONE user alone, we have no problems whatsoever... however when we start up the whole intranet in this system, most

Dear Sirs, we're having some inconviniences on files used in a private system, developed to "suit" the company. this system's files are located in /var/wsystems and permissions are granted 4777 acordingly to all files. When we start up and work in this system with ONE user alone, we have no problems whatsoever... however when we start up the whole intranet in this system, most

On 2/04/2020 6:35 AM, D'Arcy Cain wrote: > On 2020-04-01 16:28, Mark Boyce wrote: >> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com >> <mailto:gdt at lexort.com>> wrote: >>> I think you need to use tcpdump and turn up firewall debugging. >> sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > block drop in log quick on bge0

I am running Asterisk 16.9 on FreeBSD 12.1-RELEASE-p1. I keep seeing lines like this in my logs. [Apr 1 13:30:33] NOTICE[101155][C-00004526] chan_sip.c: Call from '' (45.143.220.235:5356) to extension '2037' rejected because extension not found in context 'unauthenticated'. I have a script that checks for things like this and adds them to my packet filter (pf).

D'Arcy Cain <darcy at VybeNetworks.com> writes: > Here is the first four lines from "pfctl -sr": > > pass in quick on bge0 from <FRIENDS> to any flags S/SA keep state > block drop in log quick on bge0 from <ENEMIES> to any > block drop in log quick on bge0 from <AUTOBLOCK> to any > block drop out log quick on bge0 from any to

On 2/04/2020 5:28 AM, Mark Boyce wrote: > On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com > <mailto:gdt at lexort.com>> wrote: >> >> I think you need to use tcpdump and turn up firewall debugging. > > sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > > Mark Or the stateful entry still exists when the table entry is updated.

On 2020-04-02 08:01, Larry Moore wrote: > I suspect you have a good understanding of pf. Pretty good I think. As with everything I am always willing to learn more. > Have you included in your script running 'pfctl -k <ip_address>' to kill > any states that may exists after you update your <AUTOBLOCK> table? I haven't yet because I want to watch the effect of

After fixing some warnings (see prior commits), we can now enable them in configure.ac. --- m4/guestfs_c.m4 | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/m4/guestfs_c.m4 b/m4/guestfs_c.m4 index e91446f..7250294 100644 --- a/m4/guestfs_c.m4 +++ b/m4/guestfs_c.m4 @@ -43,22 +43,15 @@ fi dnl This, $nw, is the list of warnings we disable. nw= nw="$nw

Posting because I haven't seen this yet. I have been getting this error on 2 boxes for the last 2 days. Both boxes: root at Shop:/usr/src # svn info /usr/src/ Path: . Working Copy Root Path: /usr/src URL: svn://kryten.nina.org/src/stable/9 Relative URL: ^/stable/9 Repository Root: svn://kryten.nina.org/src Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255501 Node Kind:

TB --- 2012-12-11 03:57:29 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-12-11 03:57:29 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-12-11 03:57:29 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2012-12-11 03:57:29 - cleaning the