(DRR) for this with more flexible limits.
I'll rediff against net-2.6.26 within the next days and send
a final version for review (anyone interested is welcome to
already review this version of course :).
commit 13d0cc64d0f7fed945c357cf4ca43330c8f95ad2
Author: Patrick McHardy [EMAIL PROTECTED]
Date
Damien Thébault wrote:
2008/1/2 Damien Thébault [EMAIL PROTECTED]:
On Dec 30, 2007 6:53 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
Thanks. They still show the double POST_ROUTING effects (the retransmitted
\0a), but I can't figure out why this would be happening. Please add TRACE
Damien Thébault wrote:
On Jan 11, 2008 1:24 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
No, this should work properly. I just tried to reproduce it,
but I only get a single POSTROUTING invocation. I tried with
real bridged traffic, traffic routed between two different
bridge devices
Patrick McHardy wrote:
Damien Thébault wrote:
On the router, I'm using this script :
ifconfig eth0 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
ifconfig br0 192.168.1.70 up
ifconfig br0:0 192.168.2.70 up
iptables -t nat -A POSTROUTING -d 192.168.2.0/24 -j MASQUERADE
iptables -t nat
Damien Thébault wrote:
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index c1757c7..362fe89 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -285,12 +285,17 @@ static int br_nf_pre_routing_finish_bridge(struct sk_buff
*skb)
Damien Thébault wrote:
On Dec 22, 2007 8:56 AM, Patrick McHardy [EMAIL PROTECTED] wrote:
Yes, the captures show the effects from the double POSTROUTING
invocation. Could you send me captures from the current net-2.6
tree?
Sure, here they are.
(I used David Miller's net-2.6.25
Damien Thébault wrote:
On Dec 20, 2007 12:25 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
Thanks. Could you also post a tcpdump and enable conntrack logging
by doing echo 255 /proc/sys/net/netfilter/nf_conntrack_log_invalid
and post the output of that, if any (you also need to load ipt_LOG
Damien Thébault wrote:
On Dec 19, 2007 8:03 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
Could you capture the conntrack events of the non-working
case with (run in parallel):
conntrack -E
conntrack -E expect
Sure, here it is :
That actually looks like it works properly.
New control
Damien Thébault wrote:
On Dec 20, 2007 12:07 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
Don't worry. I was just wondering because I asked for the output
of the *non-working* case :) Please post that and I'll look into it.
The fact is that this was the output of the non working case
Damien Thébault wrote:
Hello,
I sent the quoted mail to linux-net with my problem yesterday, but I
did a git bisect today and I got the following output :
2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8 is first bad commit
commit 2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8
Author: Patrick McHardy
Jan Engelhardt wrote:
On Oct 12 2007 15:48, Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing (mangle/nat
Al Boldi wrote:
Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should
Please send mails discussing netfilter to netfilter-devel.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
There are some minor
Sam Ravnborg wrote:
On Tue, Jul 24, 2007 at 08:36:33AM +0300, Al Boldi wrote:
Replaces NF_CONNTRACK_ENABLED with NF_CONNTRACK and selects it for
NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
This exposes IPv4/6 connection tracking options for easier Kconfig setup.
Signed-off-by: Al Boldi [EMAIL
Al Boldi wrote:
Patrick McHardy wrote:
But I vaguely recall having tried this myself and it broke somewhere,
maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
recall anymore. Al, if this also works without removal of
NF_CONNTRACK_ENABLED, please resend without that part
Al Boldi wrote:
Patrick McHardy wrote:
Al Boldi wrote:
Patrick McHardy wrote:
But I vaguely recall having tried this myself and it broke somewhere,
maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
recall anymore. Al, if this also works without removal of
NF_CONNTRACK_ENABLED
Frantisek Rysanek wrote:
I know that Netfilter can do seamless stateful filtering of traffic
returning back through NAT. If I set up two uplinks with a NAT
horizon split on each of them, it shouldn't be a problem to route
traffic to either interface by merely modifying the default route
Bill Davidsen wrote:
Still working on this problem, I have found what appears to be a bug.
The documentation seems to indicate that in a route definition if I have
src x.x.x.x it defines the outgoing IP address. I'm cautiously going
to say that doesn't seem to be the case.
I have these
Jerome Borsboom wrote:
This is a CC of a patch from my discussion on linux-net mailinglist
which may be also appropriate here.
It wasn't CCed so I've added linux-net since you've also posted
the patch there.
Below is a patch that I had to include on top of Herbert Xu's recent
nat-sip patch
Jerome Borsboom wrote:
Signed-off-by: Jerome Borsboom [EMAIL PROTECTED]
Applied, thanks Jerome.
-
To unsubscribe from this list: send the line unsubscribe linux-net in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jerome Borsboom wrote:
I am not the maintainer of the NAT-SIP module. In the future, you should
post similar requests to the linux-net mailinglist where it can be
picked up by more skilled people. I have cross-posted my reply there too.
Actually netfilter-devel is the correct list for these
Hirokazu Takahashi wrote:
TBF --- Simple Token Bucket Filter --- packet scheduler doesn't
work correctly with TSO on that it slows down to send out packets.
TSO packets will be discarded since the size can be larger than
the scheduler expects. But it won't cause serious problems
because the
David Miller wrote:
From: Patrick McHardy [EMAIL PROTECTED]
Date: Thu, 10 May 2007 14:56:39 +0200
I don't see why this is needed, the correct way to use TBF with TSO
is to specify a larger MTU value, in which case it won't drop TSO
packets.
Why should a user have to know anything
Stephen Hemminger wrote:
Minor update release for iproute2 is available.
It's missing this patch to use correct values for HZ. If you have
doubts, please say so, I'm not going to resend a fourth time. To
demonstrate the problem:
$ while true; do date; ip -s route get 172.16.195.200; sleep 1; done
On Tue, 22 Feb 2005, DuBuisson, Thomas wrote:
Summary of important items:
ip policy routing used.
Packet matching policy not getting encrypted
Kernel version 2.6.9
ipsec-tools version 0.4rc1
Using IPsec tunneling
I'm more than happy to try suggestions or provide misc details.
I can't reproduce it
25 matches
Mail list logo
