* [PATCH] Reduce number of pointer dereferences in IPv6 netfilter LOG module function dump_packet()
From: Jesper Juhl @ 2010-11-14 21:47 UTC (permalink / raw)
To: Netfilter Core Team
Cc: Jan Rekorajski, David S. Miller, netfilter-devel, netfilter,
netdev, linux-kernel
By adding two pointer variables to
net/ipv6/netfilter/ip6t_LOG.c::dump_packet() we can save 19 bytes of .text
and many pointer dereferences.
before:
text data bss dec hex filename
6258 600 3088 9946 26da net/ipv6/netfilter/ip6t_LOG.o
after:
text data bss dec hex filename
6239 600 3088 9927 26c7 net/ipv6/netfilter/ip6t_LOG.o
Please Cc me on replies.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
ip6t_LOG.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/netfilter/ip6t_LOG.c b/net/ipv6/netfilter/ip6t_LOG.c
index 09c8889..51d10a5 100644
--- a/net/ipv6/netfilter/ip6t_LOG.c
+++ b/net/ipv6/netfilter/ip6t_LOG.c
@@ -46,6 +46,8 @@ static void dump_packet(struct sbuff *m,
unsigned int ptr;
unsigned int hdrlen = 0;
unsigned int logflags;
+ struct sock *sk;
+ struct socket *sk_socket;
if (info->type == NF_LOG_TYPE_LOG)
logflags = info->u.log.logflags;
@@ -358,13 +360,15 @@ static void dump_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & IP6T_LOG_UID) && recurse && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
+ sk = skb->sk;
+ sk_socket = sk->sk_socket;
+ if ((logflags & IP6T_LOG_UID) && recurse && sk) {
+ read_lock_bh(&sk->sk_callback_lock);
+ if (sk_socket && sk_socket->file)
sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
+ sk_socket->file->f_cred->fsuid,
+ sk_socket->file->f_cred->fsgid);
+ read_unlock_bh(&sk->sk_callback_lock);
}
/* Max length: 16 "MARK=0xFFFFFFFF " */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] Reduce number of pointer dereferences in IPv4 netfilter LOG module function dump_packet()
From: Jesper Juhl @ 2010-11-14 21:35 UTC (permalink / raw)
To: Netfilter Core Team
Cc: netdev, linux-kernel, netfilter, netfilter-devel, David S. Miller,
Rusty Russell
By adding two pointer variables to
net/ipv4/netfilter/ipt_LOG.c::dump_packet() we can save 16 bytes of .text
and 9 pointer dereferences.
before this patch we did 20 pointer dereferences and had this object file
size:
text data bss dec hex filename
6233 600 3080 9913 26b9 net/ipv4/netfilter/ipt_LOG.o
after this patch we do just 11 pointer dereferences and have this object
file size:
text data bss dec hex filename
6217 600 3080 9897 26a9 net/ipv4/netfilter/ipt_LOG.o
Please Cc me on replies.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
ipt_LOG.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_LOG.c b/net/ipv4/netfilter/ipt_LOG.c
index 72ffc8f..02a92de 100644
--- a/net/ipv4/netfilter/ipt_LOG.c
+++ b/net/ipv4/netfilter/ipt_LOG.c
@@ -39,6 +39,8 @@ static void dump_packet(struct sbuff *m,
struct iphdr _iph;
const struct iphdr *ih;
unsigned int logflags;
+ struct sock *sk;
+ struct socket *sk_socket;
if (info->type == NF_LOG_TYPE_LOG)
logflags = info->u.log.logflags;
@@ -335,13 +337,15 @@ static void dump_packet(struct sbuff *m,
}
/* Max length: 15 "UID=4294967295 " */
- if ((logflags & IPT_LOG_UID) && !iphoff && skb->sk) {
- read_lock_bh(&skb->sk->sk_callback_lock);
- if (skb->sk->sk_socket && skb->sk->sk_socket->file)
+ sk = skb->sk;
+ sk_socket = sk->sk_socket;
+ if ((logflags & IPT_LOG_UID) && !iphoff && sk) {
+ read_lock_bh(&sk->sk_callback_lock);
+ if (sk_socket && sk_socket->file)
sb_add(m, "UID=%u GID=%u ",
- skb->sk->sk_socket->file->f_cred->fsuid,
- skb->sk->sk_socket->file->f_cred->fsgid);
- read_unlock_bh(&skb->sk->sk_callback_lock);
+ sk_socket->file->f_cred->fsuid,
+ sk_socket->file->f_cred->fsgid);
+ read_unlock_bh(&sk->sk_callback_lock);
}
/* Max length: 16 "MARK=0xFFFFFFFF " */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Eric Dumazet @ 2010-11-14 19:57 UTC (permalink / raw)
To: Kevin Cernekee
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <AANLkTik4PLga8mX73c8iONPeOtpDiuDhfu3xiPmF07jC@mail.gmail.com>
Le dimanche 14 novembre 2010 à 10:33 -0800, Kevin Cernekee a écrit :
> On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > I would like to get an exact SIP exchange to make sure their is not
> > another way to handle this without adding a "Cisco" string somewhere...
> >
> > Please provide a pcap or tcpdump -A
>
> Existing nf_nat_sip: phone sends unauthenticated REGISTER requests
> over and over again, because it is not seeing the replies sent back to
> port 50070:
>
> 10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
> E`...[..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
Hmm, partial tcpdump... you should use" tcpdump -s 1000 -A"
We miss the
Via: SIP/2.0/UDP 192.168.2.28:5060;branch=xxxxxxxx
Maybe a fix would be to use this "5060" port, instead of hardcoding it
like you did ?
>
> Patched nf_nat_sip: router sends the replies back to port 5060, so the
> phone is now able to register itself and make calls:
>
> 10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723
> E`...G..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
> 10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
> E....+..4..$C...............SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.2.28:5060
>
> 10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550
> E..B.,..4...C...............SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP 192.168.2.2
>
> 10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900
> E`...H..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
> 10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
> E....-..4.."C...............SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.2.28:5060
>
> 10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579
> E.._....4...C............K..SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.2.28:5060;bra
>
>
> BTW, I thought of two possible issues with the original patch:
>
> 1) Might need to call skb_make_writable() prior to modifying the
> packet. Presumably the second invocation inside
> nf_nat_mangle_udp_packet() will have no effect.
>
> (Is there a cleaner way to mangle just the port number? Most of the
> utility functions only help with modifying the data area.)
>
> 2) I should probably be checking to make sure request == 0 before
> mangling the packet. The current behavior is harmless if the SIP
> proxy is on port 5060, but that might not always be the case.
>
> I can roll these, along with any other suggestions, into v2.
^ permalink raw reply
* Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Kevin Cernekee @ 2010-11-14 18:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <1289725175.2743.65.camel@edumazet-laptop>
On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> I would like to get an exact SIP exchange to make sure their is not
> another way to handle this without adding a "Cisco" string somewhere...
>
> Please provide a pcap or tcpdump -A
Existing nf_nat_sip: phone sends unauthenticated REGISTER requests
over and over again, because it is not seeing the replies sent back to
port 50070:
10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...[..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:05:53.587370 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..fC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:05:53.587807 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..%C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:05:57.496541 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...\..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:05:57.526716 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..dC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:05:57.527162 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..#C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:06:01.486821 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...]..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:06:01.515611 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..bC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:06:01.516024 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..!C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
... continues forever ...
Patched nf_nat_sip: router sends the replies back to port 5060, so the
phone is now able to register itself and make calls:
10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723
E`...G..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
E....+..4..$C...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550
E..B.,..4...C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900
E`...H..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
E....-..4.."C...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579
E.._....4...C............K..SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.28:5060;bra
BTW, I thought of two possible issues with the original patch:
1) Might need to call skb_make_writable() prior to modifying the
packet. Presumably the second invocation inside
nf_nat_mangle_udp_packet() will have no effect.
(Is there a cleaner way to mangle just the port number? Most of the
utility functions only help with modifying the data area.)
2) I should probably be checking to make sure request == 0 before
mangling the packet. The current behavior is harmless if the SIP
proxy is on port 5060, but that might not always be the case.
I can roll these, along with any other suggestions, into v2.
^ permalink raw reply
* Testing bridge setup with packet generator and qemu
From: Kfir Lavi @ 2010-11-14 17:30 UTC (permalink / raw)
To: netfilter, bridge
Hi,
I would like to test a simple bridge setup.
br0 have eth0 and eth1
I want to create a fake traffic and see it crossing the bridge.
Lets say i'm generating arp packet with nemesis:
nemesis arp -v -d eth0 -S $SRC -D $DST -h $SRC_MAC -m $DST_MAC
nemesis arp -v -r -d eth0 -S $DST -D $SRC -h $DST_MAC -m $SRC_MAC
This shows on eth0 tcpdump but not on eth1 tcpdump
Why is that?
I have a gentoo rootfs.
qemu nics are define like this:
-net nic,model=rtl8139,vlan=0 -net user,vlan=0 \
-net nic,model=rtl8139,vlan=1
Regards,
Kfir
^ permalink raw reply
* Re: NAT-PMP connections not tracked with nf_conntrack
From: Mr Dash Four @ 2010-11-14 10:41 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
In-Reply-To: <4CB9E918.2040707@googlemail.com>
>
>> ip6tables-save, or its respective v4 part.
>>
> iptables-save | grep NOTRACK returns nothing, so I assume that I am
> not using this.
Any ideas? The connection is definitely not tracked and could be seen
with netstat from local to the remote point on the VPN.
^ permalink raw reply
* Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Eric Dumazet @ 2010-11-14 8:59 UTC (permalink / raw)
To: Kevin Cernekee
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <28d666269c390965f1a4edca42f93c12@localhost>
Le dimanche 14 novembre 2010 à 00:32 -0800, Kevin Cernekee a écrit :
> Most SIP devices use a source port of 5060/udp on SIP requests, so the
> response automatically comes back to port 5060:
>
> phone_ip:5060 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:5060 100 Trying
>
> The newer Cisco IP phones, however, use a randomly chosen high source
> port for the SIP request but expect the response on port 5060:
>
> phone_ip:49173 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:5060 100 Trying
>
> Standard Linux NAT, with or without nf_nat_sip, will send the reply back
> to port 49173, not 5060:
>
> phone_ip:49173 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:49173 100 Trying
>
> But the phone is not listening on 49173, so it will never see the reply.
>
> This issue was seen on a Cisco CP-7965G, firmware 8-5(3). It appears
> to be a well-known problem on 7941 and newer:
>
> http://www.voip-info.org/wiki/view/Standalone+Cisco+7941%252F7961+without+a+local+PBX
>
> Search for "Connecting to the outside world"
>
> I contacted Cisco support and they were not amenable to changing the
> behavior. It appears to be RFC3261-compliant, as the "Sent-by port"
> field in the request specifies 5060:
>
There is a difference between being RFC compliant, and being usable.
Most SIP sotfwares I know will break with such a stupid CISCO behavior.
> 18.2.2 Sending Responses
>
> The server transport uses the value of the top Via header field in
> order to determine where to send a response. It MUST follow the
> following process:
>
> ...
>
> o Otherwise (for unreliable unicast transports), if the top Via
> has a "received" parameter, the response MUST be sent to the
> address in the "received" parameter, using the port indicated
> in the "sent-by" value, or using port 5060 if none is specified
> explicitly. If this fails, for example, elicits an ICMP "port
> unreachable" response, the procedures of Section 5 of [4]
> SHOULD be used to determine where to send the response.
>
> This patch modifies nf_*_sip to work around this quirk, by rewriting
> the response port to 5060 when the following conditions are met:
>
> - User-Agent starts with "Cisco"
>
> - Incoming TTL was exactly 64 (meaning that our system is the phone's
> local router, not an intermediate router)
>
This seems a hack to me, sorry. How many different vendors will switch
to "Cisco" broken way, and we have to patch over and over ?
I would like to get an exact SIP exchange to make sure their is not
another way to handle this without adding a "Cisco" string somewhere...
Please provide a pcap or tcpdump -A
Thanks
^ permalink raw reply
* [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Kevin Cernekee @ 2010-11-14 8:32 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris <>
Cc: netfilter-devel, netfilter, coreteam, linux-kernel, netdev
Most SIP devices use a source port of 5060/udp on SIP requests, so the
response automatically comes back to port 5060:
phone_ip:5060 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:5060 100 Trying
The newer Cisco IP phones, however, use a randomly chosen high source
port for the SIP request but expect the response on port 5060:
phone_ip:49173 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:5060 100 Trying
Standard Linux NAT, with or without nf_nat_sip, will send the reply back
to port 49173, not 5060:
phone_ip:49173 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:49173 100 Trying
But the phone is not listening on 49173, so it will never see the reply.
This issue was seen on a Cisco CP-7965G, firmware 8-5(3). It appears
to be a well-known problem on 7941 and newer:
http://www.voip-info.org/wiki/view/Standalone+Cisco+7941%252F7961+without+a+local+PBX
Search for "Connecting to the outside world"
I contacted Cisco support and they were not amenable to changing the
behavior. It appears to be RFC3261-compliant, as the "Sent-by port"
field in the request specifies 5060:
18.2.2 Sending Responses
The server transport uses the value of the top Via header field in
order to determine where to send a response. It MUST follow the
following process:
...
o Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter, using the port indicated
in the "sent-by" value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP "port
unreachable" response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.
This patch modifies nf_*_sip to work around this quirk, by rewriting
the response port to 5060 when the following conditions are met:
- User-Agent starts with "Cisco"
- Incoming TTL was exactly 64 (meaning that our system is the phone's
local router, not an intermediate router)
Tested on Linus' latest 2.6.37-rc tree.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
include/linux/netfilter/nf_conntrack_sip.h | 2 ++
net/ipv4/netfilter/nf_nat_sip.c | 12 ++++++++++++
net/netfilter/nf_conntrack_sip.c | 25 +++++++++++++++++++++++++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/linux/netfilter/nf_conntrack_sip.h b/include/linux/netfilter/nf_conntrack_sip.h
index 0ce91d5..a6ea620 100644
--- a/include/linux/netfilter/nf_conntrack_sip.h
+++ b/include/linux/netfilter/nf_conntrack_sip.h
@@ -8,6 +8,7 @@
struct nf_ct_sip_master {
unsigned int register_cseq;
unsigned int invite_cseq;
+ unsigned int cisco_port_mangle;
};
enum sip_expectation_classes {
@@ -90,6 +91,7 @@ enum sip_header_types {
SIP_HDR_EXPIRES,
SIP_HDR_CONTENT_LENGTH,
SIP_HDR_CALL_ID,
+ SIP_HDR_USER_AGENT,
};
enum sdp_header_types {
diff --git a/net/ipv4/netfilter/nf_nat_sip.c b/net/ipv4/netfilter/nf_nat_sip.c
index e40cf78..4b9a46d 100644
--- a/net/ipv4/netfilter/nf_nat_sip.c
+++ b/net/ipv4/netfilter/nf_nat_sip.c
@@ -121,6 +121,7 @@ static unsigned int ip_nat_sip(struct sk_buff *skb, unsigned int dataoff,
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
+ struct nf_conn_help *help = nfct_help(ct);
unsigned int coff, matchoff, matchlen;
enum sip_header_types hdr;
union nf_inet_addr addr;
@@ -225,6 +226,17 @@ next:
return NF_DROP;
}
+ /* Mangle destination port for Cisco phones, then fix up checksums */
+ if (help->help.ct_sip_info.cisco_port_mangle) {
+ struct udphdr *uh;
+
+ uh = (struct udphdr *)(skb->data + ip_hdrlen(skb));
+ uh->dest = htons(SIP_PORT);
+
+ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, 0, 0, NULL, 0))
+ return NF_DROP;
+ }
+
if (!map_sip_addr(skb, dataoff, dptr, datalen, SIP_HDR_FROM) ||
!map_sip_addr(skb, dataoff, dptr, datalen, SIP_HDR_TO))
return NF_DROP;
diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index bcf47eb..6042f66 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -18,6 +18,7 @@
#include <linux/udp.h>
#include <linux/tcp.h>
#include <linux/netfilter.h>
+#include <linux/ip.h>
#include <net/netfilter/nf_conntrack.h>
#include <net/netfilter/nf_conntrack_core.h>
@@ -338,6 +339,7 @@ static const struct sip_header ct_sip_hdrs[] = {
[SIP_HDR_EXPIRES] = SIP_HDR("Expires", NULL, NULL, digits_len),
[SIP_HDR_CONTENT_LENGTH] = SIP_HDR("Content-Length", "l", NULL, digits_len),
[SIP_HDR_CALL_ID] = SIP_HDR("Call-Id", "i", NULL, callid_len),
+ [SIP_HDR_USER_AGENT] = SIP_HDR("User-Agent", NULL, NULL, string_len),
};
static const char *sip_follow_continuation(const char *dptr, const char *limit)
@@ -1366,6 +1368,29 @@ static int process_sip_request(struct sk_buff *skb, unsigned int dataoff,
unsigned int matchoff, matchlen;
unsigned int cseq, i;
+ /* Many Cisco IP phones use a high source port for SIP requests, but
+ * listen for the response on port 5060. If we are the local
+ * router for one of these phones, flag the connection here so that
+ * responses will be redirected to the correct port.
+ */
+ do {
+ static const char cisco[] = "Cisco";
+ struct iphdr *iph = ip_hdr(skb);
+ struct nf_conn_help *help = nfct_help(ct);
+
+ if (iph->ttl != 63)
+ break;
+ if (ct_sip_get_header(ct, *dptr, 0, *datalen,
+ SIP_HDR_USER_AGENT, &matchoff, &matchlen) <= 0)
+ break;
+ if (matchlen < strlen(cisco))
+ break;
+ if (strnicmp(*dptr + matchoff, cisco, strlen(cisco)) != 0)
+ break;
+
+ help->help.ct_sip_info.cisco_port_mangle = 1;
+ } while (0);
+
for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) {
const struct sip_handler *handler;
--
1.7.0.4
^ permalink raw reply related
* Re: [SOLVED] Re: ClusterIP and MAC NAT
From: Grant Taylor @ 2010-11-12 22:28 UTC (permalink / raw)
To: Mail List - Netfilter
In-Reply-To: <1289234180.6644.33.camel@nerino>
On 11/08/10 10:36, Michele Codutti wrote:
> Hello everyone today I managed to nat a multicast address of a clustered
> ip. So I'm writing to the ML to keep track of the solution.
I'm glad that you got things working the way that you wanted them to.
Thank you for replying to the mailing list so that others can search the
archives in the future.
> The servers and the bridges all are Debian Lenny with only packaged
> software, the router is a Cisco 7200 VXR.
*nod*
> There are only 3 ebtables rules to do the trick:
> ebtables -t nat -A PREROUTING \
> --in-interface "$OUTERFACE" \
> --protocol arp \
> --arp-opcode Request \
> --arp-ip-dst "$ip" \
> --jump arpreply \
> --arpreply-mac "$UMAC_OUI:" \
> --arpreply-target DROP
> ebtables -t nat -A PREROUTING \
> --in-interface "$OUTERFACE" \
> --destination "$UMAC_OUI:$MAC_EUI" \
> --jump dnat
> --to-destination "$MMAC_OUI:$MAC_EUI" \
> --dnat-target ACCEPT
> ebtables -t nat -A POSTROUTING \
> --out-interface "$OUTERFACE" \
> --protocol arp \
> --arp-opcode Request \
> --arp-ip-src "$ip" \
> --jump snat \
> --snat-arp \
> --to-source "$UMAC_OUI:$MAC_EUI" \
> --snat-target ACCEPT
> Where:
> - $ip is the cluster ip shared by servers;
> - $OUTERFACE is the interface of the bridge connected
> on router ethernet segment;
> - $MMAC_OUI is the multicast OUI part of the MAC address;
> - $MMAC_OUI is the unicast OUI part of the MAC address;
> - $MAC_EUI is the final part of the MAC address.
Did you mean $UMAC_OUI for the unicast?
> Special thanks to Grant Taylor.
Id's say you are welcome, but I didn't do any thing other than point in
a direction and say yes it could be done.
Grant. . . .
^ permalink raw reply
* SFQ flow classifier, works for imq0, not for eth1
From: Ben Pfountz @ 2010-11-12 14:57 UTC (permalink / raw)
To: netfilter
Hey Everyone,
Any direction with this problem would be greatly appreciated. For some
reason when I add a SFQ flow classifier using tc filter, the sfq qdisc
stops forwarding packets. (strangely though, a few packets are
forwarded before things stop working)
I am working with an openwrt based router, trying to add SFQ flow
classifier support to openwrt's qos-scripts. I have simplified the TC
commands down to these to try to find the problem.
tc qdisc add dev eth1 root handle 1: htb default 7
tc class add dev eth1 parent 1: classid 1:7 htb rate 500mbit ceil
1000mbit prio 3
tc qdisc add dev eth1 parent 1:7 handle 10: sfq perturb 10
tc filter add dev eth1 protocol ip parent 10: handle 2 flow hash keys
src,dst divisor 1024
Without the last line, packets flow normally as shown by
# tc -s -d qdisc show dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 7 direct_packets_stat 0 ver 3.17
Sent 856 bytes 11 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 10: parent 1:7 limit 127p quantum 1514b flows 127/1024 perturb
10sec
Sent 856 bytes 11 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
With the last line, I see this
tc -s -d qdisc show dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 7 direct_packets_stat 0 ver 3.17
Sent 5019 bytes 53 pkt (dropped 40, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 10: parent 1:7 limit 127p quantum 1514b flows 127/1024 perturb
10sec
Sent 5019 bytes 53 pkt (dropped 40, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
I have tried every combination of hash keys and divisor I can think of,
but the problem remains.
The system is linux 2.6.32.25, iproute 2.6.35, and cls_flow is loaded.
Does anyone have any suggestions?
What is the TC command to view the SFQ internal queues as described here?
http://www.mail-archive.com/netdev@vger.kernel.org/msg60637.html
Thanks!
Ben
^ permalink raw reply
* pppd or netfilter error?
From: Gáspár Lajos @ 2010-11-12 11:46 UTC (permalink / raw)
To: netfilter list
Hi all!
The following error is related to the iptables subsystem?
Thanx
Swifty
fw01 kernel: Call Trace:
fw01 kernel: Code: b4 26 00 00 00 00 53 89 c2 9c 59 fa 8b 00 39 c2 74 24
85 c0 74 1a ff 4a 08 8b 18 8b 50 04 c7 00 00 00 00 00 c7 40 04 00 00 00
00 <89> 53 04 89 1a 51 9d 5b c3 66 90 31 c0 eb f6 8d b6 00 00 00 00
fw01 kernel: Process pppd (pid: 21943, ti=f6595000 task=f715ebe0
task.ti=f6595000)
fw01 kernel: EIP: [<c032dc65>] SS:ESP 0068:f6595e88
fw01 kernel: last sysfs file: /sys/module/ip_tables/initstate
fw01 kernel: CR2: 0000000000000004
fw01 kernel: Oops: 0002 [#2]
fw01 kernel: Stack:
fw01:/fw# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 3200+
stepping : 0
cpu MHz : 2204.965
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4409.93
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts
fw01:/fw# uname -a
Linux fw01 2.6.36 #1 Wed Oct 27 20:18:18 CEST 2010 i686 GNU/Linux
^ permalink raw reply
* Re: [PATCH] netfilter: NF_HOOK_COND has wrong conditional
From: Patrick McHardy @ 2010-11-12 7:32 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Eric Paris, netfilter-devel, netfilter, coreteam, linux-kernel
In-Reply-To: <alpine.LNX.2.01.1011112148100.30863@obet.zrqbmnf.qr>
On 11.11.2010 21:49, Jan Engelhardt wrote:
> On Thursday 2010-11-11 20:09, Eric Paris wrote:
>
>> The NF_HOOK_COND returns 0 when it shouldn't due to what I believe to be an
>> error in the code as the order of operations is not what was intended. C will
>> evalutate == before =. Which means ret is getting set to the bool result,
>> rather than the return value of the function call. The code says
>>
>> if (ret = function() == 1)
>> when it meant to say:
>> if ((ret = function()) == 1)
>
> Thanks for catching. Indeed (ret = f) == 1 is desired, as can be seen in
> patch 2249065f4b22b493bae2caf549b86f175f33188e.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] netfilter: NF_HOOK_COND has wrong conditional
From: Jan Engelhardt @ 2010-11-11 20:49 UTC (permalink / raw)
To: Eric Paris; +Cc: netfilter-devel, netfilter, coreteam, kaber, linux-kernel
In-Reply-To: <20101111190954.29005.61686.stgit@paris.rdu.redhat.com>
On Thursday 2010-11-11 20:09, Eric Paris wrote:
>The NF_HOOK_COND returns 0 when it shouldn't due to what I believe to be an
>error in the code as the order of operations is not what was intended. C will
>evalutate == before =. Which means ret is getting set to the bool result,
>rather than the return value of the function call. The code says
>
>if (ret = function() == 1)
>when it meant to say:
>if ((ret = function()) == 1)
Thanks for catching. Indeed (ret = f) == 1 is desired, as can be seen in
patch 2249065f4b22b493bae2caf549b86f175f33188e.
^ permalink raw reply
* [PATCH] netfilter: NF_HOOK_COND has wrong conditional
From: Eric Paris @ 2010-11-11 19:09 UTC (permalink / raw)
To: netfilter-devel, netfilter, coreteam; +Cc: kaber, linux-kernel
The NF_HOOK_COND returns 0 when it shouldn't due to what I believe to be an
error in the code as the order of operations is not what was intended. C will
evalutate == before =. Which means ret is getting set to the bool result,
rather than the return value of the function call. The code says
if (ret = function() == 1)
when it meant to say:
if ((ret = function()) == 1)
Normally the compiler would warn, but it doesn't notice it because its
a actually complex conditional and so the wrong code is wrapped in an explict
set of () [exactly what the compiler wants you to do if this was intentional].
Fixing this means that errors when netfilter denies a packet get propagated
back up the stack rather than lost.
Signed-off-by: Eric Paris <eparis@redhat.com>
---
include/linux/netfilter.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 89341c3..03317c8 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -215,7 +215,7 @@ NF_HOOK_COND(uint8_t pf, unsigned int hook, struct sk_buff *skb,
int ret;
if (!cond ||
- (ret = nf_hook_thresh(pf, hook, skb, in, out, okfn, INT_MIN) == 1))
+ ((ret = nf_hook_thresh(pf, hook, skb, in, out, okfn, INT_MIN)) == 1))
ret = okfn(skb);
return ret;
}
^ permalink raw reply related
* Re: limit bandwidth equally
From: Michele Petrazzo - Unipex @ 2010-11-11 18:42 UTC (permalink / raw)
To: J Webster; +Cc: netfilter
In-Reply-To: <4CDBDC82.6020006@googlemail.com>
J Webster ha scritto:
> I am using the following script for tc/htb.
> My server has 2 VPN services and a proxy server.
> The proxy server already limits using delay pools but I need to add a
> 1Mbps limit for every IP connecting to the VPN.
> The VPN is on tun1 and tun 0.
> Does the tc script go in the same folder as iptables.../etc/sysconfig?
>
No, it's not need.
This script are a separate "program".
> # The network interface we're planning on limiting bandwidth.
> IF=eth0 # Interface
> # Download limit (in mega bits)
> DNLD=1mbit # DOWNLOAD Limit
> # Upload limit (in mega bits)
> UPLD=1mbit # UPLOAD Limit
> $TC qdisc add dev $IF root handle 1: htb default 30
> $TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
> $TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
This is the first error that I found. With htb you cannot limit upload
and download speed on the same interface. Are you looking for ifb?
Michele
^ permalink raw reply
* Re: limit bandwidth equally
From: J Webster @ 2010-11-11 12:07 UTC (permalink / raw)
To: Michele Petrazzo - Unipex, netfilter
In-Reply-To: <4CD926C6.8070604@unipex.it>
I am using the following script for tc/htb.
My server has 2 VPN services and a proxy server.
The proxy server already limits using delay pools but I need to add a
1Mbps limit for every IP connecting to the VPN.
The VPN is on tun1 and tun 0.
Does the tc script go in the same folder as iptables.../etc/sysconfig?
This is my ip a:
[root sarg]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
qlen 100
link/ether 00:19:99:63:5a:a3 brd ff:ff:ff:ff:ff:ff
inet 88.xxx.xxx.xx8/22 brd 88.208.239.255 scope global eth0
inet 88.xxx.xxx.xx9/22 brd 88.208.239.255 scope global secondary eth0:0
inet6 fe80::219:99ff:fe63:5aa3/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
53: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 100
link/[65534]
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun1
54: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1460 qdisc
pfifo_fast qlen 100
link/[65534]
inet 172.16.0.1 peer 172.16.0.2/32 scope global tun0
[root sarg]#
tc script:
#!/bin/bash
#
# tc uses the following units when passed as a parameter.
# kbps: Kilobytes per second
# mbps: Megabytes per second
# kbit: Kilobits per second
# mbit: Megabits per second
# bps: Bytes per second
# Amounts of data can be specified in:
# kb or k: Kilobytes
# mb or m: Megabytes
# mbit: Megabits
# kbit: Kilobits
# To get the byte figure from bits, divide the number by 8 bit
#
#
# Name of the traffic control command.
TC=/sbin/tc
# The network interface we're planning on limiting bandwidth.
IF=eth0 # Interface
# Download limit (in mega bits)
DNLD=1mbit # DOWNLOAD Limit
# Upload limit (in mega bits)
UPLD=1mbit # UPLOAD Limit
# IP address of the machine we are controlling
IP=10.8.0.0/32 # Host IP
IP=172.16.0.0/32 # Host IP
# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"
start() {
# We'll use Hierarchical Token Bucket (HTB) to shape bandwidth.
# For detailed configuration options, please consult Linux man
# page.
$TC qdisc add dev $IF root handle 1: htb default 30
$TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
$U32 match ip dst $IP/32 flowid 1:1
$U32 match ip src $IP/32 flowid 1:2
# The first line creates the root qdisc, and the next two lines
# create two child qdisc that are to be used to shape download
# and upload bandwidth.
#
# The 4th and 5th line creates the filter to match the interface.
# The 'dst' IP address is used to limit download speed, and the
# 'src' IP address is used to limit upload speed.
}
stop() {
# Stop the bandwidth shaping.
$TC qdisc del dev $IF root
}
restart() {
# Self-explanatory.
stop
sleep 1
start
}
show() {
# Display status of traffic control status.
$TC -s qdisc ls dev $IF
}
case "$1" in
start)
echo -n "Starting bandwidth shaping: "
start
echo "done"
;;
stop)
echo -n "Stopping bandwidth shaping: "
stop
echo "done"
;;
restart)
echo -n "Restarting bandwidth shaping: "
restart
echo "done"
;;
show)
echo "Bandwidth shaping status for $IF:"
show
echo ""
;;
*)
pwd=$(pwd)
echo "Usage: tc.bash {start|stop|restart|show}"
;;
esac
exit 0
iptables:
iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner test -j MARK
--set-mark 1
^ permalink raw reply
* iptables matching on TCP OPTIONS
From: burek @ 2010-11-11 9:02 UTC (permalink / raw)
To: netfilter
Hi,
I've been trying Google for hours now, and had no luck with this :(
Is it possible to use TCP OPTIONS field (
http://en.wikipedia.org/wiki/Transmission_Control_Protocol ) to put a short
string (text) in the tcp option area of an TCP packet (as a new, custom,
option) and later match those packets with iptables using --tcp-option?
Are there any example out there that are explaining how to match a tcp
packet, based on the custom option's value (short text that i'd like to put
in it)?
Thanks to all who can help.
^ permalink raw reply
* Re: unable to source and destination nat at the same time on multi-homed server
From: Joelly Alexander @ 2010-11-10 22:33 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: netfilter
In-Reply-To: <4CD6CF5B.2030606@plouf.fr.eu.org>
On 07.11.2010 17:10, Pascal Hambourg wrote:does anyone know a way to
solve this
> You can mark the packets (-j MARK) or the connection (-j CONNMARK) in
> mangle/OUTPUT before DNAT, and match the packet mark (-m mark) or
> connection mark (-m connmark) in nat/POSTROUTING.
>
> Or you can use -m conntrack --ctorigdst to match the original
> destination address.
>
After playing around some time to see how to use and how it works - it
does exactly what i need
Thanks
^ permalink raw reply
* Re: How to transfer a IP packet based on ebtables and iptables?
From: Pascal Hambourg @ 2010-11-10 9:09 UTC (permalink / raw)
To: Sumin Xia; +Cc: netfilter
In-Reply-To: <B6443739-BE5C-44B0-916D-69C4764DBDF6@gmail.com>
Hello,
Sumin Xia a écrit :
>
> According to my understanding, if I implement ebtables on my Linux
> system, a frame should be passed through ebtables modules.
Ebtables sees only packets on interfaces that are part of a bridge.
> Then, if
> ebtables modules find the destination mac address of the frame is the
> local mac address, it will transfer the frame to layer-3, that is
> iptables, right?
Iptables is normally called from the IP layer, and the layer 3 is the IP
layer if the packet is an IP packet. But if the kernel was built with
the option CONFIG_BRIDGE_NETFILTER enabled (which is the most common
AFAICS) and /proc/sys/net/bridge/bridge-nf-call-iptables is set to 1
(the default), things are a bit more complicated : some iptables chains
are called from the bridge and interleaved with ebtables chains, and
won't be called from the IP layer. This is shown on the diagram in the
article about netfilter/iptables at Wikipedia. The purpose is to allow
to use iptables capabilities on purely bridged IP traffic.
> Now I want to do a test, which modifies the destination mac address of
> a frame before sending it. Therefore, the frame will be forwarded to
> another destination instead of the real destination, while its
> destination ip address is still the real destination ip address. In
> this case, when the frame arrive at pseudo destination machine, will
> it be transfered to lay-3 of the system?
Yes.
> If it is transfered to lay-3
> of the system, the system will find the destination ip address is not
> local ip address. What will happen next? Drop the packet? or send an
> arp request to find the real destination mac address and forward it?
It depends whether the machine acts as a host or a router. If it acts as
a host, it will discard the packet. If it acts as a router, it will try
to forward the packet to the next hop (which may not be the final
destination) according to its routing table. It will send an ARP request
only if it is a necessary step in order to reach the next hop.
^ permalink raw reply
* Re: Redirecting flows among one machine's interfaces
From: Pascal Hambourg @ 2010-11-10 8:47 UTC (permalink / raw)
To: Kostas Pelechrinis; +Cc: netfilter
In-Reply-To: <764497.89064.qm@web31604.mail.mud.yahoo.com>
Hello,
Kostas Pelechrinis a écrit :
>
> I have a machine with two interfaces (let's say if1 -- with ip address
> a.b.c.d -- and if2 -- with ip address x.y.z.w) both connected to the
> internet. One of the two interfaces is the default interface (e.g., if1).
> Whatever flow is initiated towards a destination in the Internet is
> going out if1. I want to use iptables in order to redirect some of the
> flows to if2. Is there a way to do this using iptables?
This is a FAQ. You will find useful information in the Linux Advanced
Routing and Traffic Control (LARTC) HOWTO.
> I have tried some rules (e.g., iptables -A FORWARD -d k.l.m.n -o if2
> -j ACCEPT // where k.l.m.n is the destination ip address of the flow I
> want to redirect) but with no luck. From what I could figure out the
> rule FORWARD is mainly for packets that go through the machine and not
> that much for packets originating from the machine.
Indeed. Besides, the rule justs matches packets going out through the
interface if2. It does not have any effect on the routing decision,
which took place before the FORWARD chain.
> another question is weather iptables changing the source ip address
> from a.b.c.d to x.y.z.w or not.
Iptables does not change the source address implicitly as a result of a
rerouting decision. You have to do it explicitly with rules using SNAT
or MASQUERADE.
^ permalink raw reply
* Re: Redirecting flows among one machine's interfaces
From: Kostas Pelechrinis @ 2010-11-10 0:51 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
In-Reply-To: <alpine.LNX.2.01.1011100033030.7017@obet.zrqbmnf.qr>
Thanks a lot. I am checking iproute2 now but can you give any pointers/hints.
Thanks a lot,
Kostas
--- On Tue, 11/9/10, Jan Engelhardt <jengelh@medozas.de> wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
> Subject: Re: Redirecting flows among one machine's interfaces
> To: "Kostas Pelechrinis" <kpele_ntua@yahoo.com>
> Cc: netfilter@vger.kernel.org
> Date: Tuesday, November 9, 2010, 6:33 PM
> On Tuesday 2010-11-09 23:59, Kostas
> Pelechrinis wrote:
>
> >Hi all,
> >
> >I am not very familiar with iptables, but what I am
> trying to achieve
> >is the following:
> >
> >I have a machine with two interfaces (let's say if1 --
> with ip address
> >a.b.c.d -- and if2 -- with ip address x.y.z.w) both
> connected to the
> >internet. One of the two interfaces is the default
> interface (e.g.,
> >if1). Whatever flow is initiated towards a
> destination in the Internet
> >is going out if1. I want to use iptables in order
> to redirect some of
> >the flows to if2. Is there a way to do this using
> iptables?
>
> Using -j MARK and iproute2 policy routing.
>
> >I have tried some rules (e.g., iptables -A FORWARD -d
> k.l.m.n -o if2 -j
> >ACCEPT // where k.l.m.n is the destination ip address
> of the flow I
> >want to redirect) but with no luck.
>
> Well guess why: it _tests_ whether the outgoing interface
> is (already)
> if2.
>
^ permalink raw reply
* Re: Redirecting flows among one machine's interfaces
From: Jan Engelhardt @ 2010-11-09 23:33 UTC (permalink / raw)
To: Kostas Pelechrinis; +Cc: netfilter
In-Reply-To: <764497.89064.qm@web31604.mail.mud.yahoo.com>
On Tuesday 2010-11-09 23:59, Kostas Pelechrinis wrote:
>Hi all,
>
>I am not very familiar with iptables, but what I am trying to achieve
>is the following:
>
>I have a machine with two interfaces (let's say if1 -- with ip address
>a.b.c.d -- and if2 -- with ip address x.y.z.w) both connected to the
>internet. One of the two interfaces is the default interface (e.g.,
>if1). Whatever flow is initiated towards a destination in the Internet
>is going out if1. I want to use iptables in order to redirect some of
>the flows to if2. Is there a way to do this using iptables?
Using -j MARK and iproute2 policy routing.
>I have tried some rules (e.g., iptables -A FORWARD -d k.l.m.n -o if2 -j
>ACCEPT // where k.l.m.n is the destination ip address of the flow I
>want to redirect) but with no luck.
Well guess why: it _tests_ whether the outgoing interface is (already)
if2.
^ permalink raw reply
* Redirecting flows among one machine's interfaces
From: Kostas Pelechrinis @ 2010-11-09 22:59 UTC (permalink / raw)
To: netfilter
Hi all,
I am not very familiar with iptables, but what I am trying to achieve is the following:
I have a machine with two interfaces (let's say if1 -- with ip address a.b.c.d -- and if2 -- with ip address x.y.z.w) both connected to the internet. One of the two interfaces is the default interface (e.g., if1). Whatever flow is initiated towards a destination in the Internet is going out if1. I want to use iptables in order to redirect some of the flows to if2. Is there a way to do this using iptables?
I have tried some rules (e.g., iptables -A FORWARD -d k.l.m.n -o if2 -j ACCEPT // where k.l.m.n is the destination ip address of the flow I want to redirect) but with no luck. From what I could figure out the rule FORWARD is mainly for packets that go through the machine and not that much for packets originating from the machine. Is there a way to perform what I want with iptables ? Given that this is possible, another question is weather iptables changing the source ip address from a.b.c.d to x.y.z.w or not.
Thanks a lot and hopefully someone can seed light on this.
Best,
Kostas
^ permalink raw reply
* Re: Verdict with ebtables?
From: Angel Inkov @ 2010-11-09 22:41 UTC (permalink / raw)
To: Kfir Lavi, netfilter
In-Reply-To: <AANLkTikpfZCpcTqWAo5ONO6dJvFfruEJXCbam4EbPVdT@mail.gmail.com>
maybe using nflog with drop target in the rule can help you
^ permalink raw reply
* Re: How to transfer a IP packet based on ebtables and iptables?
From: Angel Inkov @ 2010-11-09 22:30 UTC (permalink / raw)
To: Sumin Xia, netfilter
In-Reply-To: <B6443739-BE5C-44B0-916D-69C4764DBDF6@gmail.com>
it depends, for example if you have ip_forward enabled it will forward
the packet for you, using your default route for example in case dest
ip is not in the same subnet.
On 9 November 2010 20:56, Sumin Xia <xiasumin1984@gmail.com> wrote:
> Hi every one,
>
> According to my understanding, if I implement entables on my Linux system, a
> frame should be passed through ebtables modules. Then, if ebtables modules
> find the destination mac address of the frame is the local mac address, it
> will transfer the frame to layer-3, that is iptables, right?
>
> Now I want to do a test, which modifies the destination mac address of a
> frame before sending it. Therefore, the frame will be forwarded to another
> destination instead of the real destination, while its destination ip
> address is still the real destination ip address. In this case, when the
> frame arrive at pseudo destination machine, will it be transfered to lay-3
> of the system? If it is transfered to lqy-3 of the system, the system will
> find the destination ip address is not local ip address. What will happen
> next? Drop the packet? or send an arp request to find the real destination
> mac address and forward it?
>
> Thanks,
>
> Sumin
> --
> 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
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox