On 2011-11-15 18:10:01 (+0100), GR 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 address b
On 2012-02-10 14:56:04 (+0100), Alexander Leidinger
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 you add which you can
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 c
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 q
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"
ifcon
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
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 (pfil_run
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
* sys.netpfil.pf.set_tos.
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
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 now.
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 2020-0
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
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 outp
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
___
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 str
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
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 this
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
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.
It
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
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 &&
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&revision=355744
That hasn’t been MFC’d for the excellent reason th
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. The
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 or in
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 something
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 ).
Requires scbus
and 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 th
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
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 2-
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 i
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
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.
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:
!
> 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
>
> The proble
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 it tcpdump may inde
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 wrote:
>>> Forwarding by ipfw to closed local port generating RST packet with
>>> incorrect
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 on
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:
38 matches
Mail list logo
