'HELP ME PLEASE. libnetfilter_queue issue

'HELP ME PLEASE. libnetfilter_queue issue

[MAI JIN]

 Hi, 

I'm a new user to libnetfilter_queue. I ran the test example of
libnetfilter_queue-1.0.0 on a Debian x86 (Linux debian 2.6.26-1-686)
host but I found that the pakcets queue in NFQUEUE were not dequeued
after recv() was invoked. I ran the iptables command on the debain host:
iptables -A INPUT -p udp --dport 8192:32000 -j NFQUEUE --queue-num 0

Then I send UDP packets from another machine with destination port in
the range. By default, the libnetfilter_queue received 1000 packets on
Debian host and stopped (blocked in recv()). Then I set the queue length
to 12000 nfq_set_queue_maxlen(qh, 1200) . This time, the
libnetfilter_queue received 1200 packets and stopped (blocked in
recv()). 

Looks like the pakcets were not dequeued from NFQUEUE? How can I fix
this problem? 

int main(int argc, char **argv) 
{ 
        struct nfq_handle *h; 
        struct nfq_q_handle *qh; 
        struct nfnl_handle *nh; 
        int fd; 
        int rv; 
        char buf[4096] __attribute__ ((aligned)); 

        printf("opening library handle\n"); 
        h = nfq_open(); 
        if (!h) { 
                fprintf(stderr, "error during nfq_open()\n"); 
                exit(1); 
        } 

        printf("unbinding existing nf_queue handler for AF_INET (if
any)\n"); 
        if (nfq_unbind_pf(h, AF_INET) < 0) { 
                fprintf(stderr, "error during nfq_unbind_pf()\n"); 
                exit(1); 
        } 

        printf("binding nfnetlink_queue as nf_queue handler for
AF_INET\n"); 
        if (nfq_bind_pf(h, AF_INET) < 0) { 
                fprintf(stderr, "error during nfq_bind_pf()\n"); 
                exit(1); 
        } 

        printf("binding this socket to queue '0'\n"); 
        qh = nfq_create_queue(h,  0, &cb, NULL); 
        if (!qh) { 
                fprintf(stderr, "error during nfq_create_queue()\n"); 
                exit(1); 
        } 

        printf("setting copy_packet mode\n"); 
        if (nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff) < 0) { 
                fprintf(stderr, "can't set packet_copy mode\n"); 
                exit(1); 
        } 

        if (nfq_set_queue_maxlen(qh, 1200) < 0) { 
                fprintf(stderr, "can't set queue_maxlen\n"); 
                exit(1); 
        } 

        fd = nfq_fd(h); 

        while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) { 
                nfq_handle_packet(h, buf, rv); 
        } 

        printf("unbinding from queue 0\n"); 
        nfq_destroy_queue(qh); 

#ifdef INSANE 
        /* normally, applications SHOULD NOT issue this command, since 
         * it detaches other programs/sockets from AF_INET, too ! */ 
        printf("unbinding from AF_INET\n"); 
        nfq_unbind_pf(h, AF_INET); 
#endif 

        printf("closing library handle\n"); 
        nfq_close(h); 

        exit(0); 
} 


Best regards 
=========================== 
Mai Jin 
Alcatel Shanghai Bell (Nanjing) Co. Ltd. 
Alcatel-Net: 2735-5011 
Tel: (+86)-25-8473 1240-5011 
Addr: 11F, Yangtse River Tech Park. 
           Building No.40 of Nanchang Road, 
           Gulou District, Nanjing, China 
Zip: 210037 
jin.mai@Alcatel-sbell.com.cn 
ASB/MoAD/RDR/BSR APL 
  

Re: 'HELP ME PLEASE. libnetfilter_queue issue

[Mistick Levi]

Hi,
Where is the Callback function?
( You use it when you call "create_queue" ), w-hen you call
handle_packet() it executes the callback you supply in
"create_queue"..

And messages are removed from the queue only after you issue a verdict
for them. until you do they will eat up you're queue space :)

in order to fix the problem, create a callback ( "cb" is the name you
issued in the create_queue function ) and issue a verdict for the
messages you receive in that callback.

Kind Regards
Yechiel Levi

On Thu, Jul 15, 2010 at 11:08 AM, MAI JIN <Jin.Mai@alcatel-sbell.com.cn> wrote:
>
>  Hi,
>
> I'm a new user to libnetfilter_queue. I ran the test example of
> libnetfilter_queue-1.0.0 on a Debian x86 (Linux debian 2.6.26-1-686)
> host but I found that the pakcets queue in NFQUEUE were not dequeued
> after recv() was invoked. I ran the iptables command on the debain host:
> iptables -A INPUT -p udp --dport 8192:32000 -j NFQUEUE --queue-num 0
>
> Then I send UDP packets from another machine with destination port in
> the range. By default, the libnetfilter_queue received 1000 packets on
> Debian host and stopped (blocked in recv()). Then I set the queue length
> to 12000 nfq_set_queue_maxlen(qh, 1200) . This time, the
> libnetfilter_queue received 1200 packets and stopped (blocked in
> recv()).
>
> Looks like the pakcets were not dequeued from NFQUEUE? How can I fix
> this problem?
>
> int main(int argc, char **argv)
> {
>        struct nfq_handle *h;
>        struct nfq_q_handle *qh;
>        struct nfnl_handle *nh;
>        int fd;
>        int rv;
>        char buf[4096] __attribute__ ((aligned));
>
>        printf("opening library handle\n");
>        h = nfq_open();
>        if (!h) {
>                fprintf(stderr, "error during nfq_open()\n");
>                exit(1);
>        }
>
>        printf("unbinding existing nf_queue handler for AF_INET (if
> any)\n");
>        if (nfq_unbind_pf(h, AF_INET) < 0) {
>                fprintf(stderr, "error during nfq_unbind_pf()\n");
>                exit(1);
>        }
>
>        printf("binding nfnetlink_queue as nf_queue handler for
> AF_INET\n");
>        if (nfq_bind_pf(h, AF_INET) < 0) {
>                fprintf(stderr, "error during nfq_bind_pf()\n");
>                exit(1);
>        }
>
>        printf("binding this socket to queue '0'\n");
>        qh = nfq_create_queue(h,  0, &cb, NULL);
>        if (!qh) {
>                fprintf(stderr, "error during nfq_create_queue()\n");
>                exit(1);
>        }
>
>        printf("setting copy_packet mode\n");
>        if (nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff) < 0) {
>                fprintf(stderr, "can't set packet_copy mode\n");
>                exit(1);
>        }
>
>        if (nfq_set_queue_maxlen(qh, 1200) < 0) {
>                fprintf(stderr, "can't set queue_maxlen\n");
>                exit(1);
>        }
>
>        fd = nfq_fd(h);
>
>        while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) {
>                nfq_handle_packet(h, buf, rv);
>        }
>
>        printf("unbinding from queue 0\n");
>        nfq_destroy_queue(qh);
>
> #ifdef INSANE
>        /* normally, applications SHOULD NOT issue this command, since
>         * it detaches other programs/sockets from AF_INET, too ! */
>        printf("unbinding from AF_INET\n");
>        nfq_unbind_pf(h, AF_INET);
> #endif
>
>        printf("closing library handle\n");
>        nfq_close(h);
>
>        exit(0);
> }
>
>
> Best regards
> ===========================
> Mai Jin
> Alcatel Shanghai Bell (Nanjing) Co. Ltd.
> Alcatel-Net: 2735-5011
> Tel: (+86)-25-8473 1240-5011
> Addr: 11F, Yangtse River Tech Park.
>           Building No.40 of Nanchang Road,
>           Gulou District, Nanjing, China
> Zip: 210037
> jin.mai@Alcatel-sbell.com.cn
> ASB/MoAD/RDR/BSR APL
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

packet flow - ebtables broute DROP target

[Aijaz Baig]

Hello people,

Im relatively new to the ebtables + iptables firewalling architecture. I
have read the ebtables and iptables firewall interaction document and
also seen the GIF specified at the end of the document. For those
unfamiliar with it, here are the links to the same:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
picture.

Im trying to understand what happens to a packet which is DROPped in the
BROUTING chain of the broute table. If I have understood correctly from
the document above, it goes to L3 where the routing subsystem can decide
where to send the packet to depending on L3 information in it isn't it?
So i'm assuming that the first place it should be visible should be the
PREROUTING chain of the mangle table isn't it? But I tried with a LOG
target rule matching the criteria I used in constructing the DROP target
in the broute table's BROUTING chain. 

And then after that I checked the packet counters for both the rules
viz. the one in the BROUTING chain and the one in the PREROUTING chain
of the mangle table. The packet did hit the first rule and it is
dropped. I cannot see it on br0, the bridge interface too. But the
packet count in the latter rule is 0 which means that the packet didnt
arrive in the mangle table's
PREhttp://ebtables.sourceforge.net/br_fw_ia/PacketFlow.pngROUTING chain.
But this behavior is contrary to what the GIF above shows.

Im rather confused. Please do shed some light on it if people have had
similar experiences before.

I am keen to hear from you,

Regards,
Aijaz Baig.

Re: packet flow - ebtables broute DROP target

[Jan Engelhardt]

On Thursday 2010-07-15 16:02, Aijaz Baig wrote:
>unfamiliar with it, here are the links to the same:
>http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
>and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
>picture.

Use http://jengelh.medozas.de/images/nf-packet-flow.png

>Im trying to understand what happens to a packet which is DROPped in the
>BROUTING chain of the broute table. If I have understood correctly from
>the document above, it goes to L3 where the routing subsystem can decide
>where to send the packet to depending on L3 information in it isn't it?

In net/core/dev.c, the packet is passed to all "taps". Taps include 
raw sockets (think tcpdump), but also bridge and the IPvX layers 
themselves. Each of them basically gets a copy, thus it is important to 
not have an address on the ethernet interface (so that the IPvX tap 
ignores it). Only the bridge interface should have an address, because 
the bridge code will pass it to IPvX on its own.

(You probably knew this, but this is a nice question plus answer for our 
planned book(s).)

So considering only bridge.c, the brouting chain can then be used to 
either move the packet along the blue L2 path or the green L3 path.

If a packet remains travelling in the blue domain (i.e. it is bridged), 
the packet _must_ have the bridge's own dst mac address to go "upwards" 
at the "bridging decision" (sort of Ethernet routing, if you want to 
call it so) circle to reach IPvX routing.

>And then after that I checked the packet counters for both the rules
>viz. the one in the BROUTING chain and the one in the PREROUTING chain
>of the mangle table. The packet did hit the first rule and it is
>dropped. I cannot see it on br0, the bridge interface too. But the
>packet count in the latter rule is 0 which means that the packet didnt
>arrive in the mangle table's

To be eligible for green traversal as a result of (bridge check), the 
packet of course needs to be one of the supported protocols.
Sending STP into the green domain has no bearing. IPX packets will be 
conntracked, but of course you won't see them in iptables or ip6tables 
(since they are not IPv4/IPv6, naturally).

Re: packet flow - ebtables broute DROP target

[Bart De Schuymer]

Aijaz Baig schreef:
> Hello people,
>
> Im relatively new to the ebtables + iptables firewalling architecture. I
> have read the ebtables and iptables firewall interaction document and
> also seen the GIF specified at the end of the document. For those
> unfamiliar with it, here are the links to the same:
> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
> and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
> picture.
>
> Im trying to understand what happens to a packet which is DROPped in the
> BROUTING chain of the broute table. If I have understood correctly from
> the document above, it goes to L3 where the routing subsystem can decide
> where to send the packet to depending on L3 information in it isn't it?
> So i'm assuming that the first place it should be visible should be the
> PREROUTING chain of the mangle table isn't it? But I tried with a LOG
> target rule matching the criteria I used in constructing the DROP target
> in the broute table's BROUTING chain. 
>
> And then after that I checked the packet counters for both the rules
> viz. the one in the BROUTING chain and the one in the PREROUTING chain
> of the mangle table. The packet did hit the first rule and it is
> dropped. I cannot see it on br0, the bridge interface too. But the
> packet count in the latter rule is 0 which means that the packet didnt
> arrive in the mangle table's
> PREhttp://ebtables.sourceforge.net/br_fw_ia/PacketFlow.pngROUTING chain.
> But this behavior is contrary to what the GIF above shows.
>
> Im rather confused. Please do shed some light on it if people have had
> similar experiences before.
>
>   
Your traffic is probably dropped by the networking code because the 
destination MAC address differs from that of the bridge port. You should 
redirect the traffic with ebtables. See 
http://ebtables.sourceforge.net/examples/basic.html#ex_brouter

cheers,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: packet flow - ebtables broute DROP target

[Bart De Schuymer]

Jan Engelhardt schreef:
> On Thursday 2010-07-15 16:02, Aijaz Baig wrote:
>   
>> unfamiliar with it, here are the links to the same:
>> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
>> and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
>> picture.
>>     
>
> Use http://jengelh.medozas.de/images/nf-packet-flow.png
>
>   
>> Im trying to understand what happens to a packet which is DROPped in the
>> BROUTING chain of the broute table. If I have understood correctly from
>> the document above, it goes to L3 where the routing subsystem can decide
>> where to send the packet to depending on L3 information in it isn't it?
>>     
>
> In net/core/dev.c, the packet is passed to all "taps". Taps include 
> raw sockets (think tcpdump), but also bridge and the IPvX layers 
> themselves. Each of them basically gets a copy, thus it is important to 
> not have an address on the ethernet interface (so that the IPvX tap 
> ignores it). Only the bridge interface should have an address, because 
> the bridge code will pass it to IPvX on its own.
>
>   
When using a brouter, you actually assign IP addresses to the bridge 
ports (different subnets) instead of the virtual bridge interface 
itself. IP traffic is then DROPped in the BROUTE chain, so it's not 
bridged. See http://ebtables.sourceforge.net/examples/real.html#example1 
for an example usage.

cheers,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: packet flow - ebtables broute DROP target

[Aijaz Baig]

Hello Bart and Jan,

Sorry for the belated reply. Im in India so the time gaps makes it bad.
Thank you for your great inputs. I would surely consider them now. Thank
you Jan for letting us know you guys are writing a book on netfilter.
Lord knows we need it. More and more companies across the globe are
using linux more and more now. This would be of immense help to
academicians and professionals alike.

Ive got 2 linux boxes, one virtual and one real. The real one has a eth0
interface which connects to my LAN. It's vmnet8 interface is behind the
virtual linux box's eth0 interface i.e. the latter is the former's
gateway. The virtual box has 3 interfaces eth0, eth1 and eth2. Out of
which eth0 and eth1 are bridged and enslaved to br0. eth2 connects to
the same LAN as does my real box's eth0. I have added a static route for
a PC in my outer LAN to force the traffic to go through vmnet8.

Now when I DROP packets for the target PC in the broute table, the
problem that I described above happens. I did what was told to be done
as shown the basic brouter example. But still..zilch..nothing seemed to
be working. 

To be specific, I added a rule:
ebtables -t broute -A BROUTING -p 0x806 --d$MAC_OF_eth0 -j DROP 
to allow the arp replies to arrive on eth0 and not on br0. But even
after that it didn't work. Even the packet count for this new rule was
zero all the time so I guess something was suspicious here.

Could someone, bart maybe, let me know what it means by his quote: "Your
traffic is probably dropped by the networking code because the 
destination MAC address differs from that of the bridge port."

May be I don't really know ARP works to infer how such a rule would be
helpful in the first place.

I am keen to hear frm you guys and once again, thank you for your input
and such wonderful open source software that would put the big guys out
there to shame.

Regards,
Aijaz

On Thu, 2010-07-15 at 21:26 +0200, Bart De Schuymer wrote: 
> Jan Engelhardt schreef:
> > On Thursday 2010-07-15 16:02, Aijaz Baig wrote:
> >   
> >> unfamiliar with it, here are the links to the same:
> >> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
> >> and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
> >> picture.
> >>     
> >
> > Use http://jengelh.medozas.de/images/nf-packet-flow.png
> >
> >   
> >> Im trying to understand what happens to a packet which is DROPped in the
> >> BROUTING chain of the broute table. If I have understood correctly from
> >> the document above, it goes to L3 where the routing subsystem can decide
> >> where to send the packet to depending on L3 information in it isn't it?
> >>     
> >
> > In net/core/dev.c, the packet is passed to all "taps". Taps include 
> > raw sockets (think tcpdump), but also bridge and the IPvX layers 
> > themselves. Each of them basically gets a copy, thus it is important to 
> > not have an address on the ethernet interface (so that the IPvX tap 
> > ignores it). Only the bridge interface should have an address, because 
> > the bridge code will pass it to IPvX on its own.
> >
> >   
> When using a brouter, you actually assign IP addresses to the bridge 
> ports (different subnets) instead of the virtual bridge interface 
> itself. IP traffic is then DROPped in the BROUTE chain, so it's not 
> bridged. See http://ebtables.sourceforge.net/examples/real.html#example1 
> for an example usage.
> 
> cheers,
> Bart
> 

Re: packet flow - ebtables broute DROP target

[Bart De Schuymer]

Aijaz Baig schreef:
> Hello Bart and Jan,
>
> Sorry for the belated reply. Im in India so the time gaps makes it bad.
> Thank you for your great inputs. I would surely consider them now. Thank
> you Jan for letting us know you guys are writing a book on netfilter.
> Lord knows we need it. More and more companies across the globe are
> using linux more and more now. This would be of immense help to
> academicians and professionals alike.
>
> Ive got 2 linux boxes, one virtual and one real. The real one has a eth0
> interface which connects to my LAN. It's vmnet8 interface is behind the
> virtual linux box's eth0 interface i.e. the latter is the former's
> gateway. The virtual box has 3 interfaces eth0, eth1 and eth2. Out of
> which eth0 and eth1 are bridged and enslaved to br0. eth2 connects to
> the same LAN as does my real box's eth0. I have added a static route for
> a PC in my outer LAN to force the traffic to go through vmnet8.
>
> Now when I DROP packets for the target PC in the broute table, the
> problem that I described above happens. I did what was told to be done
> as shown the basic brouter example. But still..zilch..nothing seemed to
> be working. 
>
> To be specific, I added a rule:
> ebtables -t broute -A BROUTING -p 0x806 --d$MAC_OF_eth0 -j DROP 
> to allow the arp replies to arrive on eth0 and not on br0. But even
> after that it didn't work. Even the packet count for this new rule was
> zero all the time so I guess something was suspicious here.
>
> Could someone, bart maybe, let me know what it means by his quote: "Your
> traffic is probably dropped by the networking code because the 
> destination MAC address differs from that of the bridge port."
>
> May be I don't really know ARP works to infer how such a rule would be
> helpful in the first place.
>
>   
This is explained at the link I gave you. If something is unclear in my 
description on the website, feel free to let me know.
Try it out with the example rules I mention on that site and adapt to 
your situation from there. In the future, please explicitly list your 
complete test setup, including a dump of the firewall tables.

cheers,
Bart


-- 
Bart De Schuymer
www.artinalgorithms.be

Re: packet flow - ebtables broute DROP target

[Payam Chychi]

hey,

how are u checking the table? make sure u are looking at the NAT table and not input or forwarding.

Regards,
--
Payam Tarverdyan Chychi
Network Engineer

Sent from my iPhone

On 2010-07-16, at 10:05 AM, Aijaz Baig <aijazbaig1@gmail.com> wrote:

> Hello Bart and Jan,
> 
> Sorry for the belated reply. Im in India so the time gaps makes it bad.
> Thank you for your great inputs. I would surely consider them now. Thank
> you Jan for letting us know you guys are writing a book on netfilter.
> Lord knows we need it. More and more companies across the globe are
> using linux more and more now. This would be of immense help to
> academicians and professionals alike.
> 
> Ive got 2 linux boxes, one virtual and one real. The real one has a eth0
> interface which connects to my LAN. It's vmnet8 interface is behind the
> virtual linux box's eth0 interface i.e. the latter is the former's
> gateway. The virtual box has 3 interfaces eth0, eth1 and eth2. Out of
> which eth0 and eth1 are bridged and enslaved to br0. eth2 connects to
> the same LAN as does my real box's eth0. I have added a static route for
> a PC in my outer LAN to force the traffic to go through vmnet8.
> 
> Now when I DROP packets for the target PC in the broute table, the
> problem that I described above happens. I did what was told to be done
> as shown the basic brouter example. But still..zilch..nothing seemed to
> be working. 
> 
> To be specific, I added a rule:
> ebtables -t broute -A BROUTING -p 0x806 --d$MAC_OF_eth0 -j DROP 
> to allow the arp replies to arrive on eth0 and not on br0. But even
> after that it didn't work. Even the packet count for this new rule was
> zero all the time so I guess something was suspicious here.
> 
> Could someone, bart maybe, let me know what it means by his quote: "Your
> traffic is probably dropped by the networking code because the 
> destination MAC address differs from that of the bridge port."
> 
> May be I don't really know ARP works to infer how such a rule would be
> helpful in the first place.
> 
> I am keen to hear frm you guys and once again, thank you for your input
> and such wonderful open source software that would put the big guys out
> there to shame.
> 
> Regards,
> Aijaz
> 
> On Thu, 2010-07-15 at 21:26 +0200, Bart De Schuymer wrote: 
>> Jan Engelhardt schreef:
>>> On Thursday 2010-07-15 16:02, Aijaz Baig wrote:
>>> 
>>>> unfamiliar with it, here are the links to the same:
>>>> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
>>>> and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
>>>> picture.
>>>> 
>>> 
>>> Use http://jengelh.medozas.de/images/nf-packet-flow.png
>>> 
>>> 
>>>> Im trying to understand what happens to a packet which is DROPped in the
>>>> BROUTING chain of the broute table. If I have understood correctly from
>>>> the document above, it goes to L3 where the routing subsystem can decide
>>>> where to send the packet to depending on L3 information in it isn't it?
>>>> 
>>> 
>>> In net/core/dev.c, the packet is passed to all "taps". Taps include 
>>> raw sockets (think tcpdump), but also bridge and the IPvX layers 
>>> themselves. Each of them basically gets a copy, thus it is important to 
>>> not have an address on the ethernet interface (so that the IPvX tap 
>>> ignores it). Only the bridge interface should have an address, because 
>>> the bridge code will pass it to IPvX on its own.
>>> 
>>> 
>> When using a brouter, you actually assign IP addresses to the bridge 
>> ports (different subnets) instead of the virtual bridge interface 
>> itself. IP traffic is then DROPped in the BROUTE chain, so it's not 
>> bridged. See http://ebtables.sourceforge.net/examples/real.html#example1 
>> for an example usage.
>> 
>> cheers,
>> Bart
>> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html