[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with Netfilter (Packet Marking) and ip util



Title: Problem with Netfilter (Packet Marking) and ip util

Hi all,

Background
----------
The box in question is running kernel 2.4.0-test5 (I need this kernel for a specific MPLS + TC patch which destabilizes on later kernels).  System is Redhat 6.2, iptables 1.1.0, iproute2 (March 5, 2000).

I have an incoming UDP data stream, source and destination IP are consistent within each packet, but I vary the destination port, starting at 1024 and counting to 1123.  My intent is to mark 50% of the incoming packets (those with dports 1024:1073) with one marker, and the other 50% (1074:1123) with another marker.  The ip util would then be called to create two new routing tables, based on these markers, implement the routing tables, and finally mplsadm (James Leu) with Steven Van den Berghe's TC (diffserv for mpls) patches is called to build two MPLS paths based on the contents of the new routing tables.

The Problem
-----------
This all works if the marks I specify with iptables are < 10.  Anything higher, and the packets appear to be missed by either the netfilter code or the ip code. 

mplsadm simply operates on the contents of the routing tables, so I figure the problem must lie earlier on in the chain of events.

I've tried looking at the code for netfilter, and have determined that the marker should be an unsigned int, which should accomodate 10, 11, etc as marks.

Related Issues
--------------
1.  What purpose would a mark on a packet serve?  Why would people do this?  (Genuinely interested since it may help me debug the problem).  If I can try another application/test which uses packet marking, I can see if the packets are in fact being marked or not.  Even a quick and dirty utility/patch to dump the relevant portion of the skbuff structure would show whether netfilter is at fault or not.

2.  Testing ip routing tables other than the default table is something I'm not sure how to accomplish.  If I stick a remote network into a user-defined routing table, ping reports that the destination address is unknown, but I've definately created the route entry - I can see it via 'ip route show table ...' and mplsadm is able to use it to properly create the paths.  Is ping is need of  a patch?

Any thoughts on where to go from here?

Cheers!
Jon