libipq

libipq

[Bogaerts Bart]

Hello,

I have written a UserApplication which changes some payload into certain
messages. 
When I send with netcat messages sequential to netfilter all the messages
are passed through netfilter, but when I
send multiple messages to netfilter, I can see that my application get all
the messages adapt this messages 
and calls for every messages the set_verdict function but not all the
messages are appearing on the outgoing interface.

I'm using kernel 2.4.20 and iptables 1.2.6a

What exactly happens when a adapted packet is reinjected via nf_reinject ?
After leaving the POSTROUTING hook the packet is sent to where ?


With friendly greetings,
Bart

libipq

[Oumer Teyeb]

Hi,

I have a linux box (propriotry of some company) where there is an 
installation of iptables but not of libipq. As I want to do some 
userspace programming, I naturally want libipq installed. Is there an 
easy way of installing libipq without the need to recompile my kernel (I 
don't even have the source for the kernel)  or reinstall the iptables 
that is already there?  Will it be enough just to run make under the 
libipq sub-directory of the iptables source code? I just don't want to 
mess the iptables that is already working.

Thanks in advance,
Oumer

libipq

[Oumer Teyeb]

Hi,

I have a linux box (propriotry of some company) where there is an 
installation of iptables but not of libipq. As I want to do some 
userspace programming, I naturally want libipq installed. Is there an 
easy way of installing libipq without the need to recompile my kernel (I 
don't even have the source for the kernel)  or reinstall the iptables 
that is already there?  Will it be enough just to run make under the 
libipq sub-directory of the iptables source code? I just don't want to 
mess the iptables that is already working.

Thanks in advance,
Oumer

libipq

[Devaraj Das]

Hi all,
If I have an application (using libipq) that's waiting for packets, and I
want to inspect the payload, will the payload be encrypted in case I use
esp/transport with kernel 2.6 (with built-in ipsec)?
Thanks,
Devaraj.

__ Radien__ wrote:

> Dear All
>
>    I have read some about ISA server from it's documentation. There were
> listed some facilities for example Circuit Level and App Level
> filtering and gateway.
>
>    Circuit level filtering and gateway were strange for me. What are
> they?
>    How can I see such capabilities in iptables? How they get mapped in
> iptables?
>
>    Is iptables sth other than what ip_conntrack_ftp.o mudule do in
> Application Layer?
>
> Regards
> __Radien__

Re: libipq

[Antony Stone]

On Thursday 08 April 2004 9:32 am, Devaraj Das wrote:

> Hi all,
> If I have an application (using libipq) that's waiting for packets, and I
> want to inspect the payload, will the payload be encrypted in case I use
> esp/transport with kernel 2.6 (with built-in ipsec)?

This depends on which packets you inspect the payload of.

If you inspect the ESP packets, then yes, they will be encrypted under IPsec.

If you inpect the HTTP/FTP/SMTP/whatever packets which come out of the tunnel 
on the other side, then no, they will not be encrypted (unless, of course, 
you send ssh or https through your IPsec tunnel).

PS: Please don't quote an irrelevant previous posting, and please start a new 
thread for a new question.

Regards,

Antony.

-- 
I'm pink, therefore I'm Spam.

                                                     Please reply to the list;
                                                           please don't CC me.

libipq

[aksingh]

hi

1) is libipq library distributed with all 2.4 series kernels, i use
2.4.2-2smp, but i cant locate libipq.h on my system
2) i had a doubt regarding nf_hook filters returning NF_QUEUE, nobody has
replied so ill try and make my question more specific ---
      - i use a PRE_ROUTING hook to capture all ipv4 packets  >>> this is
fine
      -the hook function returns NF_QUEUE return code and hence the packet
goes to ip_queue(assuming i have loaded ip_queue module, the kernel gives
upprocessing this packet here
              - a user process i create is listening on the netlink socket
for the packet just given to ip_queue, once it gets the packet it plays
with it and reinjects the packet using ip_set_verdict ... here two things
might happen, one is that my user process decides to keep the packet for
itself and returns a verdict of NF_DROP in ip_set_verdict(in which case the
packet is dropped on being reinjected into the kernel, i hope this is the
case, right ?).   Secondly, the process might actually want to reinject the
packet into the kernel and hence it calls ip_set_verdict with a verdict of
NF_ACCEPT. On receiving this second type of packet(after reinjection), i
expect the kernel not to repeat the same hook, cos if it does then im stuck
in an infinite loop.

is my understanding correct(just the third point) or is there any chance of
me getting into an infinite loop if i use this method.

thanks
Amit





Alistair Tonner <Alistair@nerdnet.ca>@lists.netfilter.org on 04/19/2004
02:18:14 PM

Sent by:    netfilter-admin@lists.netfilter.org


To:    netfilter@lists.netfilter.org
cc:

Subject:    Re: Iptables and Kernel


On April 19, 2004 04:34 am, Norman Zhang wrote:
> >I'm running 2.6.3. with iptables 1.2.9 and p-o-m-ng h323 patch -- they
> > work for me -- but I'm referring to a home lan ond only one netmeeting
> > seesioon from the LAN  -- we haven't tried multiple sessions from
inside
> > the lan ... either to the same netmeeting sessioon or to different
ones.
>
> Sorry it is me again. I tried to compile pomng using
>
> # KERNEL_DIR=/usr/src/linux ./runme pending
> # KERNEL_DIR=/usr/src/linux ./runme base
> # KERNEL_DIR=/usr/src/linux ./runme extend
>
> but couldn't find h323-conntrack-nat patch being offered. I did see
> owner-socketlookup mention something about H.323. May I ask how do I
> applied h323-conntrack-nat patch to iptables and kernel-2.6.5 alone? I
> can see the subfolder h323-conntrack-nat under pomng.

 Okay -- I'm a twit --- I'd assumed since my loadup script was completed
without errors that things had worked all the way through ... looking again
it seems that the h323 stuff only applies against 2.4.x kernels -- Joseph
K.
hasn't ported it -- likely because its slightly hackish .. And Lord KNOWS
why
netmeeting is working through my firewall ... other than the fact of a good
old ESTABLISHED RELATED rule ... I do know that it only works outbound, if
someone wants to call into the LAN they have to call on a specific port and
I
have that port forwarded to the destination host.

 As such, this is Yet Another Thing I might look at.


 Alistair Tonner

>
> Regards,
> Norman

Re: libipq

[Jee J.Z.]

Hi Amit,

> hi Jee
>
>   I think you got my question wrong ... my design is as follows :
> first my netfilter hook returns NF_QUEUE and hence the packet goes to
> ip_queue and from there to the user process. The user process always sets
> the verdict to either NF_ACCEPT(if it wants the kernel to handle it again)
> or NF_DROP(if it wants the kernel just to drop the packet since the user
> process has taken the ownership now). The user process wld never return
> NF_QUEUE and hence there should not be any infinite loops here.

You can try return NF_QUEUE using ipq_set_verdict() from userspace, that
gives you an infinite loop. Also, if you try NF_REPEAT, that gives you an
infinite loop as well (I think NF_REPEAT causes the kernel to repeat the
same hook). I tested it. Other than these two targets, of course you won't
get inifnite loops.

Jee

> -Amit
>
>
>
>
> "Jee J.Z." <jz105@york.ac.uk> on 06/21/2004 08:19:41 PM
>
> To:    Amit Kumar Singh/HSS@HSS
> cc:
>
> Subject:    Re: libipq
>
>
> > 1) is libipq library distributed with all 2.4 series kernels, i use
>
> I think so.
>
> > 2.4.2-2smp, but i cant locate libipq.h on my system
> > 2) i had a doubt regarding nf_hook filters returning NF_QUEUE, nobody
has
> > replied so ill try and make my question more specific ---
> >       - i use a PRE_ROUTING hook to capture all ipv4 packets  >>> this
is
> > fine
> >       -the hook function returns NF_QUEUE return code and hence the
> packet
> > goes to ip_queue(assuming i have loaded ip_queue module, the kernel
gives
> > upprocessing this packet here
> >               - a user process i create is listening on the netlink
> socket
> > for the packet just given to ip_queue, once it gets the packet it plays
> > with it and reinjects the packet using ip_set_verdict ... here two
things
> > might happen, one is that my user process decides to keep the packet for
> > itself and returns a verdict of NF_DROP in ip_set_verdict(in which case
> the
> > packet is dropped on being reinjected into the kernel, i hope this is
the
> > case, right ?).   Secondly, the process might actually want to reinject
> the
> > packet into the kernel and hence it calls ip_set_verdict with a verdict
> of
> > NF_ACCEPT. On receiving this second type of packet(after reinjection), i
> > expect the kernel not to repeat the same hook, cos if it does then im
> stuck
> > in an infinite loop.
>
> No. When you set NF_ACCEPT, the packet will go where it should go. When
you
> set NF_QUEUE in ipq_set_verdict, the packet will be put in the QUEUE
target
> again, and therefore infinite loop starts.
>
> Jee
>
> > is my understanding correct(just the third point) or is there any chance
> of
> > me getting into an infinite loop if i use this method.
> >
> > thanks
> > Amit
> >
> >
> >
> >
> >
> > Alistair Tonner <Alistair@nerdnet.ca>@lists.netfilter.org on 04/19/2004
> > 02:18:14 PM
> >
> > Sent by:    netfilter-admin@lists.netfilter.org
> >
> >
> > To:    netfilter@lists.netfilter.org
> > cc:
> >
> > Subject:    Re: Iptables and Kernel
> >
> >
> > On April 19, 2004 04:34 am, Norman Zhang wrote:
> > > >I'm running 2.6.3. with iptables 1.2.9 and p-o-m-ng h323 patch -- 
they
> > > > work for me -- but I'm referring to a home lan ond only one
> netmeeting
> > > > seesioon from the LAN  -- we haven't tried multiple sessions from
> > inside
> > > > the lan ... either to the same netmeeting sessioon or to different
> > ones.
> > >
> > > Sorry it is me again. I tried to compile pomng using
> > >
> > > # KERNEL_DIR=/usr/src/linux ./runme pending
> > > # KERNEL_DIR=/usr/src/linux ./runme base
> > > # KERNEL_DIR=/usr/src/linux ./runme extend
> > >
> > > but couldn't find h323-conntrack-nat patch being offered. I did see
> > > owner-socketlookup mention something about H.323. May I ask how do I
> > > applied h323-conntrack-nat patch to iptables and kernel-2.6.5 alone? I
> > > can see the subfolder h323-conntrack-nat under pomng.
> >
> >  Okay -- I'm a twit --- I'd assumed since my loadup script was completed
> > without errors that things had worked all the way through ... looking
> again
> > it seems that the h323 stuff only applies against 2.4.x kernels -- 
Joseph
> > K.
> > hasn't ported it -- likely because its slightly hackish .. And Lord
KNOWS
> > why
> > netmeeting is working through my firewall ... other than the fact of a
> good
> > old ESTABLISHED RELATED rule ... I do know that it only works outbound,
> if
> > someone wants to call into the LAN they have to call on a specific port
> and
> > I
> > have that port forwarded to the destination host.
> >
> >  As such, this is Yet Another Thing I might look at.
> >
> >
> >  Alistair Tonner
> >
> > >
> > > Regards,
> > > Norman
> >
> >
> >
> >
> >
>
>
>
>
>

libipq

[Simon]

Hi there,
  I've been working with iptables a long time but only as a newbie.
Now I moved up the ladder to the rank of amateur and I made myself a
companion program to iptables that helps manage it.
  One more thing i whish to do is to examine packets one after the
other (only certain types of packet, not all traffic) and I understand
I should QUEUE packets and use libipq to read those packets.

  Now my question: is this a good place for any questions regarding
libipq ?  And if it is, can you guys tell me in advance where I can
find a more in-depth documentation that the simple man-page i could
only find?

Thanks,
  Simon

Re: libipq

[Eric Leblond]

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

Hi,

Le samedi 09 juin 2007 à 12:46 -0500, Simon a écrit :
> Hi there,
>   I've been working with iptables a long time but only as a newbie.
> Now I moved up the ladder to the rank of amateur and I made myself a
> companion program to iptables that helps manage it.
>   One more thing i whish to do is to examine packets one after the
> other (only certain types of packet, not all traffic) and I understand
> I should QUEUE packets and use libipq to read those packets.

You should not use the deprecated and almost dead ipq. Use
libnetfilter_queue.

> 
>   Now my question: is this a good place for any questions regarding
> libipq ?

Yes

>   And if it is, can you guys tell me in advance where I can
> find a more in-depth documentation that the simple man-page i could
> only find?

libnetfilter_queue or ip_queue lack documentation but you can look at
some code sample like the one I wrote for NuFW :
http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall/nufw/trunk/nufw/src/nufw/packetsrv.c

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

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libipq

[Simon]

Hi Eric,
  thanks for the quick reply!  I was misled by "libipq" and I found
all I need to get started, already downloaded the 2 libs (main one and
_queue) and I'm trying to compile right now (well... i'm still
compiling deps though).

  I got lots of things to try now and hopefully I'll be back later
with good questions.

Thanks,
  Simon

On 6/9/07, Eric Leblond <eric@inl.fr> wrote:
> Hi,
>
> Le samedi 09 juin 2007 à 12:46 -0500, Simon a écrit :
> > Hi there,
> >   I've been working with iptables a long time but only as a newbie.
> > Now I moved up the ladder to the rank of amateur and I made myself a
> > companion program to iptables that helps manage it.
> >   One more thing i whish to do is to examine packets one after the
> > other (only certain types of packet, not all traffic) and I understand
> > I should QUEUE packets and use libipq to read those packets.
>
> You should not use the deprecated and almost dead ipq. Use
> libnetfilter_queue.
>
> >
> >   Now my question: is this a good place for any questions regarding
> > libipq ?
>
> Yes
>
> >   And if it is, can you guys tell me in advance where I can
> > find a more in-depth documentation that the simple man-page i could
> > only find?
>
> libnetfilter_queue or ip_queue lack documentation but you can look at
> some code sample like the one I wrote for NuFW :
> http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall/nufw/trunk/nufw/src/nufw/packetsrv.c
>
> BR,
> --
> Eric Leblond <eric@inl.fr>
> INL
>
>

libipq

[Micheal Scofield]

I'm trying to use the libipq fucntions such as ipq_create_handle in C,
but I keep getting the error 

too many arguments to function `ipq_create_handle'

I tried downloading the latest libnetfilter_queue files by wget-ing it,
and I can see after "./configure"ing, "make"ing and "make install"ing it
that there is a new libipq.h file with 2 arguments for the function
"ipq_create_handle", but I'm not sure how to successfully get those into
my include files. I tried "cp"ing it, but that ended up with more errors
after I compiled.

Luckily I kept a backup of the old libipq.h file and put it back... It
was a stupid idea, I know. but what am I supposed to do to use the
updated functions.

Your help is grately apreeshiated.

Re: libipq

[Eric Leblond]

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

Hi,

Le Tue, 14 Aug 2007 21:33:12 +0400,
Micheal Scofield <dtsmedia@easynet.co.uk> a écrit :

> I'm trying to use the libipq fucntions

Don't use libipq, it's fully deprecated.


> such as ipq_create_handle in C,
> but I keep getting the error 
> 
> Your help is grately apreeshiated.

If you need to port some code to libnetfilter_queue, please have a look
to snort-inline or nufw which can use both systems.

snort-inline: http://snort-inline.sourceforge.net/
nufw: http://www.nufw.org

BR,
- -- 
Eric Leblond <eric@regit.org>
NuFW, Now User Filtering Works : http://www.nufw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGwgpsnxA7CdMWjzIRAoRTAJ4wIHHPfxuQjuILw7pEvDItSj8l6QCfZIwO
dIyAAT+rh6Oz3NL+K8SnRmI=
=7yMD
-----END PGP SIGNATURE-----