home 
wiki
wiki
MWRPFrottleDevDiscussion
Frottle uses the iptables QUEUE target to delay outgoing traffic. The QUEUE target was designed to allow userspace applications, like Frottle, to inspect and control network traffic.The QUEUE target is explained here:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.4Here is the relevant exerpt:
QUEUE is a special target, which queues the packet for userspace processing. For this to be useful, two further components are required:
- a "queue handler", which deals with the actual mechanics of passing packets between the kernel and userspace; and
- a userspace application to receive, possibly manipulate, and issue verdicts on packets.
The standard queue handler for IPv4 iptables is the ip_queue module, which is distributed with the kernel and marked as experimental.
The following is a quick example of how to use iptables to queue packets for userspace processing:
# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE
With this rule, locally generated outgoing ICMP packets (as created with, say, ping) are passed to the ip_queue module, which then attempts to deliver the packets to a userspace application. If no userspace application is waiting, the packets are dropped.
To write a userspace application, use the libipq API. This is distributed with iptables. Example code may be found in the testsuite tools (e.g. redirect.c) in CVS.
The status of ip_queue may be checked via:
/proc/net/ip_queue
The maximum length of the queue (i.e. the number packets delivered to userspace with no verdict issued back) may be controlled via:
/proc/sys/net/ipv4/ip_queue_maxlen
The default value for the maximum queue length is 1024. Once this limit is reached, new packets will be dropped until the length of the queue falls below the limit again. Nice protocols such as TCP interpret dropped packets as congestion, and will hopefully back off when the queue fills up. However, it may take some experimenting to determine an ideal maximum queue length for a given situation if the default value is too small.
Presently, Frottle is only capable of acting on one network interface at a time on the host on which it is running. To be part of a truly scalable network, it would be desireable for Frottle to act on any and all of a hosts' wireless interfaces. For instance, a host may have one interface which is acting as a Access Point, and two more interfaces making client connections to two remote APs. It would be desireable for Frottle to be able to simultaneously act as a Master on the AP interface and as a Client on each of the client interfaces.
As mentioned in the exeprt above, the QUEUE target requires:
a userspace application to receive, possibly manipulate, and issue verdicts on packets.
Frottle does this, but currently it is able to manipulate the transmit order of packets in the QUEUE based on port number only. This is the controlled by the "HIPORT" paramater in the Frottle config file.
For Frottle to be able to act on different interfaces, it needs to be able to manipulate packets in the QUEUE based on their destination IP or Ethernet MAC address also. Packets being sent to one interface will be within a certain IP address range, packets being sent to another interface will be from a different IP address range.
LIBIPQ is the API that allows userspace applications to inspect an manipulate the packets in the QUEUE. Doing a search on Google turns up some info:
Google Search - libipqGoogle Search - "libipq" addressA good place to start is here:
Quick Intro to libipqFrom reading the various pages out there on LIBIPQ, it appears it can read a field called "hw_addr" from the "ipq_packet_msg" record. This is the source MAC address of the packet. This is useful to us, as it tells us out which interface the packet is destined to leave the host. It is unclear at this point wether or not packets sent to the QUEUE from the FORWARD and OUTPUT chains will have "hw_addr" set (it looks like they don't). Perhaps QUEUEing packets from the POSTROUTING chain would work better (if this is allowed).
OK, we don't need "hw_addr", iptables MARK, routing table lookups or anything like that. The name of the outgoing is contained in the packet. LIBIPQ can read it from packets in the QUEUE.
From
SuperHac.com:
ipq_packet_msg structure
Just a dump of the ipq_packet_msg structure.
ipq_packet_msg structure defined in /usr/include/linux/netfilter_ipv4/ip_queue.h:
typedef struct ipq_packet_msg {
} ipq_packet_msg_t;
Just a dump of the ipq_packet_msg structure.
ipq_packet_msg structure defined in /usr/include/linux/netfilter_ipv4/ip_queue.h:
typedef struct ipq_packet_msg {
unsigned long packet_id; /* ID of queued packet */ unsigned long mark; /* Netfilter mark value */ long timestamp_sec; /* Packet arrival time (seconds) */ long timestamp_usec; /* Packet arrvial time (+useconds) */ unsigned int hook; /* Netfilter hook we rode in on */ char indev_nameIFNAMSIZ; /* Name of incoming interface */
char outdev_nameIFNAMSIZ; /* Name of outgoing interface */
unsigned short hw_protocol; /* Hardware protocol (network order) */ unsigned short hw_type; /* Hardware type */ unsigned char hw_addrlen; /* Hardware address length */ unsigned char hw_addr8; /* Hardware address */ size_t data_len; /* Length of packet data */ unsigned char payload0; /* Optional packet data */
} ipq_packet_msg_t;
"outdev_name" is what we're after. We can use this to put packets into subqueues (inside Frottle, in userspace) based on outgoing interface name.
Version 5 (old) modified Mon, 26 Jul 2021 12:49:29 +0000 by Dan
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]