gnn accepted this revision.
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D26757/new/
REVISION DETAIL
https://reviews.freebsd.org/D26757
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences
gnn accepted this revision.
gnn added a reviewer: gnn.
This revision has a positive review.
REVISION DETAIL
https://reviews.freebsd.org/D9847
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: kczekirda, oshogbo, bapt, tsoome, glebius, freebsd-net-list
gnn accepted this revision.
This revision has a positive review.
REVISION DETAIL
https://reviews.freebsd.org/D8905
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
honzhan_microsoft.com
gnn added a comment.
Not my comment "once everyone agrees" :-)
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, network, glebius, adrian, delphij,
decui_mic
gnn added a comment.
Let's keep this moving along. Mike isn't (yet) a committer but if someone
can commit this once everyone agrees that would be great.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences
gnn closed this revision.
gnn added a comment.
I believe we can close this.
REVISION DETAIL
https://reviews.freebsd.org/D1777
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: rrs, imp, rwatson, lstewart, kib, adrian, jhb, bz, sbruno, gnn
Cc: ae, bz
gnn added a comment.
Any update on this?
REVISION DETAIL
https://reviews.freebsd.org/D1944
To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn
Cc: freebsd-virtualization, freebsd-pf, freebsd-net
___
freebsd-net@freebsd.org mailing
gnn accepted this revision.
gnn added a comment.
BTW Mike Karels was in favor of this in an email thread. He's not yet on
phabricator but I'll ask him here as well.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1965
To: erj, adrian, jfvogel, gnn
Cc: glebius, freebsd-net
gnn accepted this revision.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1691
To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1708
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1698
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1705
To: arybchik, gnn
Cc: freebsd-net
gnn requested changes to this revision.
gnn added a comment.
This revision now requires changes to proceed.
If you look at other drivers you'll see they have #define'd macros for the
locks, rather than direct calls. This allows us to name the lock in the macro.
See, for instance, this example
gnn requested changes to this revision.
gnn added a comment.
This revision now requires changes to proceed.
__predict_false rarely, if ever, does the right thing. Have you run any
benchmarks to show that this improves performance?
REVISION DETAIL
https://reviews.freebsd.org/D1697
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1704
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1703
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1702
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1706
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1701
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
REVISION DETAIL
https://reviews.freebsd.org/D1692
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1700
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1699
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1694
To: arybchik, gnn
Cc: freebsd-net
gnn accepted this revision.
gnn added a reviewer: gnn.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1309
To: rodrigc, bz, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv,
rpaulo, adrian, gnn, hiren, rwatson
Cc: freebsd-virtualization
gnn added a comment.
No objection from me.
REVISION DETAIL
https://reviews.freebsd.org/D1201
To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo,
adrian, bz, gnn, hiren, rwatson
Cc: freebsd-net, emaste, gnn, rwatson
At Tue, 8 May 2012 12:11:20 +0200,
Gergely CZUCZY wrote:
Hello,
I'd like to ask a few question in order to get some hardware to work
we've got recently.
The hardwares are the following:
- 2x dualport Mellanox ConnectX-3 VPI cards, with 56Gbps ports
- 4 computing modules with a
Synopsis: [panic] panic while restarting net/freenet6
Responsible-Changed-From-To: gnn-n...@freebsd.org
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:13:33 UTC 2010
Responsible-Changed-Why:
http://www.freebsd.org/cgi/query-pr.cgi?pr=123758
Synopsis: [panic] panic while restarting net/freenet6
Responsible-Changed-From-To: n...@freebsd.org-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:14:53 UTC 2010
Responsible-Changed-Why:
Give this one back.
http://www.freebsd.org/cgi/query-pr.cgi?pr=123758
Synopsis: [lor] Deadlock with FASTIPSEC and nat
Responsible-Changed-From-To: gnn-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:18:21 UTC 2010
Responsible-Changed-Why:
I believe this is fixed but others can comment on it at will.
http://www.freebsd.org/cgi/query
Synopsis: IPsec connection stops working if associated network interface goes
down and then up again.
Responsible-Changed-From-To: gnn-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:34:03 UTC 2010
Responsible-Changed-Why:
This is probably not longer valid given
Synopsis: FreeBSD freezes on mbufs exhaustion (network interface independent)
Responsible-Changed-From-To: gnn-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:35:12 UTC 2010
Responsible-Changed-Why:
5.3 bug, probably no longer relevant.
http://www.freebsd.org/cgi
Synopsis: IPSEC can't detunnel GRE packets after real ESP encryption
Responsible-Changed-From-To: gnn-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:47:06 UTC 2010
Responsible-Changed-Why:
This is likely stale.
http://www.freebsd.org/cgi/query-pr.cgi?pr=65616
Synopsis: IPsec tunnel (ESP) over IPv6: MTU computation is wrong
Responsible-Changed-From-To: gnn-freebsd-net
Responsible-Changed-By: gnn
Responsible-Changed-When: Tue Jun 15 17:47:41 UTC 2010
Responsible-Changed-Why:
I'm not working on IPSec at the moment, handing this one back.
http
At Sat, 24 Jan 2009 16:20:06 +,
Rui Paulo wrote:
On 24 Jan 2009, at 12:54, Yony Yossef wrote:
Hi All,
I'm facing a temporary network hang on my interfaces following a flood
ping/stress udp test.
I'm running a netperf UDP test which is giving results but does not
return
At Tue, 23 Dec 2008 22:49:24 +0200,
Vladimir V. Kobal wrote:
We are using pf+ALTQ for shaping and ipfw for filtering, diverting into
netgraph nodes, attaching altq queues.
OK, that also makes sense given what I saw in the code. Can you
explain your entire setup? That is, which filters,
At Tue, 23 Dec 2008 13:00:12 -0800,
julian wrote:
g...@freebsd.org wrote:
Hi,
I just checked in a small tool to HEAD in
/usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect
ethernet packets just about the driver layer without involving the
protocol stacks. This is
Hi,
I just checked in a small tool to HEAD in
/usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect
ethernet packets just about the driver layer without involving the
protocol stacks. This is useful for people doing low level testing of
drivers and switches. If you happen to be
Hi,
Can you try this with fastforwarding off? It looks like a double free
somewhere in the ip_fastforward() routine. Someone frees m but does
not NULL it out and at the drop: label the mbuf m is valid but the
data within it has already been freed. Knowing if this is related
only to the fast
At Wed, 24 Sep 2008 15:50:32 +0100,
Bruce M. Simpson wrote:
Hi,
I agree with the intent of the change that IPv4 and IPv6 input queues
should have a tunable queue length. However, the change provided is
going to make the definition of IFQ_MAXLEN global and dependent upon a
variable.
At Wed, 24 Sep 2008 12:53:31 -0700,
John-Mark Gurney wrote:
George V. Neville-Neil wrote this message on Tue, Sep 23, 2008 at 15:29 -0400:
It turns out that the last time anyone looked at this constant was
before 1994 and it's very likely time to turn it into a kernel
tunable. On hosts
Hi,
It turns out that the last time anyone looked at this constant was
before 1994 and it's very likely time to turn it into a kernel
tunable. On hosts that have a high rate of packet transmission
packets can be dropped at the interface queue because this value is
too small. Rather than make a
At Wed, 24 Sep 2008 00:17:18 +0400,
Ruslan Ermilov wrote:
Hi,
On Tue, Sep 23, 2008 at 03:29:06PM -0400, [EMAIL PROTECTED] wrote:
It turns out that the last time anyone looked at this constant was
before 1994 and it's very likely time to turn it into a kernel
tunable. On hosts that
At Fri, 29 Aug 2008 18:28:53 +0200,
Luigi Rizzo wrote:
and to be more explicit - the result of m_pullup is that
the number of bytes specified as m_pullup argument are in
a private piece of memory -- the 'data' region within the mbuf -- so
you can freely play with them without trouble.
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I have tried it and it does fix my problem. RIP2 over multicast works
again. :-)
Good to hear. I'm
At Tue, 26 Aug 2008 17:56:13 -0700,
Sam Leffler wrote:
[EMAIL PROTECTED] wrote:
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I
At Fri, 22 Aug 2008 03:27:11 +0100,
Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix is
to m_pullup() the udp
At Fri, 22 Aug 2008 21:42:00 +0200,
Luigi Rizzo wrote:
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue? Since this packet is only going into the
At Fri, 22 Aug 2008 19:43:03 +0100,
Bruce M. Simpson wrote:
We end up calling if_simloop() from a few interesting places, in
particular the kernel PIM packet handler.
In this particular case we're going to take a full mbuf chain copy every
time we send a packet which needs to be looped
At Fri, 22 Aug 2008 22:43:39 +0100,
Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
Hi,
Turns out there is a bug in the code that loops back multicast
packets. If the underlying device driver supports checksum offloading
then the packet that is looped back, when it is transmitted on the
wire, is incorrect, due to the fact that the packet is not fully
copied.
Here is a patch.
At Thu, 21 Aug 2008 22:35:19 +0200,
Luigi Rizzo wrote:
On Thu, Aug 21, 2008 at 03:11:56PM -0400, [EMAIL PROTECTED] wrote:
Hi,
Turns out there is a bug in the code that loops back multicast
packets. If the underlying device driver supports checksum offloading
then the packet that is
Hi Jack,
Thanks for this and for the concise pciconf line. We use em (soon to
be igb) interfaces extensively at work.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
At Sun, 20 Jul 2008 16:07:29 -0700,
Kip Macy wrote:
Actually, I'd like to re-factor multiple parts of socketvar in to
separate files.
Please provide feedback on the following:
http://www.fsmware.com/socketvar_refactor.diff
Looks good to me.
Best,
George
At Tue, 15 Jul 2008 10:35:57 -0700,
Jack Vogel wrote:
OK, will put on my todo list :)
Thanks. A kernel built that way (i.e. with igb and em) does actually
work, which is good, but if you're going to split them up we should
get this right before 7.1.
Best,
George
At Mon, 14 Jul 2008 14:53:16 -0700,
Jack Vogel wrote:
Just guessing, did someone change conf/files maybe??
If you build a STABLE kernel with igb AND em then things work and the
kernel uses em.
I'm not sure which thing needs to be changed in conf/files or
otherwise though.
Later,
George
At Tue, 15 Jul 2008 10:07:22 -0700,
Jack Vogel wrote:
Oh, so the problem is if igb alone is defined?
Yes.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
A, thanks,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Howdy,
As of today, this afternoon, I see the following:
linking kernel.debug
e1000_api.o(.text+0xad9): In function `e1000_setup_init_funcs':
../../../dev/em/e1000_api.c:343: undefined reference to
`e1000_init_function_pointers_80003es2lan'
At Thu, 10 Jul 2008 11:43:23 +0100 (BST),
rwatson wrote:
On Wed, 9 Jul 2008, [EMAIL PROTECTED] wrote:
I would assume that if a card, say the em, has hardware TX checksum that
the
UDP checksum could be calculated by the hardware, but this seems not to be
the case. The manual pages
I would assume that if a card, say the em, has hardware TX checksum
that the UDP checksum could be calculated by the hardware, but this
seems not to be the case. The manual pages are unhelpful in this regard.
Thanks,
George
___
freebsd-net@freebsd.org
At Thu, 26 Jun 2008 23:25:18 -0400,
Paul wrote:
I have a FreeBSD router set up with Full BGP routes and I'm doing some
tests on using it for routing.
7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008
amd64
oddness..:
Use a packet generator to generate random
Jun 9 18:23:59 ... kernel: em0: Intel(R) PRO/1000 Network Connection
Version - 6.7.3 port 0x2000-0x201f mem 0xd802-0xd803,0xd800
-0xd801 irq 18 at device 0.0 on pci4
Jun 9 18:23:59 ... kernel: em0: Using MSI interrupt
Jun 9 18:23:59 ... kernel: em0: Setup of Shared code
Howdy,
I have developed the attached patch which extends the functionality of
netstat (via the -x flag) to show us all the socket buffer
statistics. The kernel change counts mbufs, as well as clusters (at
the moment of any size) and gives output like this:
Proto Recv-Q Send-Q Local Address
At Tue, 22 Apr 2008 06:35:38 -0700,
Chris Pratt wrote:
On Apr 21, 2008, at 12:43 AM, [EMAIL PROTECTED] wrote:
...snip
Well there are plenty of us motivated to get at these issues. Can you
do me a favor and characterize your traffic a bit? Is it mostly TCP,
The traffic that
At Sun, 20 Apr 2008 09:53:49 -0700,
Chris Pratt wrote:
On Apr 20, 2008, at 2:43 AM, Robert Watson wrote:
On Fri, 18 Apr 2008, Chris Pratt wrote:
Doesn't 7.0 fix this? I'd like to see an official definitive
answer and all I've been going on is that the problem description
is
At Sun, 20 Apr 2008 10:32:25 +0100 (BST),
rwatson wrote:
On Fri, 18 Apr 2008, [EMAIL PROTECTED] wrote:
I am wondering why this patch was never committed?
http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround
It does seem to address an issue I'm seeing where processes
At Mon, 21 Apr 2008 16:46:00 +0900,
[EMAIL PROTECTED] wrote:
At Sun, 20 Apr 2008 10:32:25 +0100 (BST),
rwatson wrote:
On Fri, 18 Apr 2008, [EMAIL PROTECTED] wrote:
I am wondering why this patch was never committed?
At Thu, 17 Apr 2008 18:35:23 -0700 (PDT),
vijay singh wrote:
Hi all. How do we avoid a race in populating the ifindex_table? Id
this is a TODO, as it seems from the code below, would it be
acceptable if I wrote a patch and reused the ifnet_lock
[IFNET_WLOCK, IFNET_WUNLOCK]?
It is almost
At Thu, 17 Apr 2008 21:00:04 -0700,
Kip Macy wrote:
I would like to MFC TOE and RDMA support in the last week of May /
first week of June. My primary objective is that it be present in 7.1.
The re team has not yet decided when the freeze date for 7.1 will be,
so I may end up asking to do it
Hi,
I am wondering why this patch was never committed?
http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround
It does seem to address an issue I'm seeing where processes get into
the zonelimit state through the use of mbufs (a high speed UDP packet
receiver) but even after
Synopsis: no response to ICMP traffic on interface configured with a link-local
address
State-Changed-From-To: open-patched
State-Changed-By: gnn
State-Changed-When: Thu Apr 17 12:51:46 UTC 2008
State-Changed-Why:
User submitted a patch which is now applied and tested.
Take over bug until
Howdy,
I have just finished updating a new tool in src/tools/tools/mctest
which is a multicast test program. The mctest program works by
sending packets from a source to a sink over using a multicast address
and then the sink reflects the packets it receives back to the
source. The source
At Thu, 13 Mar 2008 20:58:25 -0400,
James Snow wrote:
[1 text/plain; us-ascii (7bit)]
On Thu, Mar 13, 2008 at 08:40:07PM -0400, James Snow wrote:
Also, I took a cue from the IN_LINKLOCAL() macro and added two new
macros to sys/netinet/in.h to perform checks for the loopback network
At Fri, 29 Feb 2008 13:44:27 -0600,
Kevin Day wrote:
This is from 7.0-RELEASE:
lock order reversal:
1st 0xc3bde2b8 rtentry (rtentry) @ netinet6/nd6.c:1930
2nd 0xc3af367c radix node head (radix node head) @ net/route.c:147
KDB: stack backtrace:
db_trace_self_wrapper
FYI this is fixed by a one line change that is about to hit 6-STABLE:
@@ -991,7 +991,6 @@
* a new record. Otherwise, we are done.
*/
if (ifma-ifma_protospec != NULL) {
- if_delmulti_ent(ifma); /* We don't need another reference */
At Wed, 20 Feb 2008 18:25:05 +,
Bruce M Simpson wrote:
I just noticed that whilst the socket code appears to support
IPV6_TCLASS, we don't document it.
I haven't raised a PR for this issue yet nor have I written a patch.
Please do both :-)
Thanks,
George
At Tue, 19 Feb 2008 14:00:56 +,
Bruce M. Simpson wrote:
Rob Watt wrote:
Hi.
We recently upgraded some of our machines to 6.3-RELEASE and we have been
plagued by repeatable panics when our multi-cast client applications exit.
Our machines have Intel X5365 processors, LSI MegaSAS
At Wed, 13 Feb 2008 00:52:52 -0800,
Kip Macy wrote:
Oops sorry ... What is the output of 'sysctl dev.cxgbc.0'?
Here ya go, and thanks!
Later,
George
nozomi8# ifconfig cxgb0
cxgb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 9000
At Thu, 7 Feb 2008 15:16:44 +0100,
Michael Tuexen wrote:
Dear all,
I was able to build an IPv4 only kernel by having
options INET
#options INET6
in the kernel config file.
Is it supposed to work that one can build a IPv6-only
kernel by using
#options INET
options INET6
I have not
At Thu, 07 Feb 2008 19:45:28 +0400,
Tofig Suleymanov wrote:
Hello list,
I will be grateful if someone could point me to the right direction
regarding the question below.
My device driver is getting incoming packets fine, but for some reason I
am not able to send a single packet. Here
Hi,
I have two MP/Multicore Xeon boxes with CX4 based Chelsio cards in
them. If I boot 7.0-RC1 the cards can talk to each other. If I build
a recent kernel/world (for instance from today) I cannot ping between
them. I have tried using GENERIC as wella as a custom kernel.
kodama8# ifconfig
At Thu, 31 Jan 2008 13:15:12 +0100 (CET),
Ingo Flaschberger wrote:
Dear Andre,
2) linux method:
Look for CONFIG_TCP_MD5SIG in linux-2.6.24/net/ipv4/tcp_ipv4.c
(sorry no weblink..)
They check and block md5-packets early in tcp_v4_do_rcv.
afinet.c - tcp_v4_rcv -
At Thu, 17 Jan 2008 15:06:19 -0500,
randall wrote:
[EMAIL PROTECTED] wrote:
Howdy,
At my current gig we find that the network interface locks up if we
subject it to a high rate of multicast traffic. Since the whole
purpose of this box is to do multicast (it absorbs a feed of data
Howdy,
At my current gig we find that the network interface locks up if we
subject it to a high rate of multicast traffic. Since the whole
purpose of this box is to do multicast (it absorbs a feed of data over
multicast manipulates and then sends it out again over multicast) it's
a bad thing if
At Sun, 6 Jan 2008 13:47:24 + (GMT),
rwatson wrote:
There's also the opportunity to think about whether it's possible to
harden things in such a ways as to not give up our flexibility to
keep maintaining and improving TCP (and other related subsystems),
yet improving the quality of
At Wed, 26 Dec 2007 16:26:11 -0800,
julian wrote:
Resending as my mailer made a dog's breakfast of the first one
with all sorts of wierd line breaks... hopefully this will be better.
(I haven't sent it yet so I'm hoping)..
---
On thing where
At Fri, 28 Dec 2007 20:40:30 +0100,
Marko Zec wrote:
The thrust behind Julian's work seems to be providing multiple
forwarding tables for for purposes of traffic engineering / policy
based routing, with a single firewall instance used as a classifier.
vimage-style network stack
At Fri, 30 Nov 2007 17:00:25 -0800,
julian wrote:
The following diff removes some (whart looks to me to be) duplicate code.
Anyone care to comment before I commit it?
(I'm trying to imagine a case where it does something useful to do this twice
but not really succeeding).
It's a
At Mon, 29 Oct 2007 10:45:17 -0700,
Jack Vogel wrote:
I have an important decision to make and I thought rather than just make
it and spring it on you I'd present the issues and see what opinions were.
Our newer hardware uses new features that, more and more, require
parallel code paths in
(), a potential
race not to mention a use-after-free.
I haven't checked Coverity for this, but it just doesn't look right.
At least in the ND6 case I think that the correct logic is:
//depot/user/gnn/ipsec_seven/src/sys/netinet6/nd6_nbr.c#1 -
/sources/p4/user/gnn/ipsec_seven/src/sys/netinet6
Thanks to all who responded. I'll check out the links.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Howdy,
A very slightly off topic question for [EMAIL PROTECTED] Does anyone know of a
web site that collects and indexes canonical packet traces for network
protocols? I'm looking for a good storehouse of traces to use in
testing.
Best,
George
___
At Thu, 26 Jul 2007 11:13:53 +0800,
blue wrote:
Hi, all:
Recently I found the behavior for the command setkey -FP is quite
different for the latest version IPsec (known as FAST_IPSEC before).
Before the command would erase all the existed SP entries; currently the
command would not.
At Wed, 11 Jul 2007 13:49:37 +0200,
Peter Blok wrote:
Hi George,
Is somebody looking at ipsec-tools? As far as I can see it requires a
lot of kame definitions, although not used most of the times. I have
tried to make sense of this, but it wasn't easy.
I am not right now, if you have
Hi,
My most recent check-in moves FreeBSD HEAD, soon to be 7.0 into the
post Kame era. What was once FAST_IPSEC has been made into IPSEC and
the Kame IPsec code has been removed from the tree. We will continue
to use and update the Kame IPv6 code but of course there will be no
more drops of
Hi,
I am about to commit IPv6 support for FAST_IPSEC to HEAD. The tree may
not build for a short while, I will email again when this process is
complete.
Best,
George
___
freebsd-net@freebsd.org mailing list
Please let myself of bz@ know of any issues. I'm attempting a build
of a fresh tree now.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
have re's permission) in the next few days so that I
have the weekend to work on other issues that come up with the code.
There have been various patches out for a while (to be found in
www.freebsd.org/~gnn) but it is clearly time to remove the KAME IPsec
which is unlocked and unmaintained and move
Howdy,
In preparation for changes in CURRENT, aka 7.0, I have produced a
patch that removes Kame IPsec and adds support for IPv6 to
FAST_IPSEC. I have produced a patch which applies and compiles here:
http://people.freebsd.org/~gnn/fast_ipv6.20070617.diff
I am still testing the kernel I built
At Sat, 7 Apr 2007 12:16:00 +0200,
Jeremie Le Hen wrote:
Hi, Bruce,
On Sat, Apr 07, 2007 at 05:27:30AM +0100, Bruce M. Simpson wrote:
I'm all for this in principle. I believe that the case for FAST_IPSEC
over KAME IPSEC is fairly clear for those of us who have read the USENIX
paper.
1 - 100 of 188 matches
Mail list logo
