Hey.
Im doing this to learn, but I was only testing with compression going
one way and no decompression just to make sure it was all working.
However if I implement decompression, then everything should be
working 100%, and I wont have to worry about breaking TCP or modifying
sequence numbers or a
On May 17, 2011, at 6:16 AM, Cole wrote:
> I was hoping to keep this clean, and use existing methods for hooking
> into the stream. Also the goal im working for is to be able to use
> this on a box doing routing to hopefully get some sort of compression
> working between 2 end points. So most of th
On Tue, May 17, 2011 at 12:20:34PM -0400, Jason Hellenthal wrote:
>
> Michael,
>
> On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote:
> > Dear all,
> >
> > fwip0 1500 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00
> > 0 0 0 00 0 0
On May 17, 2011, at 6:20 PM, Jason Hellenthal wrote:
>
> Michael,
>
> On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> fwip0 1500 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00
>> 0 0 0 00 0 0 0
>>
>
>
The following reply was made to PR kern/85320; it has been noted by GNATS.
From: Niclas Zeising
To: bug-follo...@freebsd.org, fm...@borderware.com
Cc: freebsd-net@freebsd.org
Subject: Re: kern/85320: [gre] [patch] possible depletion of kernel stack
in ip_gre.c when net.isr.enable = 1
Date: Tue,
Hi!
The issue mentioned in the PR has been fixed in 9-current and 8 (all
versions). It can probably be merged to 7-stable as well, and/or the PR
closed. Thanks!
Regards!
--
Niclas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/
Hello All!
Please close thise PR kern/141285, because in RELEASE-8.2 it is fixed.
Thanks Jack Vogel !
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...
On Tue, May 17, 2011 at 03:16:51PM +0200, Cole wrote:
> Also the goal im working for is to be able to use
> this on a box doing routing to hopefully get some sort of compression
> working between 2 end points. So most of the data would not actual be
> generated from userland processes.
But on a r
What if your modified (shortened) packet does get lost? If you
messed with the tcpcb in the way you intend, how do you plan on
getting retransmission working, when it's needed?
Or what if you enlarge a packet, are you sure it won't violate
the MTU?
It seems you're doing this on wrong side of the
Hi.
These are obviously things I will need to look into regarding
retransmission if the packet does actually get lost.
As for the MTU issue, if the kernel mod pushes the data over the MTU
size, then the packet is not changed and left as is.
I was hoping to keep this clean, and use existing metho
Hi.
Ive written a kernel module that modifies the data of outgoing TCP
packets. I use pfil_hook to insert my module into the outgoing packet
stream. Depending on the data, the size of data in the TCP packet may
change, either increasing or decreasing. When modifying the data size,
I update the mbu
Charles Sprickman wrote
in :
sp> First, the easy one. For IPv6 aliases, what is the proper subnet?
Normally it is a /64. See also Section 2.5.4 in RFC 4291.
sp> And the second one, which is also probably easy. We're going to move
sp> at some point from a bunch of subnets on the same wire
Hello,
I'm having trouble finding the canonical answer on two uses of
interface aliases.
First, the easy one. For IPv6 aliases, what is the proper subnet? I've
found some old info on the WIDE site stating that it should be the same as
the main interface (ie: if I've got a /48, my alias sho
13 matches
Mail list logo
