On Fri, Jul 13, 2007 at 05:41:04AM +, Bjoern A. Zeeb wrote:
> On Thu, 12 Jul 2007, [EMAIL PROTECTED] wrote:
> >At Wed, 11 Jul 2007 13:49:37 +0200,
> >Peter Blok wrote:
Hi all.
[KAME's IPSec removal and ipsec-tools]
> I have a preliminary hackish patch. The problem is that I have other
> patch
On Fri, 13 Jul 2007, VANHULLEBUS Yvan wrote:
(taking the thread to net@ only as it does not affect current@ but is
more a port@ thing)
On Fri, Jul 13, 2007 at 05:41:04AM +, Bjoern A. Zeeb wrote:
On Thu, 12 Jul 2007, [EMAIL PROTECTED] wrote:
At Wed, 11 Jul 2007 13:49:37 +0200,
Peter Blok w
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
1294)
That is what to be expected.
Incoming interf
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
1294)
That is what to be expected.
Incoming interface must have mtu set to the same mtu
* VANHULLEBUS Yvan <[EMAIL PROTECTED]> wrote:
> But if it is quite simple to fix for -HEAD, which now only have
> netipsec/ipsec.h, it is harder to solve cleanly for older versions,
> which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I
> just don't know how to guess which one we s
In response to Stephen Clark <[EMAIL PROTECTED]>:
> Sten Daniel Soersdal wrote:
>
> >Stephen Clark wrote:
> >
> >
> >>Hello,
> >>
> >>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
> >>accept a larger incomming packet.
> >>
> >>kernel: rl0: discard oversize frame (ether typ
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether typ
In response to Stephen Clark <[EMAIL PROTECTED]>:
> Bill Moran wrote:
>
> >In response to Stephen Clark <[EMAIL PROTECTED]>:
> >
> >>Sten Daniel Soersdal wrote:
> >>
> >>>Stephen Clark wrote:
> >>>
> Hello,
>
> Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
> >>
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280
Bill Moran wrote:
ractices are
still evolving.
Let's flip the question around a bit: why would you _want_ the TCP stack
to accept frames larger than the stated MTU?
Because mtu is mTu not mRu.
The interface should theoretically always accept any packet up to
the maximum practical size..
As t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Moran <[EMAIL PROTECTED]> wrote:
>
> Let's flip the question around a bit: why would you _want_ the TCP
> stack to accept frames larger than the stated MTU?
If I receive a 64K frame and the TCP checksum checks out, and the
sequence numbers match
In response to David DeSimone <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bill Moran <[EMAIL PROTECTED]> wrote:
> >
> > Let's flip the question around a bit: why would you _want_ the TCP
> > stack to accept frames larger than the stated MTU?
>
> If I receive a 64K
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
standard
or otherwise to support my view. You didn'
I'm having a problem getting a Netgear WG511T in my FreeBSD CURRENT
laptop to do WPA2-PSK with a Netgear WG302 access point. I'm hoping
someone here can give me a nudge in the right direction to help
troubleshoot this.
The laptop is an old Sony Vaio (PCG-Z505HS). The Netgear WG511T
probes thusly
Chuck Swiger wrote:
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
standard
or otherwise
On Jul 13, 2007, at 1:24 PM, Stephen Clark wrote:
Designers of gateways should be prepared for the fact that
successful
gateways will be copied and used in other situation and
installations. Gateways must be prepared to accept datagrams as
large as can be sent in the maximum packe
Stephen Clark wrote:
Chuck Swiger wrote:
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
sta
> Bill Moran wrote:
> ractices are
> > still evolving.
> >
> > Let's flip the question around a bit: why would you _want_ the TCP stack
> > to accept frames larger than the stated MTU?
> >
> Because mtu is mTu not mRu.
I must agree. There is no strong requirement that MTU == MRU, although
the
Mike Karels wrote:
I'd be happy to see the change undone as well. I (well, our test
group) found this change in a similar way, and it didn't agree with
our previous usage.
In -CURRENT my changes to the ethernet input path maintain the use of
ETHER_MAX_FRAME() however the check is folded un
> In -CURRENT my changes to the ethernet input path maintain the use of
> ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I
> don't recall adding this conditional or touching it so it seems to be
> something which was already thereo radded by someone else.
It has been the
20 matches
Mail list logo
