Re: using interface groups in pf tables stopped working in 13.0-RELEASE

On 16 Apr 2021, at 17:58, Kristof Provost wrote: On 14 Apr 2021, at 16:16, Peter Ankerstål wrote: In pf I use the interface group syntax alot to make the configuration more readable. All interfaces are assigned to a group representing its use/vlan name. For example: ifconfig_igb1_102

Re: using interface groups in pf tables stopped working in 13.0-RELEASE

On 14 Apr 2021, at 16:16, Peter Ankerstål wrote: In pf I use the interface group syntax alot to make the configuration more readable. All interfaces are assigned to a group representing its use/vlan name. For example: ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"

Re: [pf] stable/12: block by OS broken

On 18 Feb 2021, at 6:01, Xin Li wrote: Hi, It appears that some change between 939430f2377 (December 31) and b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the following rule: block in quick proto tcp from any os "Linux" to any port ssh would get interpreted as: block drop in

Re: latest stable13.0-ALPHA3 can not start varnish anymore.

On 2 Feb 2021, at 14:05, Johan Hendriks wrote: On 01/02/2021 22:48, Johan Hendriks wrote: I just updated my FreeBSD 13.0-APLPHA3 to the latest revision and now i can not start varnish anymore. This is on two machines. if i start varnish it errors out as the startup script does a config file

Re: Panic: 12.2 fails to use VIMAGE jails

Peter, I’m not interested in discussing software development methodology here. Please drop me from this thread. Let me know if/when you have a test case I can work from. Regards, Kristof On 9 Dec 2020, at 11:54, Peter wrote: On Tue, Dec 08, 2020 at 07:51:07PM -0600, Kyle Evans wrote: !

Re: Panic: 12.2 fails to use VIMAGE jails

On 9 Dec 2020, at 2:31, Peter wrote: On Tue, Dec 08, 2020 at 08:02:47PM +0100, Kristof Provost wrote: ! > Sorry for the bad news. ! > ! You appear to be triggering two or three different bugs there. That is possible. Then there are two or three different bugs in the production code.

Re: Panic: 12.2 fails to use VIMAGE jails

On 8 Dec 2020, at 19:49, Peter wrote: On Tue, Dec 08, 2020 at 04:50:00PM +0100, Kristof Provost wrote: ! Yeah, the bug is not exclusive to epair but that’s where it’s most easily ! seen. Ack. ! Try http://people.freebsd.org/~kp/0001-if-Fix-panic-when-destroying-vnet-and-epair-simultan.patch

Re: Panic: 12.2 fails to use VIMAGE jails

On 8 Dec 2020, at 0:34, Peter wrote: Hi Kristof, it's great to read You! On Mon, Dec 07, 2020 at 09:11:32PM +0100, Kristof Provost wrote: ! That smells a lot like the epair/vnet issues in bugs 238870, 234985, 244703, ! 250870. epair? No. It is purely Netgrh here. Yeah, the bug

Re: Panic: 12.2 fails to use VIMAGE jails

On 7 Dec 2020, at 13:54, Peter wrote: After clean upgrade (from source) from 11.4 to 12.2-p1 my jails do no longer work correctly. Old-fashioned jails seem to work, but most are VIMAGE+NETGRAPH style, and do not work properly. All did work flawlessly for nearly a year with Rel.11. If I start

Re: Commit 367705+367706 causes a pabic

the two config files closer together and found out that if I remove if_bridge from the config file and have it loaded dynamically when the bridge is created, the problem no longer happens and everything works ok. Peter On 20 Nov 2020, at 15:53, Kristof Provost wrote: I still can’t reproduce

Re: Commit 367705+367706 causes a pabic

da device ums device filemon device if_bridge On 20 Nov 2020, at 12:53, Kristof Provost wrote: Can you share your kernel config file (and src.conf / make.conf if they exist)? This second panic is in the IPSec code. My current thinking is that your kernel conf

Re: Commit 367705+367706 causes a pabic

0x809a6450 at fast_syscall_common+0x101 On 20 Nov 2020, at 11:30, Kristof Provost wrote: On 20 Nov 2020, at 11:18, peter.b...@bsd4all.org <mailto:peter.b...@bsd4all.org> wrote: I’m afraid the last Epoch fix for bridge is not solving the problem ( or perhaps creates a new ).

Re: Commit 367705+367706 causes a pabic

On 20 Nov 2020, at 11:18, peter.b...@bsd4all.org wrote: I’m afraid the last Epoch fix for bridge is not solving the problem ( or perhaps creates a new ). We’re talking about the stable/12 branch, right? This seems to happen when the jail epair is added to the bridge. There must be

Re: pf and hnX interfaces

On 13 Oct 2020, at 14:02, Eugene M. Zheganin wrote: Hello, On 13.10.2020 14:19, Kristof Provost wrote: Are these symptoms of a bug ? Perhaps. It can also be a symptom of resource exhaustion. Are there any signs of memory allocation failures, or incrementing error counters (in netstat

Re: pf and hnX interfaces

On 13 Oct 2020, at 10:58, Eugene M. Zheganin wrote: I'm running a FreeBSD 12.1 server as a VM under Hyper-V. And although this letter will make an impression of another lame post blaming FreeBSD for all of the issues while the author should blame himselm, I'm atm out of another explanation.

Re: net.pf.request_maxcount: UNDESIRABLE_OID

On 21 Aug 2020, at 8:56, Kristof Provost wrote: On 21 Aug 2020, at 8:53, Chris wrote: But why must it be a read-only OID? It doesn’t have to be, and in CURRENT it’s not: https://svnweb.freebsd.org/base?view=revision=355744 That hasn’t been MFC’d for the excellent reason that I forgot. I’ll

Re: net.pf.request_maxcount: UNDESIRABLE_OID

On 21 Aug 2020, at 8:53, Chris wrote: On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said Hi Chris, Hello, Kristof. Thanks for the reply. Nice name BTW. ;-) On 21 Aug 2020, at 2:40, Chris wrote: > We've been developing an appliance/server based on FreeBSD &&

Re: net.pf.request_maxcount: UNDESIRABLE_OID

Hi Chris, On 21 Aug 2020, at 2:40, Chris wrote: We've been developing an appliance/server based on FreeBSD && pf(4). We started some time ago, and have been using a very early version of 12. We're now collecting some 20,000,000 IP's /mos. So we're satisfied we're close to releasing. As such, we

Re: CFT: if_bridge performance improvements

On 22 Apr 2020, at 18:15, Xin Li wrote: On 4/22/20 01:45, Kristof Provost wrote: On 22 Apr 2020, at 10:20, Xin Li wrote: Hi, On 4/14/20 02:51, Kristof Provost wrote: Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge

Re: CFT: if_bridge performance improvements

On 22 Apr 2020, at 10:20, Xin Li wrote: Hi, On 4/14/20 02:51, Kristof Provost wrote: Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge. It changes the (data path) locking to use the NET_EPOCH infrastructure. Benchmarking

Re: CFT: if_bridge performance improvements

On 16 Apr 2020, at 10:36, Peter Blok wrote: Another issue I found with pf was with "set skip on bridge”. It doesn’t work on the interface group, unless a bridge exists prior to enabling pf. Makes sense, but I didn’t think of it. Other rules work fine with interface groups. I am aware of

Re: CFT: if_bridge performance improvements

to experiment with ng_bridge vs if_bridge for the same task . But I never got around to it . Do you have any insight into using one vs the other . Imho if_bridge is easier to setup and get working . --- Mark Saad | nones...@longcount.org On Apr 15, 2020, at 1:37 PM, Kristof Provost wrote: On 15

Re: CFT: if_bridge performance improvements

On 16 Apr 2020, at 8:34, Pavel Timofeev wrote: Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? I’ve not tested it, but I believe that epair scales significantly better than tap. It has a per-cpu mutex (or more accurately, a mutex in each of its per-cpu

Re: CFT: if_bridge performance improvements

On 15 Apr 2020, at 19:16, Mark Saad wrote: All Should this improve wifi to wired bridges in some way ? Has this been tested ? What sort of setup do you have to bridge wired and wireless? Is the FreeBSD box also a wifi AP? I’ve not done any tests involving wifi. Best regards, Kristof

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 16:49, Olivier Cochard-Labbé wrote: On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost wrote: The problem appears to be that /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing the `netstat -rnW` output. Shouldn't scapy use the libxo output

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 15:34, Kristof Provost wrote: On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to

CFT: if_bridge performance improvements

Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge. It changes the (data path) locking to use the NET_EPOCH infrastructure. Benchmarking shows substantial improvements (x5 in test setups). This work is ready for wider testing

Re: FreeBSD CI Weekly Report 2019-06-09

On 15 Jun 2019, at 11:35, Kristof Provost wrote: On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote: * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * Same as amd64: * sys.netinet.socket_afinet.socket_afinet_bind_zero * Others: * sys.netpfil.pf.forward.v6

Re: FreeBSD CI Weekly Report 2019-06-09

On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote: * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * Same as amd64: * sys.netinet.socket_afinet.socket_afinet_bind_zero * Others: * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 *

Re: Networking panic on 12 - found the cause

On 2019-02-12 13:54:21 (-0600), Eric van Gyzen wrote: > I see the same behavior on head (and stable/12). > > (kgdb) f > #16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800, > m=0xf8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468 > 468 switch

Re: PF problems with 11-stable

On 26 Jul 2018, at 10:16, Patrick Lamaiziere wrote: > Le Thu, 26 Jul 2018 09:58:05 +0200, > Patrick Lamaiziere a écrit : > > Hello, > >>> Hey, >>> I am on >>> 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 >>> Sun Jul 22 14:08:38 CEST 2018 >>> >>> and I see 2 problems with PF that are still there:

Re: How to setup ethernet address and IPv4 address on interface?

On 29 Jun 2016, at 13:47, Slawa Olhovchenkov wrote: > I am trying to change MAC address and setup IPv4 address and got > error: > > # ifconfig em1 ether 00:30:48:63:19:04 inet 192.168.2.1/24 > ifconfig: can't set link-level netmask or broadcast > > Is this posible? Yes, but you can’t do both in

Re: ipfw fwd to closed port

On 9 Jun 2016, at 9:06, Slawa Olhovchenkov wrote: > On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > >> On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: >>> Forwarding by ipfw to closed local port generating RST packet

Re: ipfw fwd to closed port

On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > Forwarding by ipfw to closed local port generating RST packet with > incorrect checksun. Is this know ussuse? Need open PR? Where did you capture the packet? If you've captured the packet on the machine that generated

Re: 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

> On 09 May 2016, at 16:58, Damien Fleuriot wrote: > > Since the upgrade, pf rules won't load anymore at boot time, nor even > manually with pfctl -f /etc/pf.conf : > # pfctl -f /etc/pf.conf > /etc/pf.conf:24: syntax error > pfctl: Syntax error in config file: pf rules not loaded >

Re: Reducing the need to compile a custom kernel

On 2012-02-10 14:56:04 (+0100), Alexander Leidinger alexan...@leidinger.net wrote: The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which

Re: SIOCGIFADDR broken on 9.0-RC1?

On 2011-11-15 18:10:01 (+0100), GR free...@gomor.org wrote: more insights since my last post. Here is a small code to trigger the bug (end of email). When you run it on 9.0-RC1, it gets an alias address instead of the main inet address: % ./get-ip re0 inet: 192.168.2.10 # Main