Andy Furniss wrote:
Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem
is advertising a window and then shrinking it faster than it is
naturally reduced by incoming data, essentially granting credit to
transmit x bytes, and then revoking that credit
Andy Furniss wrote:
Mark Butler wrote:
Andy Furniss wrote:
Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem
is advertising a window and then shrinking it faster than it is
naturally reduced by incoming data, essentially granting credit to
transmit x
Andy Furniss wrote:
David S. Miller wrote:
From: Michal Piotrowski [EMAIL PROTECTED]
Date: Sun, 12 Mar 2006 02:51:40 +0100
I have noticed this warnings
TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
148470938:148470943. Repaired.
TCP: Treason uncloaked! Peer
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in
Mark Butler wrote:
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address
David Daney wrote:
Following your logic through, It seems that you are advocating
broadcasting *all* ARP packets on *all* link local addresses. That
would mean that on a 192.168.* switched Ethernet network with DHCP
that twice as many ARP packets would be broadcast.
192.168.* addresses are
Vlad Yasevich wrote:
On Wed, 2006-04-05 at 10:38 -0600, Mark Butler wrote:
The problem in this case is skb1 does not own the skb_shared_info
structure (and hence the frag_list) once it has been cloned.
skb_unshare is the function that should be used to get a modifiable copy.
So
Rick Jones wrote:
Again from RFC 791:
snip
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
Hence the minimum IPv4 MTU of 68 bytes.
Makes sense to me. Does a similar argument apply the IPv6 minimum
Bill Fink wrote:
Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
the kernel overhead. If the user requests 100K of kernel data
buffering, then they should get 100K. It shouldn't matter to the
user that the kernel would actually be using a total of 167K of
memory to satisfy
David S. Miller wrote:
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for struct sk_buff etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual data to be received on that socket.
Andi Kleen wrote:
On Saturday 25 March 2006 23:32, Mark Butler wrote:
A true firewall should never need to do anything but drop packets and
reset connections. Changes to the way packets are routed should be done
at the routing layer, using the flow information from the transport
layer
David S. Miller wrote:
From: Mark Butler [EMAIL PROTECTED]
Date: Fri, 24 Mar 2006 22:37:26 -0700
On a more general note, I find the idea that a current dst entry doesn't
actually reflect the interface (even a logical interface) and nexthop
that will be used to deliver a packet a little
Wouldn't the appropriate place to add the tunable for Stretch ACKs be as
a route attribute similar to RTAX_ADVMSS? Then system administrators
who are aware of the local network topology, netfilters, etc, could use
an ip route or whatever command to enable it on the route entry for
the
Mark Butler wrote:
James Lentini wrote:
On Tue, 21 Mar 2006, Jason Gunthorpe wrote:
On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote:
Okay, but there are number of other places in iproute2 that call
ll_addr_a2n() with ifr.ifr_hwaddr.sa_data. And that is 14 bytes
Stephen Hemminger wrote:
The bigger problem is that too be effective rate control needs accurate
real time. Linux is doing better at real time, but still providing useful
high speed inter packet spacing is beyond the current capabilities. To get
around this I think most high speed 10G cards
Ian McDonald wrote:
On 3/23/06, Mark Butler [EMAIL PROTECTED] wrote:
I understand that timed intervals between individual packets is not
realistic in general. What I have in mind is a fixed granularity
transmission timer, where packets are assigned to buckets, and
transmitted one bucket
On Mon Mar 14, 2006, Christopher Hellwig wrote:
On Mon, Mar 13, 2006 at 02:25:08PM -0800, Zach Brown wrote:
Hi guys,
I'm hearing noise about the 'Extended Sockets' API in Oracle. It's an
extension to the socket API put together by an industry group that calls
itself the Interconnect
One Tue, 14 Mar 2006 11:37:38 -0300, Arnaldo Carvalho de Melo wrote:
On 3/13/06, Saurabh Jain [EMAIL PROTECTED] wrote:
Hi All,
I am trying to write a new rate based transport protocol in linux
kernel (either as a module or directly within the kernel). Basically
it
On Mon, 13 Mar 2006 18:20:26 -0600, Saurabh Jain wrote:
Hi All, I am trying to write a new rate based transport protocol in
linux kernel (either as a module or directly within the kernel).
Basically it would be similar to UDP but with features like dynamic
rate control, connection
The XFRM code base looks like it needs a relatively intrusive change to
support protocols like SCTP correctly. The problem is that security
policies are cached on the socket level, where SCTP not only uses
multiple addresses per association, but multiple associations per socket.
I believe
20 matches
Mail list logo
