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 wit
Howdy,
Does anyone know the reason for this particular check in
ip_output.c?
if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
/*
* This case can happen if the user changed the MTU
* of an interface after enabling IP on it. Becaus
At Fri, 7 Sep 2012 01:28:16 -0700,
Anuranjan Shukla wrote:
>
>
> >
> >> struct socket {
> >>
> >>int so_fibnum; /* routing domain for this socket */
> >>uint32_t so_user_cookie;
> >> + u_int so_oqueue; /* manage send prioritizing based on
> >>application
> >> needs */
> >
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=123
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=123
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/
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 gi
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.
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?
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 bac
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 generat
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 m
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 man
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'
e1000_api.o(.text+0xae8):../../../dev/em/e1000_api.c:34
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 t
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 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
___
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 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. C
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 pack
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_pul
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
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 l
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
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. :-)
> >
> > Goo
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,
> >>> Jo
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.
>
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 s
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
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
> variabl
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
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 for
At Tue, 23 Dec 2008 13:57:39 +0200,
Vladimir V. Kobal wrote:
>
> With fastforwarding off the system works well and boots without panicing.
>
OK, that narrows it down. Are you using any filtering such as PF,
ipfw, etc.?
Best,
George
___
freebsd-net@fre
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 l
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 sta
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 n
Hi,
I'm going to take a look over these changes as well.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi,
There is now a patch here:
http://people.freebsd.org/~gnn/fast_ipv6.20070406.diff
which follows the current state of my radical_ipsec p4 branch.
The patch removes Kame derived IPsec from the tree, and adds v6
support to FAST_IPSEC. The IPSEC kernel option is removed, but the
FAST_IPSEC
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
>
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
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
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
http://lists.freebsd.org/mailman/listinfo/fre
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]"
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 code
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
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
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
___
fre
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]"
teway after rtfree(), 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 -
/so
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 pat
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
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 t
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 virtuali
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 o
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 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
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 -> t
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
>
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 packe
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 cxgb
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=8843 metric 0 mtu 9000
options=1bb
ether 00:07:43:05:20:43
inet 172.16.0.1 n
OK, one more data point.
The issue is somewhere between RC2 and CURRENT. I just put RC2 on the
same box, and RC1 can talk to RC2 over the Chelsio cards.
I have now tried RC2 and CURRENT and still no dice.
Best,
George
___
freebsd-net@freebsd.org mai
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
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
_
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 */
IN_MULTI
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
> (c08af130
At Thu, 13 Mar 2008 20:58:25 -0400,
James Snow wrote:
>
> [1 ]
> 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
> > and the "zero" net
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 record
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 un
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 alm
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
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 network
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 desc
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 whe
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?
> > >
> > > http://people.freebsd.org/~delphij/misc/
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 traf
At Mon, 05 May 2008 06:31:25 +0800,
kevin wrote:
>
> Hi, all
> I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel.
> My OS kernel is GPL licenced.
> Is it possible for me to modify 4.4BSD-Lite's source code and change its
> licence from 4.4BSD-Lite licence to GPL licence?
>
Ala
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
Jun 9 18:23:59 ... kernel: em0: 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 failed
Jun 9 18:23:59 ... kernel: device_attach: em0 atta
At Tue, 12 Oct 2004 12:52:15 -0600,
Stephane Raimbault wrote:
>
> I have some busy boxes part of a cluster which seems to occassionaly get an
> Error 49 on various network based applications at the same time.
>
> Here is from an apache proxy log
>
> [Fri Oct 08 11:26:45 2004] [error] (49)Can't
Hi,
This patch fixes PR 44355 which was really an issue of FreeBSD
not keeping up with the Kame code. I'd like an approval from
Robert to commit this, and comments from anyone else familiar
with this code in case I've missed something.
This fixes the case
Howdy,
Here is a proposed set of diffs for locking fixes in the
scope6.c module. Please let me know anyone has questions or
comments.
Thanks,
George
Index: scope6.c
===
RCS file: /Volumes/exported/FreeBSD-CV
Hi Folks,
Enclosed please find my updated patch for scope6 locking for
the IPv6 code in FreeBSD-CURRENT. The major change was to
remove the IFNET list locking because this actually needs to
be done outside of the IPv6 code and to add address family
(AF) dat
At Thu, 28 Oct 2004 15:32:29 -0700,
Bruce M Simpson wrote:
> Please see my attached game plan.
>
I think it looks like a good plan. Unnumbered interfaces have other
uses than dhclient and it would be good to have clean support for
them.
Later,
George
At Tue, 9 Nov 2004 15:07:37 -0500,
James wrote:
>
>
> Does anybody know of any IPv6 traffic generators, to stress test v6 routers?
> No need for setting hop by hop options, 6to4 tunneling, etc options. just
> plain
> unicast v6 packet generator.
>
NetPipe now has IPv6 integrated into it. I do
Have you also forwarded this to Kame for comment?
I will try to take a look at this this week.
Later,
George
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
At Mon, 15 Nov 2004 17:23:10 -0500,
James wrote:
> Attached is initial code for ip6_fastforward() that I'm proposing
> for FreeBSD 5.x. This code was written for an internally modified
> FreeBSD 4.9, however in the next few weeks, I will be porting this
> into FreeBSD 5.3 tree and submit a final d
Hi Folks,
Some of us (Bruce, Juli, John-Mark and I) have embarked on a
project, named Dingo, to clean up and extend our network
stack. The web page for this is both in CVS
(www/en/projects/dingo) and on the web
(http://www.freebsd.org/projects/dingo/index.h
At Fri, 03 Dec 2004 15:39:24 +0100,
Michal Mertl wrote:
>
> [1 ]
> I looked at the project page and noticed one thing I found code for.
>
> Task: Rework code in FreeBSD's ip_icmp.c such that ICMP responses for
> forwarding can be throttled also. Call badport_bandlim() before icmp_error()?
>
>
At Wed, 8 Dec 2004 13:22:10 +0100,
Konstantin KABASSANOV wrote:
>
> [1 ]
> Hello,
>
> I have a freebsd box with a gif tunnel configured. I observed that even if
> ifconfig displays MTU 1500 for both gif and physical interface, 1300 bytes
> ipv6 packets transiting on the gif interface are systema
At Thu, 09 Dec 2004 17:52:15 +0900,
jinmei wrote:
> (Perhaps this is slightly an off-topic for this list, but) I'm also
> interested in the reason, but it's not surprising that someone in the
> world has a negative impression on a big feature like IPv6 or IPsec,
> since such a thing has typically b
e about branch views.
Branch: gnn_dingo
Update: 2004/12/19 03:17:21
Access: 2004/12/19 03:17:26
Owner: gnn
Description:
My personal sub-branch of the dingo branch.
Options:locked
View:
//depot/projects/dingo/sys/... //depot/user/gnn/dingo/sys/...
//depot/p
At Sun, 19 Dec 2004 12:32:27 -0500,
Bosko Milekic wrote:
> You develop in your individual branch, test your changes. If all is
> well, you push into dingo, where changes get tested with respect to
> other dingo-related changes (which have not yet been pushed into HEAD).
> When it's all ready, ever
At Mon, 20 Dec 2004 19:28:21 +,
Lee Johnston wrote:
> Does any one have any ideas on this? Could the kernel option (options HZ)
> which we use for dummynet/polling effect the rate in which ARP requests are
> issued?
>
> I had planned to place each subnet in a VLAN, and looks like this will h
At Mon, 20 Dec 2004 15:57:36 -0800,
Brooks Davis wrote:
>
> [1 ]
> On Sun, Dec 19, 2004 at 01:23:43PM +0900, [EMAIL PROTECTED] wrote:
> > Howdy,
> >
> > For those who use PerForce and want to work on Dingo there is
> > now a dingo branch, named "dingo". The dingo branch contains
> >
At Mon, 3 Jan 2005 01:31:29 -0600 (CST),
Mike Silbersack wrote:
> For the life of me, I can't figure out why SYN packets (other than delayed
> retransmissions of the original SYN) would ever show up once a connection
> is in the ESTABLISHED state.
They "shouldn't" and I think ignoring them mak
At Fri, 7 Jan 2005 11:34:03 +0530,
Manish Sapariya wrote:
>
> Hello,
> Can anybody suggest me freely available test suite for tcp/ip implementation.
> Are there any avalilable?
If you mean something that can veryify an RFC or do packet by packet
testing then the answer is, "Not yet."
There are
1 - 100 of 204 matches
Mail list logo
