Iptables and kernel modules

Iptables and kernel modules

[LAAROUCHI Youssef]

Hi,

I've created a kernel module to modify the format of
exchanged IP packets... This module is correctly inserted
into the kernel. I then want to make this module receive
the packets by using the following command :

#iptables -t mangle -A INPUT -p icmp --icmp-type 38 -j 
puzClient

This command returns an error asking for .so file... The
problem is that I don't know the format of .so files.. I
have generated one .so file by adding -shared in the link
command, but it doesn't solve the problem. I have undefined
symbols error.

So can you specify to me how the .so files are generated ?
and what is the necessary format to generate a ipt_target
so file. And eventually, can we make iptables working
directly  with kernel modules without using .so files  ? ? 

Thanks,

Youssef


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: Iptables and kernel modules

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting LAAROUCHI Youssef on 2005-07-01 00:41 UTC:
> Hi,
> 
> I've created a kernel module to modify the format of
> exchanged IP packets... This module is correctly inserted
> into the kernel. I then want to make this module receive
> the packets by using the following command :
> 
> #iptables -t mangle -A INPUT -p icmp --icmp-type 38 -j 
> puzClient
> 
> This command returns an error asking for .so file... The
> problem is that I don't know the format of .so files.. I
> have generated one .so file by adding -shared in the link
> command, but it doesn't solve the problem. I have undefined
> symbols error.

You need to create a userspace helper for your kernel module. If your
kernel module is named ipt_puzClient.c, the userspace helper should be
named libipt_puzClient.c and be placed in the iptables source tree in
the extensions/ directory. There are also a few more files in the same
directory that you need to create, see sections 9-12 in the
README.newpatchs in patch-o-matic-ng e.g.

http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/README.newpatches?rev=4018&view=auto

You can look at libipt_MARK.c for an example..

> So can you specify to me how the .so files are generated ?

After you get the files in place and your kernel has been configured to
compile your module, compile iptables and it should detect that it needs
to create libipt_puzClient.so and create it for you.

> and what is the necessary format to generate a ipt_target
> so file. And eventually, can we make iptables working
> directly  with kernel modules without using .so files  ? ? 

Everything's possible, but that wouldn't be very nice. Creating the .so
file shouldn't be too hard as soon as you understand how to do it. I
think you can copy-paste a lot from libipt_MARK.c to get going..

> Thanks,
> 
> Youssef

Good luck! :)

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCyFPyxyF48ZTvn+4RAtJiAJ98X0JbIrbm0sgpe2kSgv2uzq8xogCeMrJL
BBwA6+jInSxYcFbAfpmgPpI=
=7P8r
-----END PGP SIGNATURE-----

bandwidth saving idea

[Oscar Mechanic]

Hi

   You could suggest the mail should go to LARTC but as I intend to use
netfilter codebase. You may consider this to be daft

Simple scenario

I have machines one is alabama and the other in berkley called machine A
and machine B they are both routers.

machine A has a serial number A000 and machine B has a serial number
B000.

machine A and machine B send packets to each other all the time as they
belong to the same business. These may be citrix packets POP packets
etc...

Machine A sends a packet to machine B. As the packet passes through
machine A it records the MD5 checksum on the packet and holds it in
memory. Machine B is doing the same (All packets sent from A the
checksums are recorded) and it is holding the payload aswell. The key
for finding the payload is the checksum. 

For simplicity lets say the max size of the (FIFO)list in memory is
1000. 

If the same packet is sent again through A it does not send the payload
to Machine B but sends the checksum. B sees the checksum finds the
payload and replaces the checksum with the payload.

(This should work! but it only becomes useful if you can do it with a
list of checksums in the one packet)

If I am not mistaken I can do this with QUEUE target and then turn it
into a module.


Opinions anyone ? 
  

Re: bandwidth saving idea

[Eric Leblond]

Le lundi 11 juillet 2005 à 14:16 +0100, Oscar Mechanic a écrit :
> Machine A sends a packet to machine B. As the packet passes through
> If the same packet is sent again through A it does not send the payload
> to Machine B but sends the checksum. B sees the checksum finds the
> payload and replaces the checksum with the payload.

Well, there's a problem with protocol like TCP, you've got SEQ number
and other flags in TCP header that are changing even if the datas
contained in the packet are the same. Thus your compression protocol is
not efficient. Even a 1000 unit FIFO is useless. Furthermore, your
protocol is theoritically wrong, as checksum functions are not
injective.

You better try to set up an ipsec tunnel with compression between the
two machines. On protocol other than citrix, this can bring you a good
compression level (30% or more if I recall correctly some tests I've
made).

BR,
-- 
Eric Leblond <eric@inl.fr>

Re: bandwidth saving idea

[Oscar Mechanic]

On Mon, 2005-07-11 at 15:26 +0200, Eric Leblond wrote: 
> Le lundi 11 juillet 2005 à 14:16 +0100, Oscar Mechanic a écrit :
> > Machine A sends a packet to machine B. As the packet passes through
> > If the same packet is sent again through A it does not send the payload
> > to Machine B but sends the checksum. B sees the checksum finds the
> > payload and replaces the checksum with the payload.
> 
> Well, there's a problem with protocol like TCP, you've got SEQ number
> and other flags in TCP header that are changing even if the datas
> contained in the packet are the same. Thus your compression protocol is
> not efficient. Even a 1000 unit FIFO is useless. Furthermore, your
> protocol is theoritically wrong, as checksum functions are not
> injective.
> 
> You better try to set up an ipsec tunnel with compression between the
> two machines. On protocol other than citrix, this can bring you a good
> compression level (30% or more if I recall correctly some tests I've
> made).
> 
> BR,

Thank you for your response I have looked at ipcomp in detail and find
it a mature and well developed protocol. 

The TCP flags would have to be short sequenced to numeric codes. The
sequence number I will have to think about, as a single packet in the
stream is fine as it would have the same SEQ number. 

Products that work similar to this are already available and as they
most probably already using a BSD or Linux as an RTOS we will just have
to wait forever to see the code.

I do not understand "checksum functions are not injective" my intention
was to hold a name=value list where name is checksum and value is
payload (or reference to payload on disc/FC/RD). 

Regards
Oscar Mechanic

Re: bandwidth saving idea

[Eric Leblond]

> I do not understand "checksum functions are not injective" my intention
> was to hold a name=value list where name is checksum and value is
> payload (or reference to payload on disc/FC/RD). 

A function f is injective if for all a and b f(a)=f(b) implies a=b.

Let f be your checksum function and a and b two packet payload then
f(a)=f(b) does not implied a=b. Thus, given a checksum c you can not
assert that there is only one a such as f(a)=c.

In fact, your start set is the set of number of size 1500bits (packet
length) and your result set is the set of number of size inferior or
egal to checksum length (32). As number of elements of start set is
larger than the number of elements of result set. Thus, there is no
injective function from set of packet to set of checksum.

BR,
-- 
Eric Leblond <eric@inl.fr>

Re: bandwidth saving idea

[Amin Azez]

Eric Leblond wrote:
>>I do not understand "checksum functions are not injective" my intention
>>was to hold a name=value list where name is checksum and value is
>>payload (or reference to payload on disc/FC/RD). 
> 
> 
> A function f is injective if for all a and b f(a)=f(b) implies a=b.
> 
> Let f be your checksum function and a and b two packet payload then
> f(a)=f(b) does not implied a=b. Thus, given a checksum c you can not
> assert that there is only one a such as f(a)=c.
> 
> In fact, your start set is the set of number of size 1500bits (packet
> length) and your result set is the set of number of size inferior or
> egal to checksum length (32). As number of elements of start set is
> larger than the number of elements of result set. Thus, there is no
> injective function from set of packet to set of checksum.

This is true; however if the system is bi-directional, both machines
will keep a copy of the entire packet payload that was md5'd so that
they can re-emit this payload when the receive the md5 code.

The "compressing" machine after finding an md5 hit, will need to do a
bit-comparison to see that it was the same payload that generated the
md5 in the remote machine as has just generated that md5 locally.

Thus, although md5 is non-injective, the actual system is proof against
this deficiency.

It remains to see how much packet storage is needed to effectively save
bandwidth, but in specific installations this may not be too great.

Amin