There may be an issue with T/TCP, but otherwise I see no reason
to set DF on syn-ack, even when PMTUD is on. There is simply no
point to avoiding fragmentation of a single packet per connection,
and it's highly unlikely anyway in today's Internet. The current
behavior is perfectly acceptable to
Lars Eggert writes:
> >>#11 0xc1be5bfc in ?? ()
> >>#12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at
> >>../../net/if.c:1375
> >
> > ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument
> > to point to a struct ifreq, yet if_allmulti() is passing NULL.
>
> No i
Archie Cobbs wrote:
> Lars Eggert writes:
>
>>#11 0xc1be5bfc in ?? ()
>>#12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at
>>../../net/if.c:1375
>
>
> Well, this is obvious by looking at it.
>
> ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument
> to point to
Lars Eggert writes:
> #11 0xc1be5bfc in ?? ()
> #12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at
> ../../net/if.c:1375
Well, this is obvious by looking at it.
ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument
to point to a struct ifreq, yet if_allmulti() is
On Fri, 14 Jun 2002, Jonathan Lemon wrote:
> It is a DoS. Suppose that for some reason, we send out a SYN,ACK of
> 80 octets, which hits a router with the minimum MTU of 68 octets.
> Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped,
> and a ICMP PMTU response is sent ba
In article <[EMAIL PROTECTED]>,
Julian Elischer <[EMAIL PROTECTED]> wrote:
> I guess we need to figure out a way make the activation of
> the netgraph hooks automatically disable H/W checksumming by default.
Hmm, it looks like Archie already did that in February, in ng_ether.c
revisions 1.22 (-c
On Fri, Jun 14, 2002 at 01:17:24PM -0500, Mike Silbersack wrote:
>
> On Fri, 14 Jun 2002, Jonathan Lemon wrote:
>
> > Actually, this is not a bug, except possibly for the TOS bits. I just
> > reread RFC 1191, and there isn't anything in there that requires DF to
> > always be set on a TCP conne
On Fri, 14 Jun 2002, John Polstra wrote:
>
> I'm not Julian or Archie, but I think I know what the problem is.
> The xl interface supports hardware checksum offloading, while the rl
> interface does not. When checksum offloading is used, the NIC itself
> checks the checksums of received packe
On Fri, 14 Jun 2002, Jonathan Lemon wrote:
> Actually, this is not a bug, except possibly for the TOS bits. I just
> reread RFC 1191, and there isn't anything in there that requires DF to
> always be set on a TCP connection. In fact, RFC 1191 states:
>
>Or, the host may ele
In article [EMAIL PROTECTED]>
you write:
>
>(I'm redirecting this back to freebsd-net, as it doesn't seem appropriate
>for bugtraq.)
>
>I did some quick investigation last night, and agree with Phil that this
>is a bug. When the syncache was implemented, only a subset of the normal
>tcp output c
Julian Elischer wrote:
> I haven't seen a problem with multicast and netgraph but
> that doesn't mean there isn't a problem. Let us see if there is a
> traceback.
Here's one (4.5-RELEASE + security advisory patches). I can readily
reproduce this crash, so I have a good setup to test things for
In article <[EMAIL PROTECTED]>,
Sebastien Petit <[EMAIL PROTECTED]> wrote:
>
> I've a problem with ng_ether and xl0 driver, when I connect upper <-> lower
> directly, packets have ip sum to 0 and a wrong tcp and udp cksum. I try to
> use my test code on rl0 driver, and it work fine.
> Julian o
Hi,
anybody interested in implementing this for FreeBSD?
Marco
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
To: IETF-Announce: ;
Date: Fri, 14 Jun 2002 07:30:01 -0400
Subject: I-D ACTION:draft-floyd-tcp-highspeed-00.txt,.ps
A New Internet-Draft is available fr
Hi,
I've a problem with ng_ether and xl0 driver, when I connect upper <-> lower
directly, packets have ip sum to 0 and a wrong tcp and udp cksum. I try to
use my test code on rl0 driver, and it work fine.
Julian or Archie, can you say me if I must recompute ip/tcp/udp checksum for
all packets
14 matches
Mail list logo
