<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.security.firewalls.netfilter.devel">
    <title>gmane.comp.security.firewalls.netfilter.devel</title>
    <link>http://blog.gmane.org/gmane.comp.security.firewalls.netfilter.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42813"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42798"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42796"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42788"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42774"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42766"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42763"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42760"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42753"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42748"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42747"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42746"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42745"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42744"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42743"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42741"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42739"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42736"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42733"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42716"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42813">
    <title>[v5 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42813</link>
    <description>&lt;pre&gt;Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
the queue fills up and connections fail when large number of packets
get dropped.

This patch implements a "failopen" support for NFQUEUE to help keep
connections open during such failures. This is achieved by allowing
acceptance of packets temporarily when the queue is full, which
enables existing connections to be kept open.

Failopen is enabled/disabled using a new call - nfq_set_flags(qh,
mask, flags), which makes use of two new netlink attributes:
NFQA_CFG_MASK -  Specifies which flags are being modified.
NFQA_CFG_FLAGS - Set/reset the bits for each of those flags.


Tests done:
------------
- netperf TCP_STREAM.
- 64 netperf stress testing to ensure there are no memory leaks.
- icmp ping.
- enabling/disabling failopen in the middle of existing connections.
- checksum verification of transferred files using scp.
- different flag/mask values to check that code handling NFQA_CFG_MASK
  works as expected.


Test results:
-------------
Server:
-------
# iptables -A INPUT -p tcp -m mac --mac-source 00:00:C9:C6:4F:22 \
-j NFQUEUE --queue-num 0
# Run interceptor program with 50ms delay between packet processing,
  and also sets qlen to 16. After every read system call, this program
  tests and read's a config file's contents and calls
  nfq_set_flags(qh, mask, flags).

Client:
-------
---&amp;gt; failopen is disabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
0.16   
---&amp;gt; failopen is enabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
2292.82 

---&amp;gt; failopen is disabled on server at this time
# scp FILE 10.0.4.1:/tmp
FILE                             0% 2960KB  88.4KB/s 12:19:37 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             21%  809MB  44.2MB/s   01:08 ETA
---&amp;gt; Disable failopen on server at this time
FILE                             23%  903MB 157.4KB/s 5:18:01 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             100% 3835MB  24.1MB/s   02:39    

Changes from rev4:
------------------

1. Localize all changes to net/netfilter/nfnetlink_queue.c, which
helps remove GSO handling and other code in core.


Changes from rev3:
------------------

1. Changed flags/mask to big-endian.
2. Use nla_get_be32 instead of nla_data to access flags/masks.
3. Cleaned up some comments.


Changes from rev2:
------------------

1. Changed NFQA_CFG_FAIL_OPEN to generic NFQA_CFG_FLAGS and NFQA_CFG_MASK to
support new flags/options in future.
2. Enqueue handler changed to return -ENOSPC on queue-full condition.
3. Do not invoke okfn on -ENOSPC, but process all hooks first. nf_hook_slow
   has code to handle failopen.

Please review.

Signed-off-by: Krishna Kumar &amp;lt;krkumar2&amp;lt; at &amp;gt;in.ibm.com&amp;gt;
Signed-off-by: Vivek Kashyap &amp;lt;vivk&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
Signed-off-by: Sridhar Samudrala &amp;lt;samudrala&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
---

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Krishna Kumar</dc:creator>
    <dc:date>2012-05-24T13:56:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42798">
    <title>[v4 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42798</link>
    <description>&lt;pre&gt;Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
the queue fills up and connections fail when large number of packets
get dropped.

This patch implements a "failopen" support for NFQUEUE to help keep
connections open during such failures. This is achieved by allowing
acceptance of packets temporarily when the queue is full, which
enables existing connections to be kept open.

Failopen is enabled/disabled using a new call - nfq_set_flags(qh,
mask, flags), which makes use of two new netlink attributes:
NFQA_CFG_MASK -  Specifies which flags are being modified.
NFQA_CFG_FLAGS - Set/reset the bits for each of those flags.


Tests done:
------------
- netperf TCP_STREAM
- 64 netperf stress testing to ensure there are no memory leaks
- icmp ping
- enabling/disabling failopen in the middle of existing connections
- checksum verification of transferred files using scp
- different flag/mask values to check that code handling NFQA_CFG_MASK
  works as expected


Test results:
-------------
Server:
-------
# iptables -A INPUT -p tcp -m mac --mac-source 00:00:C9:C6:4F:22 \
-j NFQUEUE --queue-num 0
# Run interceptor program with 50ms delay between packet processing,
  and also sets qlen to 16. After every read system call, this program
  tests and read's a config file's contents and calls
  nfq_set_flags(qh, mask, flags).

Client:
-------
---&amp;gt; failopen is disabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
0.16   
---&amp;gt; failopen is enabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
2292.82 

---&amp;gt; failopen is disabled on server at this time
# scp FILE 10.0.4.1:/tmp
FILE                             0% 2960KB  88.4KB/s 12:19:37 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             21%  809MB  44.2MB/s   01:08 ETA
---&amp;gt; Disable failopen on server at this time
FILE                             23%  903MB 157.4KB/s 5:18:01 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             100% 3835MB  24.1MB/s   02:39    


Changes from rev3:
------------------

1. Changed flags/mask to big-endian.
2. Use nla_get_be32 instead of nla_data to access flags/masks.
3. Cleaned up some comments.


Changes from rev2:
------------------

1. Changed NFQA_CFG_FAIL_OPEN to generic NFQA_CFG_FLAGS and NFQA_CFG_MASK to
support new flags/options in future.
2. Enqueue handler changed to return -ENOSPC on queue-full condition.
3. Do not invoke okfn on -ENOSPC, but process all hooks first. nf_hook_slow
   has code to handle failopen.

Please review.

Signed-off-by: Krishna Kumar &amp;lt;krkumar2&amp;lt; at &amp;gt;in.ibm.com&amp;gt;
Signed-off-by: Vivek Kashyap &amp;lt;vivk&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
Signed-off-by: Sridhar Samudrala &amp;lt;samudrala&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
---

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Krishna Kumar</dc:creator>
    <dc:date>2012-05-24T08:25:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42796">
    <title>reason that iptables mac module only has mac-source option</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42796</link>
    <description>&lt;pre&gt;hi guys,

I am working on the mac module, and I added some arp related options
in it. I noticed that this module originally has only --mac-source
options in it. At first I think maybe author didn't want touch any
output packet. But now I doubt that maybe iptables hook point doesn't
support to do so. That is why I came here asking you guys for help. I
think in iptables OUTPUT hook point, it has not yet generate any 2nd
level information in the skb buffer, hasn't it? That is why mac module
can only touch incoming packet because only the incoming packet takes
the mac information in iptables

anybody can answer me? thanks a lot

BRs
jerry ma
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>JieYue Ma</dc:creator>
    <dc:date>2012-05-24T04:47:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42788">
    <title>[README] patches that did not reach net-next (upcoming 3.5)</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42788</link>
    <description>&lt;pre&gt;Hi!

David has closed net-next merge window.

I know there are several patches still on the table, you can see the
list here:

http://patchwork.ozlabs.org/project/netfilter-devel/list/

Some of them are small enough that I did not feel like pushing hard
for them to David, like the one from Amerigo Wang, Alban Crequy and
Denys Fedoryshchenko. My plan is to include them once merge window
opens again.

Gao Feng's namespace ct timeout requires another spin.

For bugfixes, I'll start collecting them to pass them asap.

Thanks for your work!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Pablo Neira Ayuso</dc:creator>
    <dc:date>2012-05-23T11:00:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42774">
    <title>Using RELATED for a level4 protocol (MPTCP)</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42774</link>
    <description>&lt;pre&gt;Hi everyone,

I'm a complete newbie in netfilter hacking and I'm trying to implement
the support of MPTCP [0] (standing for MultiPath TCP) in netfilter in
the context of a master's thesis.

I'll just summarize some points of MPTCP here to get a chance to be
understood with my request.
MPTCP is an extension of TCP which enables it to use multiple paths as
part of a single "MPTCP connection", answering to a multihoming and
performance demand. It acts as a higher-level, using TCP connections
as subflows and it has been designed to be backward-compatible with
regular TCP.
It exposes a similar interface to TCP to the application layer. A
figure might help to get the whole thing:

       +-------------------------------+
       |           Application         |
       +-------------------------------+
       |             MPTCP             |
       + - - - - - - - + - - - - - - - +
       | Subflow (TCP) | Subflow (TCP) |
       +-------------------------------+
       |       IP      |      IP       |
       +-------------------------------+
(If you cannot read it properly, the 2 figures in this mail are taken
from [0] where they are displayed correctly with a monospace font).

It's currently being standardized by the IETF.
Furthermore, a Linux implementation is already available and working fine [1].

Now, what I'd like some help with is for the handling of additional
subflows.  Here is a figure to illustrate the setup of an additional
subflow.

              Host A                                  Host B
     ------------------------                       ----------
     Address A1    Address A2                       Address B1
     ----------    ----------                       ----------
         |             |                                |
         |             | SYN + MP_CAPABLE               |
Initial subflow negotiation
         |---------------------------------------------&amp;gt;|
         |&amp;lt;---------------------------------------------|
         |          SYN/ACK + MP_CAPABLE(Key-B)         |
         |             |                                |
         |        ACK + MP_CAPABLE(Key-A, Key-B)        |
         |---------------------------------------------&amp;gt;|
         |             |                                |
         |             |   SYN + MP_JOIN(Token-B, R-A)  |
Additional subflow
         |             |-------------------------------&amp;gt;|
         |             |&amp;lt;-------------------------------|
         |             |  SYN/ACK + MP_JOIN(MAC-B, R-B) |
         |             |                                |
         |             |      ACK + MP_JOIN(MAC-A)      |
         |             |-------------------------------&amp;gt;|
         |             |                                |

As subflows are negotiated (and authenticated) with an option in a
regular TCP handshake, I'd like to know if there is currently a simple
way of accepting new subflow packets with netfilter.
Specifically, I thought of handling the MP_JOIN with a kind of
conntrack's RELATED state. Indeed, the first packet of the MP_JOIN
step can be "expected" and verified to be originating from the same
host than the initial subflow.

After inspection of the code, I doubt that this would be possible as
the expectation setup takes the ip addresses and ports as parameters.
I therefore assume that the whole expectation system is only usable
for protocols on the application level?
Could you confirm that it's not the good way to go?
But then, do you see any tool in the framework that would be helpful
to me? Or give me some advices/pointers to integrate this in an
elegant way into netfilter ?

In advance, thank you!


[0] http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-07
[1] http://mptcp.info.ucl.ac.be/


&lt;/pre&gt;</description>
    <dc:creator>Nicolas Maître</dc:creator>
    <dc:date>2012-05-22T20:51:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42766">
    <title>[v3 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42766</link>
    <description>&lt;pre&gt;Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
NFQUEUE queue (default 1024 entries) fills up and connections fail
after large number of packets drop during enqueue.

This patch implements a "failopen" support for NFQUEUE to help keep
connections open during such failures. This is achieved by allowing
acceptance of packets temporarily when the queue is full, which enables
existing connections to be kept open.

Failopen is enabled/disabled using a new call - nfq_set_flags(qh, mask,
flags), which makes use of two new netlink attributes:
1. NFQA_CFG_MASK:  Specifies which flags are being modified.
2. NFQA_CFG_FLAGS: Set/reset the value for each of those flags.


Tests done:
------------
- netperf TCP_STREAM
- 64 netperf stress testing to ensure there are no memory leaks
- icmp (ping)
- enabling/disabling failopen in the middle of existing connections
- checksum verification of transferred files (scp)
- different flag/mask values to check that code handling NFQA_CFG_MASK
  works as expected


Test results:
-------------
Server:
-------
# iptables -A INPUT -p tcp -m mac --mac-source 00:00:C9:C6:4F:22 \
-j NFQUEUE --queue-num 0
# Run interceptor program with 50ms delay between packet processing, and also
sets qlen to 16. After every read system call, this program tests and read's a
config file's contents (0 or 1) and calls nfq_set_flags(qh, mask, flags).

Client:
-------
---&amp;gt; failopen is disabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
0.16   
---&amp;gt; failopen is enabled on server at this time
# netperf -v0 -H 10.0.4.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.4.1 (10.0.4.1) port 0 AF_INET
2292.82 

---&amp;gt; failopen is disabled on server at this time
# scp FILE 10.0.4.1:/tmp
FILE                             0% 2960KB  88.4KB/s 12:19:37 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             21%  809MB  44.2MB/s   01:08 ETA
---&amp;gt; Disable failopen on server at this time
FILE                             23%  903MB 157.4KB/s 5:18:01 ETA
---&amp;gt; Enable failopen on server at this time
FILE                             100% 3835MB  24.1MB/s   02:39    


Changes from rev2:
------------------

1. Changed NFQA_CFG_FAIL_OPEN to generic NFAQ_CFG_FLAGS and NFAQ_CFG_MASK
2. Enqueue handler now returns -ENOSPC upon "fail-open".
3. Do not invoke okfn on ENOSPC, but process all hooks first. nf_hook_slow
   has code to handle failopen.

Please review.

Signed-off-by: Krishna Kumar &amp;lt;krkumar2&amp;lt; at &amp;gt;in.ibm.com&amp;gt;
Signed-off-by: Vivek Kashyap &amp;lt;vivk&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
Signed-off-by: Sridhar Samudrala &amp;lt;samudrala&amp;lt; at &amp;gt;us.ibm.com&amp;gt;
---

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Krishna Kumar</dc:creator>
    <dc:date>2012-05-22T12:10:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42763">
    <title>[PATCH] netfilter conntrack helper: nf_ct_h323: fix bug in rtcp natting</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42763</link>
    <description>&lt;pre&gt;The nat_rtp_rtcp hook takes two separate parameters port and rtp_port.

port is expected to be the real h245 address(found inside the packet).
rtp_port is the even number closest to port  (RTP ports are even and 
RTCP ports are odd)

However currently, both port and rtp_port are having same value(both are 
rounded to nearest even numbers).

This works well in case of openlogicalchannel with media (RTP/even) port.

But in case of openlogicalchannel for media control (RTCP/odd) port, 
h245 address in the packet is wrongly modified to have an even port.

I am attaching a pcap demonstrating the problem, for any further analysis.

This behavior was introduced around v2.6.19 while rewriting the helper.



Signed-off-by: Jagdish Motwani &amp;lt;jagdish.motwani&amp;lt; at &amp;gt;elitecore.com&amp;gt;
Signed-off-by: Sanket Shah &amp;lt;sanket.shah&amp;lt; at &amp;gt;elitecore.com&amp;gt;

--
diff --git a/net/netfilter/nf_conntrack_h323_main.c 
b/net/netfilter/nf_conntrack_h323_main.c
index 46d69d7..7f0de36 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -270,9 +270,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int expect_rtp_rtcp(struct sk_buff *skb, 
struct nf_conn *ct,
                 return 0;

         /* RTP port is even */
-       port &amp;amp;= htons(~1);
-       rtp_port = port;
-       rtcp_port = htons(ntohs(port) + 1);
+       rtp_port = port &amp;amp; htons(~1);
+       rtcp_port = htons(ntohs(rtp_port) + 1);

         /* Create expect for RTP */
         if ((rtp_exp = nf_ct_expect_alloc(ct)) == NULL)

&lt;/pre&gt;</description>
    <dc:creator>Jagdish Motwani</dc:creator>
    <dc:date>2012-05-22T06:00:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42760">
    <title>[README] net-next has been merged</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42760</link>
    <description>&lt;pre&gt;
Linus has pulled in all of the net-next changes, and I have
subsequently fast-forwarded both 'net' and 'net-next' to
Linus's tree.

All work at this time should be bug fixes and should be arranged
against 'net'.  'net-next' will be frozen and untouched until
some time after the merge window closes, and no development should
occur against it.

I am rejecting all patches in patchwork which implement new features,
perform cleanups, or otherwise are inappropriate at this time.  You
must resubmit them when the net-next tree opens back up.

There is one exception waiting in the wings, there is one netfilter
pull remaining from Pedro for the merge window and I told him that
this is OK.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2012-05-21T21:09:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42753">
    <title>libnetfilter_conntrack updates</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42753</link>
    <description>&lt;pre&gt;
The following changes since commit 6fdd30fe6de1311022ae9e17304dd72f4958bbb8:

  build: bump version to 1.0.1 (2012-05-18 01:24:29 +0200)

are available in the git repository at:
  git://git.inai.de/libnetfilter_conntrack master

Jan Engelhardt (4):
      build: remove unused LDFLAGS
      qa: change an if to elseif
      build: remove unused -DLIBNETFILTER_CONNTRACK_DIR
      Update .gitignore

 configure.ac            |    5 -----
 qa/.gitignore           |    2 ++
 qa/Makefile.am          |    4 ----
 qa/ct_events_reliable.c |    2 +-
 utils/.gitignore        |    1 +
 utils/Makefile.am       |   20 --------------------
 6 files changed, 4 insertions(+), 30 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jan Engelhardt</dc:creator>
    <dc:date>2012-05-19T22:08:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42748">
    <title>[Resend PATCH 1/2] netfilter: remove include/linux/netfilter_ipv4/ipt_addrtype.h</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42748</link>
    <description>&lt;pre&gt;From: Cong Wang &amp;lt;xiyou.wangcong&amp;lt; at &amp;gt;gmail.com&amp;gt;

It was scheduled to be removed.

Acked-by: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
Signed-off-by: Cong Wang &amp;lt;xiyou.wangcong&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 Documentation/feature-removal-schedule.txt  |    8 --------
 include/linux/netfilter_ipv4/Kbuild         |    1 -
 include/linux/netfilter_ipv4/ipt_addrtype.h |   27 ---------------------------
 3 files changed, 0 insertions(+), 36 deletions(-)
 delete mode 100644 include/linux/netfilter_ipv4/ipt_addrtype.h

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index e4b5775..366d158 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -414,14 +414,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; Files:net/netfilter/xt_connlimit.c
 
 ----------------------------
 
-What:ipt_addrtype match include file
-When:2012
-Why:superseded by xt_addrtype
-Who:Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
-Files:include/linux/netfilter_ipv4/ipt_addrtype.h
-
-----------------------------
-
 What:i2c_driver.attach_adapter
 i2c_driver.detach_adapter
 When:September 2011
diff --git a/include/linux/netfilter_ipv4/Kbuild b/include/linux/netfilter_ipv4/Kbuild
index c61b8fb..8ba0c5b 100644
--- a/include/linux/netfilter_ipv4/Kbuild
+++ b/include/linux/netfilter_ipv4/Kbuild
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -5,7 +5,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; header-y += ipt_LOG.h
 header-y += ipt_REJECT.h
 header-y += ipt_TTL.h
 header-y += ipt_ULOG.h
-header-y += ipt_addrtype.h
 header-y += ipt_ah.h
 header-y += ipt_ecn.h
 header-y += ipt_ttl.h
diff --git a/include/linux/netfilter_ipv4/ipt_addrtype.h b/include/linux/netfilter_ipv4/ipt_addrtype.h
deleted file mode 100644
index 0da4223..0000000
--- a/include/linux/netfilter_ipv4/ipt_addrtype.h
+++ /dev/null
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,27 +0,0 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
-#ifndef _IPT_ADDRTYPE_H
-#define _IPT_ADDRTYPE_H
-
-#include &amp;lt;linux/types.h&amp;gt;
-
-enum {
-IPT_ADDRTYPE_INVERT_SOURCE= 0x0001,
-IPT_ADDRTYPE_INVERT_DEST= 0x0002,
-IPT_ADDRTYPE_LIMIT_IFACE_IN= 0x0004,
-IPT_ADDRTYPE_LIMIT_IFACE_OUT= 0x0008,
-};
-
-struct ipt_addrtype_info_v1 {
-__u16source;/* source-type mask */
-__u16dest;/* dest-type mask */
-__u32flags;
-};
-
-/* revision 0 */
-struct ipt_addrtype_info {
-__u16source;/* source-type mask */
-__u16dest;/* dest-type mask */
-__u32invert_source;
-__u32invert_dest;
-};
-
-#endif
&lt;/pre&gt;</description>
    <dc:creator>Cong Wang</dc:creator>
    <dc:date>2012-05-19T14:39:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42747">
    <title>Sending packet bypassing iptables rules</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42747</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In my userspace app, i receive packets from NF_QUEUE. I manage a
userspace queue to do some processing over the packets. So i have to
set nfq_set_verdict(NF_DROP,.....). Now after the processing i need to
send the packets to the destinations. But this time i need to send
them such way so that they won't be caught in iptable rules.

What i have done for now is, i've set the dscp field of the IP packet
. And added a rule $iptables -t mangle -A PREROUTING -m dscp --dscp 10
-j ACCEPT before the rule which queues the packets. Then send the
packet over raw socket.

May be because of my intensive traffic (Traffic is real time media
data, so delays are fatal), the performance of my system is horrible.
So i'm thinking how i can achieve a more efficient processing. One
thing comes to my mind is the process i'm following for forwarding
packet is not very efficient. So i'm thinking about how can i improve
this.

Thanks in advance.

- --
- -aft

-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v0.1
Comment: http://openpgpjs.org

wsBcBAEBAgAQBQJPtjhtCRCJVJ6A/SK8awAALMcH/jZdX3CUBl1Z9icSdBEL
94ZSkh7QMO90xw3XRSv6L2e9QsVDrW2WLVIyqsiYoNdgUiwGgko4Q1o0Q49S
S0xtYlF4kyXPDNVDZ+Hurdx2Clnyk7J7BhXTPQ/DikMmKjFSSDuM+8wmuE/B
sBeM1Df+66eZVqJDKwkuKOubgfHCq3fx/iRFld+vwkDpDqqEZVr+mJwbrbea
qWCyohJQUHAXPQvm/yIgay4A4ISqd9IR7lSw41l/uap5ywSm6o5T7h9JLPOe
QeWK4oKmNbRgRVXynhmOR7SuiT0RXMQxTeLqCZUw67aLWSspoiDbNFY95c44
gSh3iuZG/wn4iYG0U9n539A=
=42Ja
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Arif Hossain</dc:creator>
    <dc:date>2012-05-18T11:54:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42746">
    <title>[PATCH][conntrack-tools] conntrack: flush stdout for each expectation event, too</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42746</link>
    <description>&lt;pre&gt;else, piping "conntrack -E expect" output will be buffered/delayed,
which is not what users expect. Normal conntrack events are already
flushed.

Signed-off-by: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
---
 src/conntrack.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/conntrack.c b/src/conntrack.c
index b065211..0920bc5 100644
--- a/src/conntrack.c
+++ b/src/conntrack.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1380,6 +1380,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int event_exp_cb(enum nf_conntrack_msg_type type,
 
 nfexp_snprintf(buf,sizeof(buf), exp, type, op_type, op_flags);
 printf("%s\n", buf);
+fflush(stdout);
 counter++;
 
 return NFCT_CB_CONTINUE;
&lt;/pre&gt;</description>
    <dc:creator>Florian Westphal</dc:creator>
    <dc:date>2012-05-18T11:36:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42745">
    <title>[PATCH][libnetfilter_conntrack] snprintf: print conntrack helper name, too</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42745</link>
    <description>&lt;pre&gt;Signed-off-by: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
---
 src/conntrack/snprintf_default.c |   11 +++++++++++
 src/conntrack/snprintf_xml.c     |   16 ++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/src/conntrack/snprintf_default.c b/src/conntrack/snprintf_default.c
index 206b9c0..45d192d 100644
--- a/src/conntrack/snprintf_default.c
+++ b/src/conntrack/snprintf_default.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -282,6 +282,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; __snprintf_timestamp_delta(char *buf, unsigned int len,
 (unsigned long long)delta_time));
 }
 
+static int
+__snprintf_helper_name(char *buf, unsigned int len, const struct nf_conntrack *ct)
+{
+return (snprintf(buf, len, "helper=%s ", ct-&amp;gt;helper_name));
+}
+
 int __snprintf_conntrack_default(char *buf, 
  unsigned int len,
  const struct nf_conntrack *ct,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -415,6 +421,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int __snprintf_conntrack_default(char *buf,
 BUFFER_SIZE(ret, size, len, offset);
 }
 
+if (test_bit(ATTR_HELPER_NAME, ct-&amp;gt;head.set)) {
+ret = __snprintf_helper_name(buf+offset, len, ct);
+BUFFER_SIZE(ret, size, len, offset);
+}
+
 /* Delete the last blank space */
 size--;
 
diff --git a/src/conntrack/snprintf_xml.c b/src/conntrack/snprintf_xml.c
index 756d118..ad53075 100644
--- a/src/conntrack/snprintf_xml.c
+++ b/src/conntrack/snprintf_xml.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -239,6 +239,18 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; __snprintf_deltatime(char *buf, unsigned int len, const struct nf_conntrack *ct)
 return size;
 }
 
+static int
+__snprintf_helper_name(char *buf, unsigned int len, const struct nf_conntrack *ct)
+{
+int ret;
+unsigned int size = 0, offset = 0;
+
+ret = snprintf(buf+offset, len, "&amp;lt;helper&amp;gt;%s&amp;lt;/helper&amp;gt;", ct-&amp;gt;helper_name);
+BUFFER_SIZE(ret, size, len, offset);
+
+return size;
+}
+
 int
 __snprintf_localtime_xml(char *buf, unsigned int len, const struct tm *tm)
 {
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -522,6 +534,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int __snprintf_conntrack_xml(char *buf,
 BUFFER_SIZE(ret, size, len, offset);
 }
 
+if (test_bit(ATTR_HELPER_NAME, ct-&amp;gt;head.set)) {
+ret = __snprintf_helper_name(buf+offset, len, ct);
+BUFFER_SIZE(ret, size, len, offset);
+}
 err_out:
 ret = snprintf(buf+offset, len, "&amp;lt;/flow&amp;gt;");
 BUFFER_SIZE(ret, size, len, offset);
&lt;/pre&gt;</description>
    <dc:creator>Florian Westphal</dc:creator>
    <dc:date>2012-05-18T11:35:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42744">
    <title>RTP stats explaination</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42744</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
We are getting very poor quality of voice during testing of a new
filtering application of us.

The application receives packets from kernel using netfilter_queue
library. Then insert the packets into a new user managed queue and
does some transformations on it, like concatenation of udp payload.

The network is healthy. Its inside our lab. And it does not drop
packets or anything .

In our app we do not forward packet immediately. After enough packet
received to increase rtp packetization time (ptime) the we forward the
message over raw socket and set dscp to be 10 so that this time
packets can escape iptable rules.

From client side the RTP stream analysis shows nearly every stream as
problematic. summery for some streams are given below :

Stream 1:

Max delta = 1758.72 ms at packet no. 40506
Max jitter = 231.07 ms. Mean jitter = 9.27 ms.
Max skew = -2066.18 ms.
Total RTP packets = 468   (expected 468)   Lost RTP packets = 0
(0.00%)   Sequence errors = 0
Duration 23.45 s (-22628 ms clock drift, corresponding to 281 Hz (-96.49%)

Stream 2:

Max delta = 1750.96 ms at packet no. 45453
Max jitter = 230.90 ms. Mean jitter = 7.50 ms.
Max skew = -2076.96 ms.
Total RTP packets = 468   (expected 468)   Lost RTP packets = 0
(0.00%)   Sequence errors = 0
Duration 23.46 s (-22715 ms clock drift, corresponding to 253 Hz (-96.84%)

Stream 3:

Max delta = 71.47 ms at packet no. 25009
Max jitter = 6.05 ms. Mean jitter = 2.33 ms.
Max skew = -29.09 ms.
Total RTP packets = 258   (expected 258)   Lost RTP packets = 0
(0.00%)   Sequence errors = 0
Duration 10.28 s (-10181 ms clock drift, corresponding to 76 Hz (-99.05%)

Any idea where should we look for the problem?


- --
- -aft
-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v0.1
Comment: http://openpgpjs.org

wsBcBAEBAgAQBQJPtiJ7CRCJVJ6A/SK8awAAHJgH/jRURuZWygqJTX7zafjK
807MvWxODhtw2p4ZLg+sCNJ0OpZlV5GftPKwH9XB4GfUKhmTPfCZ3n8vF6PU
nWKMdBDM3D/K+DktpiGuAK90A5lwniFptN8DGt/ltqdAaSAlGbz1E6LGGdlw
1w/6lPeO3J9HKpkNQA2nfn3q/s5ZHQiYoGvgFofkm85LBSYgyn4b7YDY7qnp
wtsGkSR1h66+q37Hb+1iZyWrHj26YJ+sNRBe8GzKdEccwrKMX1gJFNl5BBfl
frGsZ3Y02cSYFg5L1vVstl8F/yTz8JXTGk6yKbtA0N+TRhI7gIJ/VItm1SJt
JcF94ylPjIWiw9Iacv8ec88=
=jiIm
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Arif Hossain</dc:creator>
    <dc:date>2012-05-18T10:21:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42743">
    <title>NAT66</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42743</link>
    <description>&lt;pre&gt;Hi T.Moes,
  I am trying to use source code for NAT66 for network address 
translation in ipv6.
  Can you please tell me it will work or not, if we patch three files in 
kernel.
  Module compilation done successfully, but how to configure tart by 
using ip6tables.
  Can you please guide me about this...
Thanks,
Venkatb.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Venkateswarlu Bandi</dc:creator>
    <dc:date>2012-05-18T09:52:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42741">
    <title>Questions about ebtables QUEUE/NFQUEUE target implementation</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42741</link>
    <description>&lt;pre&gt;hello, everyone,

We are carrying out a project related with ebtables/arptables. We plan
to add logic in user space to deal with arp packets. But I found out
in ebtables homepage that the QUEUE/NFQUEUE target has not been
supported yet, while it is supported already in iptables. So does
community has any plan to support QUEUE/NFQUEUE target in ebtables? If
not, maybe we can contribute to do so.

As for arptables, I am not sure if it is supported already. I wrote
small programs using libipq as well as libnetfilter_queue, but both do
not work anyway. It does work together with iptables.

Thanks
Jerry Ma
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>JieYue Ma</dc:creator>
    <dc:date>2012-05-18T06:13:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42739">
    <title>[PATCH] iptables: xt_recent: Add optional mask option for xt_recent</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42739</link>
    <description>&lt;pre&gt;Use case for this feature:
1)In some occasions if you need to allow,block,match specific subnet.
2)I can use recent as a trigger when netfilter rule matches, with mask 0.0.0.0

Tested for backward compatibility:
)old (userspace) iptables, new kernel
)old kernel, new iptables
)new kernel, new iptables

Signed-off-by: Denys Fedoryshchenko &amp;lt;denys&amp;lt; at &amp;gt;visp.net.lb&amp;gt;
---
 extensions/libxt_recent.c           |  152 ++++++++++++++++++++++++++++++----
 include/linux/netfilter/xt_recent.h |   11 +++-
 2 files changed, 144 insertions(+), 19 deletions(-)

diff --git a/extensions/libxt_recent.c b/extensions/libxt_recent.c
index c7dce4e..930da29 100644
--- a/extensions/libxt_recent.c
+++ b/extensions/libxt_recent.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -16,6 +16,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum {
 O_NAME,
 O_RSOURCE,
 O_RDEST,
+O_MASK,
 F_SET    = 1 &amp;lt;&amp;lt; O_SET,
 F_RCHECK = 1 &amp;lt;&amp;lt; O_RCHECK,
 F_UPDATE = 1 &amp;lt;&amp;lt; O_UPDATE,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -25,7 +26,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum {
 };
 
 #define s struct xt_recent_mtinfo
-static const struct xt_option_entry recent_opts[] = {
+static const struct xt_option_entry recent_opts_v0[] = {
 {.name = "set", .id = O_SET, .type = XTTYPE_NONE,
  .excl = F_ANY_OP, .flags = XTOPT_INVERT},
 {.name = "rcheck", .id = O_RCHECK, .type = XTTYPE_NONE,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -50,6 +51,33 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static const struct xt_option_entry recent_opts[] = {
 };
 #undef s
 
+#define s struct xt_recent_mtinfo_v1
+static const struct xt_option_entry recent_opts_v1[] = {
+{.name = "set", .id = O_SET, .type = XTTYPE_NONE,
+ .excl = F_ANY_OP, .flags = XTOPT_INVERT},
+{.name = "rcheck", .id = O_RCHECK, .type = XTTYPE_NONE,
+ .excl = F_ANY_OP, .flags = XTOPT_INVERT},
+{.name = "update", .id = O_UPDATE, .type = XTTYPE_NONE,
+ .excl = F_ANY_OP, .flags = XTOPT_INVERT},
+{.name = "remove", .id = O_REMOVE, .type = XTTYPE_NONE,
+ .excl = F_ANY_OP, .flags = XTOPT_INVERT},
+{.name = "seconds", .id = O_SECONDS, .type = XTTYPE_UINT32,
+ .flags = XTOPT_PUT, XTOPT_POINTER(s, seconds)},
+{.name = "hitcount", .id = O_HITCOUNT, .type = XTTYPE_UINT32,
+ .flags = XTOPT_PUT, XTOPT_POINTER(s, hit_count)},
+{.name = "rttl", .id = O_RTTL, .type = XTTYPE_NONE,
+ .excl = F_SET | F_REMOVE},
+{.name = "name", .id = O_NAME, .type = XTTYPE_STRING,
+ .flags = XTOPT_PUT, XTOPT_POINTER(s, name)},
+{.name = "rsource", .id = O_RSOURCE, .type = XTTYPE_NONE},
+{.name = "rdest", .id = O_RDEST, .type = XTTYPE_NONE},
+{.name = "mask", .id = O_MASK, .type = XTTYPE_HOST,
+ .flags = XTOPT_PUT, XTOPT_POINTER(s, mask)},
+XTOPT_TABLEEND,
+};
+#undef s
+
+
 static void recent_help(void)
 {
 printf(
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -74,24 +102,27 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void recent_help(void)
 "    --name name                 Name of the recent list to be used.  DEFAULT used if none given.\n"
 "    --rsource                   Match/Save the source address of each packet in the recent list table (default).\n"
 "    --rdest                     Match/Save the destination address of each packet in the recent list table.\n"
+"    --mask netmask              Netmask that will be applied to this recent list.\n"
 "xt_recent by: Stephen Frost &amp;lt;sfrost&amp;lt; at &amp;gt;snowman.net&amp;gt;.  http://snowman.net/projects/ipt_recent/\n");
 }
 
-static void recent_init(struct xt_entry_match *match)
+static void recent_init(struct xt_entry_match *match,unsigned int family)
 {
-struct xt_recent_mtinfo *info = (void *)(match)-&amp;gt;data;
+struct xt_recent_mtinfo    *info_v0 = (void *)(match)-&amp;gt;data;
+struct xt_recent_mtinfo_v1 *info_v1 = (void *)(match)-&amp;gt;data;
 
-strncpy(info-&amp;gt;name,"DEFAULT", XT_RECENT_NAME_LEN);
+strncpy(info_v0-&amp;gt;name,"DEFAULT", XT_RECENT_NAME_LEN);
 /* even though XT_RECENT_NAME_LEN is currently defined as 200,
  * better be safe, than sorry */
-info-&amp;gt;name[XT_RECENT_NAME_LEN-1] = '\0';
-info-&amp;gt;side = XT_RECENT_SOURCE;
+info_v0-&amp;gt;name[XT_RECENT_NAME_LEN-1] = '\0';
+info_v0-&amp;gt;side = XT_RECENT_SOURCE;
+if (family == NFPROTO_IPV6)
+    memset(&amp;amp;info_v1-&amp;gt;mask,0xFF,sizeof(info_v1-&amp;gt;mask));
 }
 
 static void recent_parse(struct xt_option_call *cb)
 {
 struct xt_recent_mtinfo *info = cb-&amp;gt;data;
-
 xtables_option_parse(cb);
 switch (cb-&amp;gt;entry-&amp;gt;id) {
 case O_SET:
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -140,9 +171,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void recent_check(struct xt_fcheck_call *cb)
 }
 
 static void recent_print(const void *ip, const struct xt_entry_match *match,
-                         int numeric)
+                         unsigned int family)
 {
-const struct xt_recent_mtinfo *info = (const void *)match-&amp;gt;data;
+const struct xt_recent_mtinfo_v1 *info = (const void *)match-&amp;gt;data;
 
 if (info-&amp;gt;invert)
 printf(" !");
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -167,11 +198,17 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void recent_print(const void *ip, const struct xt_entry_match *match,
 printf(" side: source");
 if (info-&amp;gt;side == XT_RECENT_DEST)
 printf(" side: dest");
+if (family == NFPROTO_IPV4)
+    printf(" mask: %s",
+xtables_ipaddr_to_numeric(&amp;amp;info-&amp;gt;mask.in));
+if (family == NFPROTO_IPV6)
+    printf(" mask: %s",
+xtables_ip6addr_to_numeric(&amp;amp;info-&amp;gt;mask.in6));
 }
 
-static void recent_save(const void *ip, const struct xt_entry_match *match)
+static void recent_save(const void *ip, const struct xt_entry_match *match,unsigned int family)
 {
-const struct xt_recent_mtinfo *info = (const void *)match-&amp;gt;data;
+const struct xt_recent_mtinfo_v1 *info = (const void *)match-&amp;gt;data;
 
 if (info-&amp;gt;invert)
 printf(" !");
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -191,28 +228,107 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void recent_save(const void *ip, const struct xt_entry_match *match)
 if (info-&amp;gt;check_set &amp;amp; XT_RECENT_TTL)
 printf(" --rttl");
 if(info-&amp;gt;name) printf(" --name %s",info-&amp;gt;name);
+if (family == NFPROTO_IPV4)
+    printf(" --mask %s",
+xtables_ipaddr_to_numeric(&amp;amp;info-&amp;gt;mask.in));
+if (family == NFPROTO_IPV6)
+    printf(" --mask %s",
+xtables_ip6addr_to_numeric(&amp;amp;info-&amp;gt;mask.in6));
+
 if (info-&amp;gt;side == XT_RECENT_SOURCE)
 printf(" --rsource");
 if (info-&amp;gt;side == XT_RECENT_DEST)
 printf(" --rdest");
 }
 
-static struct xtables_match recent_mt_reg = {
-.name          = "recent",
+static void recent_init_v0(struct xt_entry_match *match) {
+recent_init(match,NFPROTO_UNSPEC);
+}
+
+static void recent_init_v1(struct xt_entry_match *match) {
+recent_init(match,NFPROTO_IPV6);
+}
+
+static void recent_save_v0(const void *ip, const struct xt_entry_match *match)
+{
+recent_save(ip,match,NFPROTO_UNSPEC);
+}
+
+static void recent_save_v4(const void *ip, const struct xt_entry_match *match)
+{
+recent_save(ip,match,NFPROTO_IPV4);
+}
+
+static void recent_save_v6(const void *ip, const struct xt_entry_match *match)
+{
+recent_save(ip,match,NFPROTO_IPV6);
+}
+
+static void recent_print_v0(const void *ip, const struct xt_entry_match *match,
+                         int numeric)
+{
+recent_print(ip,match,NFPROTO_UNSPEC);
+}
+
+static void recent_print_v4(const void *ip, const struct xt_entry_match *match,
+                         int numeric)
+{
+recent_print(ip,match,NFPROTO_IPV4);
+}
+
+static void recent_print_v6(const void *ip, const struct xt_entry_match *match,
+                         int numeric)
+{
+recent_print(ip,match,NFPROTO_IPV6);
+}
+
+static struct xtables_match recent_mt_reg[] = {
+    {.name          = "recent",
 .version       = XTABLES_VERSION,
+.revision      = 0,
 .family        = NFPROTO_UNSPEC,
 .size          = XT_ALIGN(sizeof(struct xt_recent_mtinfo)),
 .userspacesize = XT_ALIGN(sizeof(struct xt_recent_mtinfo)),
 .help          = recent_help,
-.init          = recent_init,
+.init          = recent_init_v0,
+.x6_parse      = recent_parse,
+.x6_fcheck     = recent_check,
+.print         = recent_print_v0,
+.save          = recent_save_v0,
+.x6_options    = recent_opts_v0,
+    },
+    {.name          = "recent",
+.version       = XTABLES_VERSION,
+.revision      = 1,
+.family        = NFPROTO_IPV4,
+.size          = XT_ALIGN(sizeof(struct xt_recent_mtinfo_v1)),
+.userspacesize = XT_ALIGN(sizeof(struct xt_recent_mtinfo_v1)),
+.help          = recent_help,
+.init          = recent_init_v1,
+.x6_parse      = recent_parse,
+.x6_fcheck     = recent_check,
+.print         = recent_print_v4,
+.save          = recent_save_v4,
+.x6_options    = recent_opts_v1,
+    },
+    {.name          = "recent",
+.version       = XTABLES_VERSION,
+.revision      = 1,
+.family        = NFPROTO_IPV6,
+.size          = XT_ALIGN(sizeof(struct xt_recent_mtinfo_v1)),
+.userspacesize = XT_ALIGN(sizeof(struct xt_recent_mtinfo_v1)),
+.help          = recent_help,
+.init          = recent_init_v1,
 .x6_parse      = recent_parse,
 .x6_fcheck     = recent_check,
-.print         = recent_print,
-.save          = recent_save,
-.x6_options    = recent_opts,
+.print         = recent_print_v6,
+.save          = recent_save_v6,
+.x6_options    = recent_opts_v1,
+    }
 };
 
 void _init(void)
 {
-xtables_register_match(&amp;amp;recent_mt_reg);
+xtables_register_matches(recent_mt_reg,
+ ARRAY_SIZE(recent_mt_reg));
 }
diff --git a/include/linux/netfilter/xt_recent.h b/include/linux/netfilter/xt_recent.h
index 83318e0..b8d58c6 100644
--- a/include/linux/netfilter/xt_recent.h
+++ b/include/linux/netfilter/xt_recent.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -22,7 +22,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum {
 
 #define XT_RECENT_VALID_FLAGS (XT_RECENT_CHECK|XT_RECENT_SET|XT_RECENT_UPDATE|\
        XT_RECENT_REMOVE|XT_RECENT_TTL|XT_RECENT_REAP)
-
 struct xt_recent_mtinfo {
 __u32 seconds;
 __u32 hit_count;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -32,4 +31,14 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct xt_recent_mtinfo {
 __u8 side;
 };
 
+struct xt_recent_mtinfo_v1 {
+__u32 seconds;
+__u32 hit_count;
+__u8 check_set;
+__u8 invert;
+char name[XT_RECENT_NAME_LEN];
+__u8 side;
+union nf_inet_addr mask;
+};
+
 #endif /* _LINUX_NETFILTER_XT_RECENT_H */
&lt;/pre&gt;</description>
    <dc:creator>Denys Fedoryshchenko</dc:creator>
    <dc:date>2012-05-17T20:08:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42736">
    <title>[PATCH 1/2] extensions: libxt_rateest: output all options in save hook</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42736</link>
    <description>&lt;pre&gt;ipt-restore fails to parse the ipt-save output:
zmatches -m rateest --rateest RE1 --rateest-pps --rateest-lt 5
(should be "--rateest-pps 5 --rateest-lt").  Also, the "delta" option
was never shown in -save output, but twice in some cases when using
"iptables -L".

Also, the "b/pps1" option must be shown when "delta" option is used with
relative mode.

Signed-off-by: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
---
 extensions/libxt_rateest.c |   55 +++++++++++++++++++++++++++----------------
 1 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/extensions/libxt_rateest.c b/extensions/libxt_rateest.c
index 86bbb06..185a813 100644
--- a/extensions/libxt_rateest.c
+++ b/extensions/libxt_rateest.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -348,8 +348,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; rateest_print(const void *ip, const struct xt_entry_match *match, int numeric)
 if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_DELTA)
 rateest_print_rate(info-&amp;gt;bps1, numeric);
 if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_ABS) {
-rateest_print_mode(info, "");
 rateest_print_rate(info-&amp;gt;bps2, numeric);
+rateest_print_mode(info, "");
 }
 }
 if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_PPS) {
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -366,8 +366,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; rateest_print(const void *ip, const struct xt_entry_match *match, int numeric)
 rateest_print_mode(info, "");
 
 printf(" %s", info-&amp;gt;name2);
-if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_DELTA)
-printf(" delta");
 
 if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_BPS) {
 printf(" bps");
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -382,33 +380,48 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; rateest_print(const void *ip, const struct xt_entry_match *match, int numeric)
 }
 }
 
+static void __rateest_save_rate(const struct xt_rateest_match_info *info,
+                                const char *name, uint32_t r1, uint32_t r2,
+                                int numeric)
+{
+if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_DELTA) {
+printf(" --rateest-%s1", name);
+rateest_print_rate(r1, numeric);
+rateest_print_mode(info, "--rateest-");
+printf(" --rateest-%s2", name);
+} else {
+rateest_print_mode(info, "--rateest-");
+printf(" --rateest-%s", name);
+}
+
+if (info-&amp;gt;flags &amp;amp; (XT_RATEEST_MATCH_ABS|XT_RATEEST_MATCH_DELTA))
+rateest_print_rate(r2, numeric);
+}
+
+static void rateest_save_rates(const struct xt_rateest_match_info *info)
+{
+if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_BPS)
+__rateest_save_rate(info, "bps", info-&amp;gt;bps1, info-&amp;gt;bps2, 0);
+if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_PPS)
+__rateest_save_rate(info, "pps", info-&amp;gt;pps1, info-&amp;gt;pps2, 1);
+}
+
+
 static void
 rateest_save(const void *ip, const struct xt_entry_match *match)
 {
 const struct xt_rateest_match_info *info = (const void *)match-&amp;gt;data;
 
+if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_DELTA)
+printf(" --rateest-delta");
+
 if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_REL) {
 printf(" --rateest1 %s", info-&amp;gt;name1);
-if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_BPS)
-printf(" --rateest-bps");
-if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_PPS)
-printf(" --rateest-pps");
-rateest_print_mode(info, " --rateest-");
+rateest_save_rates(info);
 printf(" --rateest2 %s", info-&amp;gt;name2);
-} else {
+} else { /* XT_RATEEST_MATCH_ABS */
 printf(" --rateest %s", info-&amp;gt;name1);
-if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_BPS) {
-printf(" --rateest-bps1");
-rateest_print_rate(info-&amp;gt;bps1, 0);
-printf(" --rateest-bps2");
-rateest_print_rate(info-&amp;gt;bps2, 0);
-rateest_print_mode(info, "--rateest-");
-}
-if (info-&amp;gt;flags &amp;amp; XT_RATEEST_MATCH_PPS) {
-printf(" --rateest-pps");
-rateest_print_mode(info, "--rateest-");
-printf(" %u", info-&amp;gt;pps2);
-}
+rateest_save_rates(info);
 }
 }
 
&lt;/pre&gt;</description>
    <dc:creator>Florian Westphal</dc:creator>
    <dc:date>2012-05-17T11:03:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42733">
    <title>Re[2]:  [PATCH] netfilter: xt_HMARK: fix endian bugs and warnings</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42733</link>
    <description>&lt;pre&gt;

Indeed,  but it saves some cpu cycles 


Ok, to make it endian safe a shift is required.
Like this:

        hp.b32 = (uports-&amp;gt;b32 &amp;amp; info-&amp;gt;port_mask.b32) | info-&amp;gt;port_set.b32;
        src = ntohs(hp.b16.src);
        dst = ntohs(hp.b16.dst);

        if (dst &amp;gt; src)
                uports-&amp;gt;v32 = (dst &amp;lt;&amp;lt; 16) | src;
        else
                uports-&amp;gt;v32 = (src &amp;lt;&amp;lt; 16) | dst;


I'll re-spin the patch



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Hans Schillstrom</dc:creator>
    <dc:date>2012-05-17T08:07:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42716">
    <title>[PATCH] netfilter: xt_HMARK: fix endian bugs and warnings</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42716</link>
    <description>&lt;pre&gt;A mix of u32 and __be32 causes endian warning.
The hash value produced is now the same for big and little endian machines.
i.e. a mix of Big and Little endian in a cluster is now possible.

Reported-by: Dan Carpenter &amp;lt;dan.carpenter&amp;lt; at &amp;gt;oracle.com&amp;gt;
Signed-off-by: Hans Schillstrom &amp;lt;hans.schillstrom&amp;lt; at &amp;gt;ericsson.com&amp;gt;
---
 include/linux/netfilter/xt_HMARK.h |    5 ++-
 net/netfilter/xt_HMARK.c           |   68 ++++++++++++++++++++---------------
 2 files changed, 42 insertions(+), 31 deletions(-)

diff --git a/include/linux/netfilter/xt_HMARK.h b/include/linux/netfilter/xt_HMARK.h
index abb1650..8b6307a 100644
--- a/include/linux/netfilter/xt_HMARK.h
+++ b/include/linux/netfilter/xt_HMARK.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -24,10 +24,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum {
 
 union hmark_ports {
 struct {
-__u16src;
-__u16dst;
+__be16src;
+__be16dst;
 } p16;
 __u32v32;
+__be32b32;
 };
 
 struct xt_hmark_info {
diff --git a/net/netfilter/xt_HMARK.c b/net/netfilter/xt_HMARK.c
index 32fbd73..7bb7b5e 100644
--- a/net/netfilter/xt_HMARK.c
+++ b/net/netfilter/xt_HMARK.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -32,13 +32,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; MODULE_ALIAS("ipt_HMARK");
 MODULE_ALIAS("ip6t_HMARK");
 
 struct hmark_tuple {
-u32src;
-u32dst;
+__be32src;
+__be32dst;
 union hmark_portsuports;
 uint8_tproto;
 };
 
-static inline u32 hmark_addr6_mask(const __u32 *addr32, const __u32 *mask)
+static inline __be32 hmark_addr6_mask(const __be32 *addr32, const __be32 *mask)
 {
 return (addr32[0] &amp;amp; mask[0]) ^
        (addr32[1] &amp;amp; mask[1]) ^
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -46,8 +46,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline u32 hmark_addr6_mask(const __u32 *addr32, const __u32 *mask)
        (addr32[3] &amp;amp; mask[3]);
 }
 
-static inline u32
-hmark_addr_mask(int l3num, const __u32 *addr32, const __u32 *mask)
+static inline __be32
+hmark_addr_mask(int l3num, const __be32 *addr32, const __be32 *mask)
 {
 switch (l3num) {
 case AF_INET:
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -58,6 +58,25 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_addr_mask(int l3num, const __u32 *addr32, const __u32 *mask)
 return 0;
 }
 
+static inline void hmark_port_order(union hmark_ports *uports,
+    const struct xt_hmark_info *info)
+{
+union hmark_ports hp;
+
+hp.b32 = (uports-&amp;gt;b32 &amp;amp; info-&amp;gt;port_mask.b32) | info-&amp;gt;port_set.b32;
+hp.v32 = ntohl(hp.b32);
+/* Make it endian safe into jhash() */
+#if defined(__LITTLE_ENDIAN)
+if ((__force u16) uports-&amp;gt;p16.dst &amp;gt;
+    (__force u16) uports-&amp;gt;p16.src)
+#else
+if ((__force u16) uports-&amp;gt;p16.src &amp;gt;
+    (__force u16) uports-&amp;gt;p16.dst)
+#endif
+swap(hp.p16.src, hp.p16.dst);
+uports-&amp;gt;v32 = hp.v32;
+}
+
 static int
 hmark_ct_set_htuple(const struct sk_buff *skb, struct hmark_tuple *t,
     const struct xt_hmark_info *info)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -74,10 +93,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_ct_set_htuple(const struct sk_buff *skb, struct hmark_tuple *t,
 otuple = &amp;amp;ct-&amp;gt;tuplehash[IP_CT_DIR_ORIGINAL].tuple;
 rtuple = &amp;amp;ct-&amp;gt;tuplehash[IP_CT_DIR_REPLY].tuple;
 
-t-&amp;gt;src = hmark_addr_mask(otuple-&amp;gt;src.l3num, otuple-&amp;gt;src.u3.all,
- info-&amp;gt;src_mask.all);
-t-&amp;gt;dst = hmark_addr_mask(otuple-&amp;gt;src.l3num, rtuple-&amp;gt;src.u3.all,
- info-&amp;gt;dst_mask.all);
+t-&amp;gt;src = hmark_addr_mask(otuple-&amp;gt;src.l3num, otuple-&amp;gt;src.u3.ip6,
+ info-&amp;gt;src_mask.ip6);
+t-&amp;gt;dst = hmark_addr_mask(otuple-&amp;gt;src.l3num, rtuple-&amp;gt;src.u3.ip6,
+ info-&amp;gt;dst_mask.ip6);
 
 if (info-&amp;gt;flags &amp;amp; XT_HMARK_FLAG(XT_HMARK_METHOD_L3))
 return 0;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -86,10 +105,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_ct_set_htuple(const struct sk_buff *skb, struct hmark_tuple *t,
 if (t-&amp;gt;proto != IPPROTO_ICMP) {
 t-&amp;gt;uports.p16.src = otuple-&amp;gt;src.u.all;
 t-&amp;gt;uports.p16.dst = rtuple-&amp;gt;src.u.all;
-t-&amp;gt;uports.v32 = (t-&amp;gt;uports.v32 &amp;amp; info-&amp;gt;port_mask.v32) |
-info-&amp;gt;port_set.v32;
-if (t-&amp;gt;uports.p16.dst &amp;lt; t-&amp;gt;uports.p16.src)
-swap(t-&amp;gt;uports.p16.dst, t-&amp;gt;uports.p16.src);
+hmark_port_order(&amp;amp;t-&amp;gt;uports, info);
 }
 
 return 0;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -102,11 +118,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline u32
 hmark_hash(struct hmark_tuple *t, const struct xt_hmark_info *info)
 {
 u32 hash;
+u32 src = ntohl(t-&amp;gt;src);
+u32 dst = ntohl(t-&amp;gt;dst);
 
-if (t-&amp;gt;dst &amp;lt; t-&amp;gt;src)
-swap(t-&amp;gt;src, t-&amp;gt;dst);
+if (dst &amp;lt; src)
+swap(src, dst);
 
-hash = jhash_3words(t-&amp;gt;src, t-&amp;gt;dst, t-&amp;gt;uports.v32, info-&amp;gt;hashrnd);
+hash = jhash_3words(src, dst, t-&amp;gt;uports.v32, info-&amp;gt;hashrnd);
 hash = hash ^ (t-&amp;gt;proto &amp;amp; info-&amp;gt;proto_mask);
 
 return (((u64)hash * info-&amp;gt;hmodulus) &amp;gt;&amp;gt; 32) + info-&amp;gt;hoffset;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -125,12 +143,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_set_tuple_ports(const struct sk_buff *skb, unsigned int nhoff,
 nhoff += protoff;
 if (skb_copy_bits(skb, nhoff, &amp;amp;t-&amp;gt;uports, sizeof(t-&amp;gt;uports)) &amp;lt; 0)
 return;
-
-t-&amp;gt;uports.v32 = (t-&amp;gt;uports.v32 &amp;amp; info-&amp;gt;port_mask.v32) |
-info-&amp;gt;port_set.v32;
-
-if (t-&amp;gt;uports.p16.dst &amp;lt; t-&amp;gt;uports.p16.src)
-swap(t-&amp;gt;uports.p16.dst, t-&amp;gt;uports.p16.src);
+hmark_port_order(&amp;amp;t-&amp;gt;uports, info);
 }
 
 #if IS_ENABLED(CONFIG_IP6_NF_IPTABLES)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -178,8 +191,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_pkt_set_htuple_ipv6(const struct sk_buff *skb, struct hmark_tuple *t,
 return -1;
 }
 noicmp:
-t-&amp;gt;src = hmark_addr6_mask(ip6-&amp;gt;saddr.s6_addr32, info-&amp;gt;src_mask.all);
-t-&amp;gt;dst = hmark_addr6_mask(ip6-&amp;gt;daddr.s6_addr32, info-&amp;gt;dst_mask.all);
+t-&amp;gt;src = hmark_addr6_mask(ip6-&amp;gt;saddr.s6_addr32, info-&amp;gt;src_mask.ip6);
+t-&amp;gt;dst = hmark_addr6_mask(ip6-&amp;gt;daddr.s6_addr32, info-&amp;gt;dst_mask.ip6);
 
 if (info-&amp;gt;flags &amp;amp; XT_HMARK_FLAG(XT_HMARK_METHOD_L3))
 return 0;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -255,11 +268,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; hmark_pkt_set_htuple_ipv4(const struct sk_buff *skb, struct hmark_tuple *t,
 }
 }
 
-t-&amp;gt;src = (__force u32) ip-&amp;gt;saddr;
-t-&amp;gt;dst = (__force u32) ip-&amp;gt;daddr;
-
-t-&amp;gt;src &amp;amp;= info-&amp;gt;src_mask.ip;
-t-&amp;gt;dst &amp;amp;= info-&amp;gt;dst_mask.ip;
+t-&amp;gt;src = ip-&amp;gt;saddr &amp;amp; info-&amp;gt;src_mask.ip;
+t-&amp;gt;dst = ip-&amp;gt;daddr &amp;amp; info-&amp;gt;dst_mask.ip;
 
 if (info-&amp;gt;flags &amp;amp; XT_HMARK_FLAG(XT_HMARK_METHOD_L3))
 return 0;
&lt;/pre&gt;</description>
    <dc:creator>Hans Schillstrom</dc:creator>
    <dc:date>2012-05-16T15:00:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42715">
    <title>WAIT YOUR URGENT REPLY</title>
    <link>http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/42715</link>
    <description>&lt;pre&gt;
Am really sorry i wrote so late about my inquiry i actually traveled to china to meet with some suppliers and i just came back into town few days ago. I was able to meet with some companies and also got to see what they have for me but i was surprised because the prices are much.


We saw a similar product on Alibaba Shopping/Business page so please confirm to us if you/your company can make provision of the exact product as shown on Alibaba Shopping/Business page which you can view by clicking the link below and login with you email address together with your password to download the attachment page to view the product. 

Bellow is the link.



http://dolbyltd.ucoz.com/plasltd.html


We will await your response with details, date of delivery and send quotation for large qty urgently prize and quantity that can be made available.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>dominick</dc:creator>
    <dc:date>2012-05-15T21:05:58</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.netfilter.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.netfilter.devel</link>
  </textinput>
</rdf:RDF>

