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 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
