Re: Firewall netlink question...

2001-01-24 Thread Scaramanga

Hi,

> eeks... a compressed archie including a binary is not what people on 
> linux-kernel usually want to see

whoops, gues who made a bodge of thier makefile :P


> anyway - thanks for your contribution. Why didn't you submit this for 
> inclusion into netfilter/iptables CVS patch-o-matic ? We (the netfilter
> people) keep all the new targets/matches/... there and submit approved
> stuff after some time for inclusion to the main kernel.

I actually sent this off to rusty aswell, I should have posted it to
netfilter-devel list too really.

> I'll do some testing and put it into CVS, if you want to.
> 

Cool.

--
// Gianni Tedesco <[EMAIL PROTECTED]>
Fingerprint: FECC 237F B895 0379 62C4  B5A9 D83B E2B0 02F3 7A68
Key ID: 02F37A68

egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Firewall netlink question...

2001-01-23 Thread Scaramanga


On 2001.01.22 11:58:26 + Scaramanga wrote:
> I wonder, would there be any interest/point in my NETLINK module, which
> provides a backward compatible netlink interface. There are a good few
> apps out there which rely on it, and its nice not to have to run a daemon
> and install a new library, and re-write them just to continue using them...

Well, here it is, kernel module, and iptables plugin. Emjoy :)

--
// Gianni Tedesco <[EMAIL PROTECTED]>
Fingerprint: FECC 237F B895 0379 62C4  B5A9 D83B E2B0 02F3 7A68
Key ID: 02F37A68

egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7
 netlink.tar.gz


Re: Firewall netlink question...

2001-01-22 Thread Scaramanga

Hi,

> This is true. This is called ipqmpd or something similar and written by
> Harald Welte, yes?
> Your best option is to either check out libipq (can be found in the
> directory of the same name in the iptables sources), which provides
> clean C interfaces, or the PERL interface, available from
> http://www.intercode.com.au/jamesm/

Yeah, I think that was the one.


>> What was wrong with the firewall netlink? My re-implementation works great
>> here. I can't see why anything else would be needed, QUEUE seems twice as
>> complex. Unless with QUEUE the userspce applications can make decisions on
>> what to do with the packet? In which case, it would be far too inefficient
>> for an application like mine, where all i need is to be able to read the
>> IP datagrams..
> 
> It can modify and then reinject the packet if it so wishes.

Excellent, I didn't pick up on that, with the cursory glance at the code i took.

I wonder, would there be any interest/point in my NETLINK module, which
provides a backward compatible netlink interface. There are a good few
apps out there which rely on it, and its nice not to have to run a daemon
and install a new library, and re-write them just to continue using them...

--
// Gianni Tedesco <[EMAIL PROTECTED]>
Fingerprint: FECC 237F B895 0379 62C4  B5A9 D83B E2B0 02F3 7A68
Key ID: 02F37A68

egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Firewall netlink question...

2001-01-22 Thread Scaramanga

Hi,

> QUEUE means to pass the packet to userspace (if supported by the kernel).

Looking at the code it seemed to do the same thing as the old netlink, but
with more complexity, to what end though, i couldnt tell, was only a brief
skim.

> $ sed -n -e '1874,1876p' /usr/src/linux-2.4.0/Documentation/Configure.help
> CONFIG_IP_NF_QUEUE
>   Netfilter has the ability to queue packets to user space: the
>   netlink device can be used to access them using this driver.
> 
> $ lynx /usr/share/doc/iptables/html/packet-filtering-HOWTO-7.html
> 

Yeah, after some quick googling and freshmeating, i came accross a daemon
that picked up these QUEUEd packets and multiplexed them to various child
processes, which seemed very innefcient, the documentation said something
about QUEUE not being multicast in nature, like the old firewall netlink.

What was wrong with the firewall netlink? My re-implementation works great
here. I can't see why anything else would be needed, QUEUE seems twice as
complex. Unless with QUEUE the userspce applications can make decisions on
what to do with the packet? In which case, it would be far too inefficient
for an application like mine, where all i need is to be able to read the
IP datagrams..

Am I missing something totally obvious?

Regards

--
// Gianni Tedesco <[EMAIL PROTECTED]>
Fingerprint: FECC 237F B895 0379 62C4  B5A9 D83B E2B0 02F3 7A68
Key ID: 02F37A68

egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Firewall netlink question...

2001-01-21 Thread Scaramanga

Hi,

Under Linux 2.2.x I used to be able to use ipchains to send packet to a
netlink socket so that my userspace application could further analyze
the packet data.

Since kernel 2.4 and iptables, I have not enjoyed the same functionality,
has it been deprecated in favour of a better method, if so, what? I ask 
because I just spent my last few hours writing an iptables plugin, and 
netfilter target kernel module, in order to replace the old functionality 
exactly, to the end that my application works with zero modifications.

Have I missed something?

Kind regards

--
// Gianni Tedesco <[EMAIL PROTECTED]>
Fingerprint: FECC 237F B895 0379 62C4  B5A9 D83B E2B0 02F3 7A68
Key ID: 02F37A68

egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/