> > Unfortunately my diagnostic tools do not let me see what is going
> > on on the wire, whether the spacing is larger than it should be,
actually i managed to instrument the driver and the spacing
between interrupts (with a change similar to the one you
proposed -- i make them occur every N pac
hi
i installed freebsd4.2 and
kame-20010212-freebsd42-snap and tried IPSEC connections.
ESP mode worked fine with
kame(racoon) but I couldn't get AH mode connection.
Following is the error
messages.
keTest# Feb 14 10:48:31 IkeTest /kernel: checksum mismatch in
IPv4 AH in
Luigi Rizzo wrote:
> I am trying to generate (send only) packets at maximum rate on a
> 100Mbit ethernet, which means using 64-byte packets and, once you
> do the math (counting preamble, packet and inter-packet gap),
> results in some 148.000 packets-per-second (and just to get the
> idea, this
> I have had no problem doing line rate w/fxp and a p3 500 (well not to say
> no problem, but it is achievable). In my experience the biggest overheads
you mean with min-sized packets ? what version of freebsd ? I'd
be interested to repeat this.
> are ip_output() and routing lookups. If you can'
On Tue, 13 Feb 2001, Luigi Rizzo wrote:
> Hi,
> don't know how many of you have ever tried this...
>
> I am trying to generate (send only) packets at maximum rate on a
> 100Mbit ethernet, which means using 64-byte packets and, once you
> do the math (counting preamble, packet and inter-packet ga
Hi,
don't know how many of you have ever tried this...
I am trying to generate (send only) packets at maximum rate on a
100Mbit ethernet, which means using 64-byte packets and, once you
do the math (counting preamble, packet and inter-packet gap),
results in some 148.000 packets-per-second (and j
Garrett Wollman writes:
> > ISTR at one time you would instead get the actual sockaddr of the
> > just-closed socket, rather than a bogus sockaddr... and that is the
> > behavior one would expect.
>
> As itojun pointed out, accept() used to just block if the socket it
> thought it was going to gi
Mike Bytnar wrote:
>
> Is this a bug or have I misunderstood?
> Why is it possible to say "out recv "? Or for that matter, "in
> xmit "?
>
> bridge# ipfw add 500 pipe 2 ip from any to any out recv xl1
> 00500 pipe 5 ip from any to any out recv xl1
if the filter is called from ip_outpu
> Is this a bug or have I misunderstood?
> Why is it possible to say "out recv "? Or for that matter, "in
> xmit "?
>
> bridge# ipfw add 500 pipe 2 ip from any to any out recv xl1
> 00500 pipe 5 ip from any to any out recv xl1
> bridge# ipfw add 600 pipe 3 ip from any to any in xmit x
Is this a bug or have I misunderstood?
Why is it possible to say "out recv "? Or for that matter, "in
xmit "?
bridge# ipfw add 500 pipe 2 ip from any to any out recv xl1
00500 pipe 5 ip from any to any out recv xl1
bridge# ipfw add 600 pipe 3 ip from any to any in xmit xl1
[ipfw u
< said:
> ISTR at one time you would instead get the actual sockaddr of the
> just-closed socket, rather than a bogus sockaddr... and that is the
> behavior one would expect.
As itojun pointed out, accept() used to just block if the socket it
thought it was going to give you turned out not to be
Hi,
I have to set up a FreeBSD Box which have to support IEEE 802.1Q VLANs.
>From the past I know that there are limitations in the hardware and the
fixed MTU of 1500 Bytes (fixed size of receiving buffer, etc)
I'm free in the choice of Hardware. Which cards will run smothly with
freebsd and vla
12 matches
Mail list logo