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
While chasing down an odd issue with alignment faults I activated
debugging in bin/sh.
bin/sh/Makefile has a commented out line (# DEBUG_FLAGS+= -g -DDEBUG=2
-fno-inline) to do this so that's what I did.
This fails to compile in bin/sh/jobs.c in vforkexecshell().
The debug TRACE() tries to print
Hi,
Based on the work from arm/156814 I've got a working config and device
tree for the OpenRD-CL.
It successfully boots over NFS, both network interfaces as well as the
cesa (crypto accelerator) work.
The patch:
diff --git a/sys/arm/conf/OPENRD-CL b/sys/arm/conf/OPENRD-CL
new file mode 100644
On 2013-06-14 23:07:02 (+0200), Alexander Leidinger alexan...@leidinger.net
wrote:
The bt in the minidump is useless, but I made a bt directly
in the kernel debugger:
---snip---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x0
fault code
On 2013-06-24 22:08:01 (+0200), Alexander Leidinger alexan...@leidinger.net
wrote:
On Mon, 24 Jun 2013 12:15:18 +0200
Kristof Provost kris...@sigsegv.be wrote:
For what it's worth, I'm running into exactly the same problem.
(amd64, stable/9). I have no custom settings in /etc/make.conf
On 2013-06-29 18:49:16 (+0200), Martin Matuska m...@freebsd.org wrote:
This was an obvious error by me - I forgot to register zfs_ioc_jail and
zfs_ioc_unjail using the new functions.
Amazing noone noticed this by now until it got merged down to stable/8.
In addition, I see no need to log
On 2010-04-28 15:44:29 (+0300), Alexander Motin m...@freebsd.org wrote:
I'm glad to present new driver (mvs) for several series of Marvell SATA
controllers (PCI-X, PCIe and SoC-integrated), to work with CAM ATA
infrastructure.
Driver supports following Marvell chips:
...
88SX6042,
On 2010-05-04 08:11:09 (+0300), Alexander Motin m...@freebsd.org wrote:
Kristof Provost wrote:
I've done a quick test on my Orion (88F5182) based device. It seems to
be working fine. It detects a SATA hard disk, reads/writes, ...
I wasn't able to mount a filesystem from the disk
On 2010-06-13 23:37:23 (+0900), Norikatsu Shigemura n...@freebsd.org wrote:
Hi yongari!
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On 2010-06-20 21:03:51 (+0900), Norikatsu Shigemura n...@freebsd.org wrote:
On Sun, 13 Jun 2010 22:13:31 +0200
Kristof Provost kris...@sigsegv.be wrote:
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate
The man page states that:
'-w widthWidth of ASCII-art plot in characters, default is 74.'
This is not entirely correct. The mini-help is more accurate:
'-w : width of graph/test output (default 74 or terminal width)'
In other words: the man page fails to explain that ministat will default
to
On 2015-02-23 17:23:55 (-0800), Davide Italiano dav...@freebsd.org wrote:
On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude allanj...@freebsd.org wrote:
Upgraded my router today, because it was approaching the 24 uptime days
of doom
Now, it likes to die on me, a lot
The bt you posted
On 2015-02-24 08:05:47 (+0100), Kristof Provost kris...@sigsegv.be wrote:
On 2015-02-23 17:23:55 (-0800), Davide Italiano dav...@freebsd.org wrote:
The bt you posted suggest this could be stack overflow, probably due
to infinite recursion.
Also, as a wild guess, just looking
Hi,
I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’.
Relevant backtrace bits:
#8 0x80e7dd28 in trap (frame=0xfe01f16b26a0)
at /usr/src/sys/amd64/amd64/trap.c:426
#9 0x80e5e6a2 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:235
#10
On 2015-08-09 13:36:35 (+0300), Gleb Smirnoff gleb...@freebsd.org wrote:
On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote:
K The following fixes it for me:
K
K diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c
K index 77d8940..3913ef3 100644
K --- a/sys/netinet
On 2015-11-09 21:47:01 (-0500), Shawn Webb wrote:
> I found the problem: it seems that the new Intel Haswell graphics
> support (which I've been running with) is at odds somehow with pf NAT.
> Removing Haswell graphics support means working pf NAT.
>
That's ... very
> On 02 Nov 2015, at 14:47, Shawn Webb wrote:
>
> On Sunday, 01 November 2015 07:16:34 AM Julian Elischer wrote:
>> On 11/1/15 2:50 AM, Shawn Webb wrote:
>>> I'm at r290228 on amd64. I'm not sure which revision I was on last when it
>>> last worked, but it seems VNET
On 2015-11-04 20:31:35 (-0500), Tom Uffner wrote:
> Commit r289932 causes pf rules with broadcast destinations (and some but not
> all rules after them in pf.conf) to be silently ignored. This is bad.
>
Thanks for the report.
What version did you test exactly?
There was an
> On 02 Nov 2015, at 15:07, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
>
> On Monday, 02 November 2015 02:59:03 PM Kristof Provost wrote:
>>
>> Can you add your pf.conf too?
>>
>> I’ll try upgrading my machine to something beyond 290228 to see if I c
> On 05 Nov 2015, at 17:25, Shawn Webb wrote:
> I've figured it out. I've removed all rules and went with a barebones config.
>
> Right now, the laptop I'm using for NAT has an outbound interface of wlan0
> with an IP of 129.6.251.181 (from DHCP). The following line
> On 05 Nov 2015, at 18:39, Tom Uffner wrote:
>
> Tom Uffner wrote:
>> Commit r289932 causes pf rules with broadcast destinations (and some but not
>> all rules after them in pf.conf) to be silently ignored. This is bad.
>
>> I do not understand the pf code well enough to see
> On 06 Nov 2015, at 01:12, Daniel Dettlaff wrote:
> I have interesting verbose output with backtrace (not panic) from one of my
> VMs: http://s.verknowsys.com/f0d457ce9420399baaf531012c33eb81.png
> It’s triggered by autostarting jail on bridged vlan interface (no VNET
>
On 2015-11-05 12:39:22 (-0500), Tom Uffner wrote:
> So, if my rule was "working" due to false positive in a comparison that has
> now been fixed, how many other address comparisons were affected by this
> error?
>
> There are 36 occurrences of PF_ANEQ in pf.c and 2 in
On 2015-12-23 08:08:29 (-0700), Sergey Manucharian wrote:
> I believe this is related to the fact that wifi adapter cannot have more
> that one MAC address. And that becomes true when it's a member of a
> bridge. There exist some tricky ways to overcome that though.
>
That's
> On 12 Feb 2016, at 10:18, Larry Rosenman <l...@lerctr.org> wrote:
>
> On 2016-02-11 20:50, Larry Rosenman wrote:
>> On 2016-02-11 14:40, Larry Rosenman wrote:
>>> On 2016-02-11 14:25, Kristof Provost wrote:
>>> On 11 Feb 2016, at 21:23, Larry Rosenman
> On 12 Feb 2016, at 15:29, Larry Rosenman wrote:
>
> On 2016-02-12 08:13, Larry Rosenman wrote:
>>
>> sysctl net.inet.tcp.rfc1323=0
>> makes it work
> Shouldn't the stack do the right thing here? For the record, the other side
> is also FreeBSD (10.2-STABLE).
>
Yes, but
> On 12 Feb 2016, at 15:33, Larry Rosenman <l...@lerctr.org> wrote:
>
> On 2016-02-12 08:31, Kristof Provost wrote:
>>> On 12 Feb 2016, at 15:29, Larry Rosenman <l...@lerctr.org> wrote:
>>> On 2016-02-12 08:13, Larry Rosenman wrote:
>>>&g
> On 11 Feb 2016, at 21:23, Larry Rosenman wrote:
>
> From which system(s) perspective do you want the packet captures?
> (Firewall, FreeBSD, Windows)?
I wouldn’t expect it to make much of a difference in this case.
Let’s start with whatever is easiest.
Regards,
Kristof
On 2016-02-10 20:38:02 (-0600), Larry Rosenman wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206904
>
> I've also posted lots of info to freebsd-net, and not gotten any
> response.
>
> Summary:
>
> Cable Modem-> EM0 on a pfSense Firewall (FreeBSD 10.1, pfSense
On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
There have been issues with pf if I recall correctly. I currently have
issues with stable, pf and vnet. There is an issue with pf table
entries when an interface is moved to a different vnet.
Does anyone no if there is a specific fix for
On 20 Jul 2017, at 18:24, Nikos Vassiliadis wrote:
It would be great if you use vnet jails for that. I am not
sure regarding the per-vnet pf functionality but I have seen
many bug fixes hitting the tree since last year. You can ask
on freebsd-virtualizat...@freebsd.org or freebsd...@freebsd.org
Hi,
I have a reproducible panic on CURRENT (r318136) doing
(jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual
1234
(dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var
For clarity, the receiving machine is CURRENT r318136, the sending
machine is running a somewhat older
On 16 May 2017, at 19:58, Andriy Gapon wrote:
On 16/05/2017 16:49, Kristof Provost wrote:
On 16 May 2017, at 15:41, Andriy Gapon wrote:
On 10/05/2017 12:37, Kristof Provost wrote:
I have a reproducible panic on CURRENT (r318136) doing
(jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04
On 16 May 2017, at 15:41, Andriy Gapon wrote:
On 10/05/2017 12:37, Kristof Provost wrote:
I have a reproducible panic on CURRENT (r318136) doing
(jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc
dual 1234
(dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var
For clarity
On 10 Oct 2017, at 23:10, Oleg Ginzburg wrote:
What is your FreeBSD version? This problem reproduced on FreeBSD 12
only.
/var/empty is exist and trivial test:
I’m running r324317 on CURRENT, yes.
What arguments are you calling dhclient with?
Clearly there’s a difference between what you’re
On 16 Nov 2017, at 14:04, KOT MATPOCKuH wrote:
> Hello, all!
>
> I'm got same problem...
>
Can you show how you call dhclient? What FreeBSD version are you running?
What’s the output of `sysctl kern.chroot_allow_open_directories`?
Regards,
Kristof
___
Hi,
I’d like to make it easier to avoid integer overflow issues in the
kernel.
It’d be a lot nicer to have a malloc function figure this out for us,
so I’d like mallocarray().
https://reviews.freebsd.org/D13766
Are there any objections to this?
Regards,
Kristof
On 25 Aug 2018, at 0:26, Matthew Macy wrote:
On Fri, Aug 24, 2018 at 15:25 Shawn Webb
wrote:
Hey All,
Somewhere in the last month or so, a use after free was introduced. I
don't have the time right now to bisect the commits and figure out
which commit introduced the breakage. Attached is
On 25 Aug 2018, at 9:06, O. Hartmann wrote:
I'm using ezjail-admin from ports (most recent tree, up to date as of
today, at Revision:
478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25
07:10:45 CEST 2018 amd64,
the jails sources are at revision 338309).
Updates of the jail's base
On 25 Aug 2018, at 0:47, Kristof Provost wrote:
On 25 Aug 2018, at 0:26, Matthew Macy wrote:
On Fri, Aug 24, 2018 at 15:25 Shawn Webb
wrote:
Hey All,
Somewhere in the last month or so, a use after free was introduced.
I
don't have the time right now to bisect the commits and figure
memguard on the memory type in question is extremely useful
in
catching use after free.
-M
On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote:
On 25 Aug 2018, at 0:47, Kristof Provost wrote:
On 25 Aug 2018, at 0:26, Matthew Macy wrote:
On Fri, Aug 24, 2018 at 15:25 Shawn Webb
wrote:
Hey All
On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote:
On Mon, Apr 09, 2018, Kristof Provost wrote:
On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
For several days buildworld fails for me with the following
error. Cleaning
and
rebuilding didn't help.
===> tests/sys/netpfil
On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
For several days buildworld fails for me with the following error.
Cleaning and
rebuilding didn't help.
===> tests/sys/netpfil/pf/ioctl (all)
--- validation ---
(cd /usr/src/tests/sys/netpfil/pf/ioctl &&
DEPENDFILE=.depend.validation
On 18 Oct 2018, at 11:33, Ernie Luzar wrote:
Wanting to get a head start on using 12.0 and vnet jails with in jail
firewall.
1. Will Vimage be compiled as a module in the 12.0 kernel and be
included in the base system release?
vimage is a kernel option, not a module. It affects the entire
> On 28 Oct 2018, at 12:56, Ernie Luzar wrote:
>
> Bjoern A. Zeeb wrote:
>>> On 28 Oct 2018, at 15:31, Ernie Luzar wrote:
>>> Tested with host running ipfilter and vnet running pf. Tried loading pf
>>> from host console or from vnet console using kldload pf.ko command and get
>>> this error
On 28 Oct 2018, at 14:39, Rodney W. Grimes wrote:
Bjoern A. Zeeb wrote:
On 28 Oct 2018, at 15:31, Ernie Luzar wrote:
Tested with host running ipfilter and vnet running pf. Tried
loading
pf from host console or from vnet console using kldload pf.ko
command
and get this error message;
On 29 Oct 2018, at 4:41, Kristof Provost wrote:
So we panic because we dereference a NULL pointer in strncmp(), which
happens because nprogtab = 13 but ef->progtab[12] has NULL pointers.
It’s not clear to me why that happens, but it’s something to go
on. I do wonder if this isn’t a
On 30 Oct 2018, at 14:29, Bjoern A. Zeeb wrote:
On 30 Oct 2018, at 12:23, Kristof Provost wrote:
I’m not too familiar with this part of the vnet code, but it looks
to me like we’ve got more per-vnet variables that was originally
anticipated, so we may need to just increase the allocated space
On 16 Sep 2018, at 23:05, Eric van Gyzen wrote:
On 9/15/18 1:06 AM, Kurt Jaeger wrote:
Can you disable all the options of the NIC ?
ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag
-vlanhwcsum -vlanhwtso
Try to disable everything that can be disabled, e.g. LRO etc.
Disabling
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
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
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
*
On 22 Apr 2019, at 12:25, Enji Cooper wrote:
Either the sys/netinet/ or sys/netipsec/ tests triggered the panic.
Not sure which right now.
That looks to be happening during a vnet jail teardown, so it’s likely
the sys/netipsec or sys/netpfil/pf tests.
I’ve done a quick test with the pf
On 31 Jan 2020, at 7:34, Clay Daniels wrote:
I've started running kyua test when I load the weekly current
snapshot, and
I'm a little confused about if I should run kyua test as user or root.
In
order to make the /usr/ports/devel/kyua port you need to be root and I
have
just been doing the
On 12 Mar 2020, at 16:58, Ronald Klop wrote:
Hi,
Clean build after svn update gives:
cc: error: no such file or directory:
'/data/src/freebsd-current/contrib/llvm-pr
oject/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
cc: error: no input files
*** [ittnotify_static.pico] Error
not to be able to MFC these changes back to 12, but
that may be possible after all.
There is an experimental patch set for stable/12 here:
https://people.freebsd.org/~kp/if_bridge/stable_12/
Best regards,
Kristof Provost
___
freebsd-current@freebsd.org
.
Best regards,
Kristof Provost
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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
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
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 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
Hi,
As this is the first status report sent to a wider audience I’ll try
to give a bit of background information.
I’m working on a performance improvement project for if_bridge. Right
now it’s a big bottleneck for a number of different scenarios (e.g.
for VNET jail or VM hosts).
if_bridge
svg
I’ll give D245250 another week or two for reviews. It’s a relatively
small patch, considering, but it’s complex and important.
I also intend to add another test case for a cleanup issue that’s
since been fixed in D245250.
Best regards,
Kristof Prov
Hi,
This week I got a prototype patch running, along the ideas discussed
last week. Essentially, we keep the BRIDGE_LOCK for any add/delete of
interfaces or rt entries, but use CK_LIST and epoch in the data path.
This is a relatively straightforward change, and currently passes the
regression
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
a bit more testing in CURRENT first.
The Foundation wrote about this project here:
https://www.freebsdfoundation.org/blog/500-if_bridge-performance-improvement/
There will be an in-depth article on this work in the upcoming May/June
issue of FreeBSD Journal.
Best regards,
Kristof Provost
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 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
to approach the
epoch-ification now, and hope to have a functional prototype in a few
weeks.
Best regards,
Kristof Provost
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
On 3 Sep 2020, at 19:56, Chris wrote:
Why was the intention to switch NOT announced as such MUCH sooner?
There was discussion about a possible switch to git on the freebsd-git
mailing list as early as February 2017:
https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html
On 11 Sep 2020, at 19:06, Gleb Smirnoff wrote:
> Kristof,
>
> can you please take a look? IMHO, the problem is that with r360345
> the bridge_ioctl() is fully covered by epoch. IMHO, should be either
> more fine grained covered, or use internal locking, because some of
> the code downstream
On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
Quoting Kristof Provost (from Sun, 27 Sep 2020
17:51:32 +0200):
Here’s an early version of a task queue based approach:
http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch
That still needs to be cleaned up
On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
Quoting Kristof Provost (from Mon, 28 Sep 2020
13:53:16 +0200):
On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
Quoting Kristof Provost (from Sun, 27 Sep 2020
17:51:32 +0200):
Here’s an early version of a task queue based
On 23 Sep 2020, at 19:37, xto...@hotmail.com wrote:
> Kristof Provost wrote:
>> On 21 Sep 2020, at 2:52, Shawn Webb wrote:
>>>> From latest HEAD on a Dell Precision 7550 laptop:
>>>
>>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
&g
On 21 Sep 2020, at 14:16, Shawn Webb wrote:
On Mon, Sep 21, 2020 at 09:57:40AM +0200, Kristof Provost wrote:
On 21 Sep 2020, at 2:52, Shawn Webb wrote:
From latest HEAD on a Dell Precision 7550 laptop:
https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
The last working boot
On 30 Sep 2020, at 13:52, Alexander Leidinger wrote:
Quoting Kristof Provost (from Tue, 29 Sep 2020
23:20:44 +0200):
On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
Quoting Kristof Provost (from Mon, 28 Sep 2020
13:53:16 +0200):
On 28 Sep 2020, at 12:45, Alexander Leidinger wrote
On 21 Sep 2020, at 2:52, Shawn Webb wrote:
>> From latest HEAD on a Dell Precision 7550 laptop:
>
> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
>
> The last working boot environment was 14 Aug 2020. If I get some time to
> bisect commits, I'll try to figure out the culprit.
>
On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote:
On 23 Jul 2020, at 8:09, Kristof Provost wrote:
On 23 Jul 2020, at 9:19, Kristof Provost wrote:
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
> So, it's pretty easy to trigger, just attach a couple USB ethernet
> adapters, in my case, they were ure, but likely any two spare ethernet
> interfaces will work, and wire them back to back..
>
I’ve been able to trigger it using epair as well:
On 23 Jul 2020, at 9:19, Kristof Provost wrote:
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare
ethernet
interfaces will work, and wire them back to back..
I’ve
On 29 Dec 2020, at 4:33, monochrome wrote:
sry forgot details:
source tree @ ead01bfe8
git -C /usr/src checkout gf20c0e331
error: pathspec 'gf20c0e331' did not match any file(s) known to git
what is the 'g' for?
That would have been a typo, I think.
git -C /usr/src checkout f20c0e331
M
On 27 Nov 2020, at 9:29, tech-lists wrote:
What's the "best" [1] choice for firewalling these days, in the list's
opinion?
There's pf, ipf and ipfw. Which is the one being most recently
developed/updated?
I'm used to using pf, have done for over a decade. But OpenBSD's pf
has diverged a lot
On 22 Dec 2020, at 22:06, bob prohaska wrote:
> On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote:
>>
>> what does "pkg install git" do for you? NB: I use "pkg install git-lite".
>> Prevents about 1000 dependencies.
>>
>
> That seems to have worked. It reported something about package
On 22 Dec 2020, at 22:50, Mark Millard wrote:
On 2020-Dec-22, at 13:31, Mark Millard wrote:
Clone
https://git.FreeBSD.org/src.git
anon...@git.freebsd.org:src.git
g...@gitrepo.freebsd.org:src.git
Hmm. It turns out that the last 2 are links on that page and the
links expand out to:
On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
Its for ever dead code on a large number of machines that do not have
the hardware for it. I know that is a decreasing set, but imho it
would be better to somehow ONLY load the module if you had CPU
support for it. The down side is that
On 11 Mar 2021, at 9:51, Ronald Klop wrote:
Hi,
This
https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h
includes libifconfig_sfp_tables.h which does not exist.
My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig,
but no succes.
The last change in these
On 13 Feb 2021, at 21:58, Alexander V. Chernikov wrote:
It turns out we're leaking some ifas for loopback interfaces on VNET
teardown:
There’s a recent bug about this as well: 253998.
The problem’s been around for a long time though. The pf tests trigger
it from time to time, although it
On 15 Feb 2021, at 22:09, Daniel Ponte wrote:
I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c
from
12.2-STABLE, throughput on my WAN interface (the box runs pf) is
incorrectly showing double in systat -if, as well as in vnstat and
pftop
from ports. The LAN interface does
On 16 Feb 2021, at 0:58, Daniel Ponte wrote:
On Mon, Feb 15, 2021 at 10:25:47PM +0100, Kristof Provost wrote:
On 15 Feb 2021, at 22:09, Daniel Ponte wrote:
I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c
from
12.2-STABLE, throughput on my WAN interface (the box runs pf
On 22 Dec 2021, at 8:21, Konrad Sewiłło-Jopek wrote:
> Hi,
>
> I think the reason is somewhere in tools/build/test-includes:
>
> --- net/if_pfsync.o ---
> In file included from net/if_pfsync.c:1:
> In file included from
> [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56:
>
> On 18 Nov 2021, at 11:43, Marcin Wojtas wrote:
> czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisał(a):
>>
>>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote:
>>>
>>> As of b014e0f15bc7 the ASLR (Address Space Layout
>>> Randomization) feature becomes enabled for the all 64-bit
>>>
On 16 Feb 2022, at 11:31, qroxana wrote:
> It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39
>
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @
> /usr/src/sys/net/if_epair.c:165
> stack backtrace:
> #0
On 9 Feb 2022, at 10:57, Gary Jennejohn wrote:
> test-includes uses pf.h when checking usage of pfvar.h.
>
> But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
> set in src.conf:
>
> .if ${MK_PF} != "no"
> INCSGROUPS+= PF
> .endif
>
> This breaks buildworld. The error message:
On 18 Jan 2022, at 3:07, Gleb Smirnoff wrote:
> * Another factor - scapy. The python scapy library would emit warning to
> stderr
> if it sees interface without any IP address. This happens right at 'import
> scapy'.
> The test suite considers a test failed if it has something on stderr,
Hi Mark,
On 14 Sep 2023, at 7:37, Mark Millard wrote:
> This change leads the port net/py-libdnet to be broken:
>
> --- fw-pf.lo ---
> fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
> ^
> fw-pf.c:252:22: error: use of undeclared
On 14 Sep 2023, at 15:34, Mark Millard wrote:
> [I've cc'd a couple of folks that have dealt with fixing
> breakage in the past.]
>
I’ve submitted a fix for libdnet in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273899 because it blocks
net/scapy, which we rely on for tests.
I do not plan
On 5 Oct 2023, at 19:34, Steve Kargl wrote:
> On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote:
>> Hi Steve,
>>
>> On 5 Oct 2023, at 17:36, Steve Kargl wrote:
>>> In case anyone else is using openvpn.
>>>
>>> % pkg info openvp
> On 6 Oct 2023, at 08:46, Steve Kargl
> wrote:
>
> On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote:
>>
>> I'll ping you off list when it's available.
>>
>
> Well, this is interesting. I cannot upload the files to
> a location from which I can then put them up on freefall.
On 10 Oct 2023, at 19:26, FreeBSD User wrote:
> Hello,
>
> at first: observation is below, marked [OBSERVATION].
>
> Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef:
> Mon Oct 9 14:00:42
> CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface
>
Hi Steve,
On 5 Oct 2023, at 17:36, Steve Kargl wrote:
> In case anyone else is using openvpn.
>
> % pkg info openvpn
> openvpn-2.6.6
> Name : openvpn
> Version: 2.6.6
> Installed on : Tue Sep 19 08:48:55 2023 PDT
> Origin : security/openvpn
> Architecture :
1 - 100 of 102 matches
Mail list logo