Firewall netlink question...

Firewall netlink question...

[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 <scaramanga@barrysworld.com>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Firewall netlink question...

[Philipp Matthias Hahn]

On Mon, 22 Jan 2001, Scaramanga wrote:

> 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.
You might take a look at

$ man iptables
...
TARGETS
...
QUEUE means to pass the packet to userspace (if supported by the kernel).

$ 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

BYtE   
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

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

Re: Firewall netlink question...

[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 <scaramanga@barrysworld.com>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Firewall netlink question...

[Daniel Stone]

On 22 Jan 2001 10:26:00 +0000, Scaramanga wrote:
> 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.

So you can do whatever you want with it.

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

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/

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

> Am I missing something totally obvious?

It just does more stuff. A plane is far more complex than a car, but
with an added feature - it also flies above the ground.

> Regards

-- 
Daniel Stone
Linux Kernel Developer
daniel@kabuki.eyep.net

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
G!>CS d s++:- a---- C++ ULS++++$>B P---- L+++>++++ E+(joe)>+++ W++ N->++ !o
K? w++(--) O---- M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ 
D+ G e->++ h!(+) r+(%) y? UF++
------END GEEK CODE BLOCK------



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

Re: Firewall netlink question...

[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 <scaramanga@barrysworld.com>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Firewall netlink question...

[Daniel Stone]

On 22 Jan 2001 11:58:26 +0000, Scaramanga wrote:
> Hi,
> >> 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...

This is a great idea.
Seeing as we have the compatability for ipchains and ipfwadm, this can't
be an altogether thing. Plus, userspace hacks to detect kernel versions
are always bad.

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

My all-time favourite is Microsoft-IIS/4.0 (Unix) mod_ssl/2.<whatever>
OpenSSL/0.9.4

-- 
Daniel Stone
Linux Kernel Developer
daniel@kabuki.eyep.net

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
G!>CS d s++:- a---- C++ ULS++++$>B P---- L+++>++++ E+(joe)>+++ W++ N->++ !o
K? w++(--) O---- M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ 
D+ G e->++ h!(+) r+(%) y? UF++
------END GEEK CODE BLOCK------



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

Re: Firewall netlink question...

[Scaramanga]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]


On 2001.01.22 11:58:26 +0000 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 <scaramanga@barrysworld.com>
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

[-- Attachment #2: netlink.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 4559 bytes --]

Re: Firewall netlink question...

[Harald Welte]

On Wed, Jan 24, 2001 at 04:28:26AM +0000, Scaramanga wrote:
> 
> On 2001.01.22 11:58:26 +0000 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 :)

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

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'll do some testing and put it into CVS, if you want to.

> // Gianni Tedesco <scaramanga@barrysworld.com>

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Firewall netlink question...

[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 <scaramanga@barrysworld.com>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Firewall netlink question...

[Harald Welte]

On Mon, Jan 22, 2001 at 10:26:00AM +0000, Scaramanga wrote:
> 
> 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.

ah... you are referring to my ipqmpd (ip queue multiplex daemon). Yes, it
is not very efficient. But it is right now the only way to have multiple
processes using the ip_queue. 

The ideal solution is a queue handler which does in fact handle more than
one queue from inside the kernel. Unfortunately nobody got around writing
it yet. 

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

well... the ip_queue module as opposed to your implementation as iptables
target has the following advantages:

- can be used from each netfilter-hook attached code (not only from 
  an ip table)
- is more generic (you can register different queue handler, ipv6, ...)

btw: please move this discussion to netfilter-devel@lists.samba.org

> Regards

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/