0

From my Raspberry Pi configured as an access point, I set the following rules:

sudo iptables -I FORWARD -p tcp --sport 25 -j NFQUEUE --queue-num 0
sudo iptables -I FORWARD -p tcp --sport 80 -j NFQUEUE --queue-num 1
sudo iptables -I FORWARD -p udp --sport 5060 -j NFQUEUE --queue-num 2
sudo iptables -I FORWARD -p tcp --sport 5060 -j NFQUEUE --queue-num 2

My purpose is to forward packets coming from port 5060 before packets from port 80 and way before packets from port 25 (a rude Quality of Service implementation where I'm trying to give the highest priority to "Skype packets" (from 5060), medium priority to "HTTP packets" (port 80) and low priority to "SMTP packets" (port 25)).

I'm using libnetfilter_queue library: how can I use nfq_set_verdict to delay a low priority packet?

NF_QUEUE inject the packet into a different queue (the target queue number is in the high 16 bits of the verdict) but don't continue iterations

NF_REPEAT iterate the same cycle once more

Maybe I don't get something about the two flags above: how can I use them in order to put a low priority packet in delay?

elmazzun
  • 153
  • 1
  • 2
  • 7

2 Answers2

3

You don't need to do NF_DROP verdict on incoming packet and resend it via raw socket. You can hold packet in your own queue, and verdict it later (say, after some delay).

I wrote a simple traffic shaper in Linux userspace with this technique: https://github.com/vmxdev/damper/

Using only NFQUEUE for delaying packets simplifies iptables rules. You don't have to think from which interface reinject packets and how it will interract with conntrack

vmx
  • 31
  • 2
0

Got the answer here: I didn't know that nfq_set_verdict could be called only once per packet, so after doing NF_DROP verdict on each packet (after copying it in my userspace application) I can't call again nfq_set_verdict with NF_ACCEPT. Therefore, open a raw socket for sending queued packets.

https://stackoverflow.com/questions/31368816/sending-queued-packets-with-nfqueue

elmazzun
  • 153
  • 1
  • 2
  • 7
  • How do you prevent your raw socket packet just going back in the same queue and straight back to your application if you send it to the same destination? – Thomas Apr 24 '16 at 05:15