Is there any particular reason why reassembled packets were not
checked? If the answer is no, I'll send in a PR.
I think it was just a random decision -- either pass packets to
the firewall before reassembly as we do, or after reassembly, as
linux does. Both have pros and cons.
Going through th
Hello,
You can look at http://www.rtems.com/ Their TCP/IP stack is derived
from FreeBSD and is probably better suited for 'extraction' than
current FreeBSD TCP/IP implementation. Also, the QNX public SVN
repository should contain QNX's fork of the NetBSD network stack as
separate resource manager.
The following reply was made to PR kern/145462; it has been noted by GNATS.
From: Gleb Smirnoff
To: Aleksey
Cc: bug-follo...@freebsd.org
Subject: Re: kern/145462
Date: Tue, 13 Apr 2010 15:36:58 +0400
IMO, this patch would be better:
Index: ng_ipfw.c
===
Hi listers,
We recently found that when the traffic passes pf with route-to, the
connection stalls.
Turning off TSO solves the problem. Our pf.conf is very simple:
table const {10/8, 172.16/12, 192.168/16}
pass out quick route-to (em0 10.1.1.1) from to ! no state
And we have a tcpdump capture
It seems as if the m_copymdata() function defined in uipc_mbuf.c has a
bug. It uses m_apply to copy data from the source mbuf to the target
but in the callback function m_bcopyxxx() the arguments are
interpreted in the wrong order. Swapping the 's' and 't' arguments in
the declaration of m_bcopyxxx
I have a question involving the userspace and kernel communication.
I need to get a point where I can exchange data between netgraph nodes and a
program in the userland.
I have a netgraph node which receives network packets and sends them to the
program to be processed. The modified packets are t
On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick
wrote:
>
> What FreeBSD version? uname -a output please.
>
I have tried 7.2-R and 8.0-R. Both version stalls, too.
8.0-RELEASE:
# uname -a
FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3
17:15:52 CST 2010 r...@bsd8:/usr/obj/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Here is a patch that addressed the issue, where when SIOCGIFDESCR is fed
with a smaller buffer. As reported by Bernhard, this would cause an
infinite loop in ifconfig(8).
The previous implementation claims that the 'length' field would be set
to
> >I think that a patch like the one you propose is very useful (for
> >ipv4 as well) but it requires a sysctl or other mechanism to make
> >sure that when it is enabled we don't pass fragments through the
> >firewall.
>
> i've looked further into this and I now wonder if is a byproduct of my
> u
