headers
Horms | 1 Oct 2006 04:42
Picon
Gravatar

Re: [patch 3/3] Replace reverse_route() with a call to ip_route_m e_harder()

On Sat, Sep 30, 2006 at 06:23:08PM +0200, Patrick McHardy wrote:
> Venkat Yekkirala wrote:
> >>Venkat, is it correct to place a security_skb_classify_flow
> >>call in ip_route_me_harder (which also handles currently
> >>unlabeled protocols)?
> > 
> > 
> > This isn't necessary since the xfrm_decode_session invocation
> > from within ip_route_me_harder does take care of classifying
> > the flow.
> 
> Thanks, I missed the call in xfrm_decode_session because I
> only looked in xfrm4_policy.c.
> 
> Simon, I fixed up the patch slightly and applied it, thanks.

Thanks, I really was a bit unsure about this patch.

--

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/
Permalink | Reply | 0 comments |
headers
Robert Scott | 1 Oct 2006 22:09

nfq_set_verdict_mark

i noticed that this function doesn't automatically convert the mark  
into the expected network byte order.  this is a minor detail, but  
the current behavior may confuse users. since nfq_get_nfmark  
automatically converts the mark into host order, i thought  
nfq_set_verdict_mark would also  do the reverse.

not really a big deal, and this will probably break most existing  
installations in the field, but perhaps a note in the docs to give  
new users a heads up.

cheers,
--robert
Permalink | Reply | 7 comments |
headers
Laurence J. Lane | 2 Oct 2006 03:37
Picon
Favicon

Re: [PATCH] iptables: ip6table version support and libip6t_multiport.fix

On 9/10/06, Laurence J. Lane <ljlane <at> debian.org> wrote:

> details: http://bugs.debian.org/329775
>
> The 329775-submitter <at> bugs.debian.org address reaches all
> interested Debian parties.
>
> Rémi Denis-Courmont has submitted a patch to that adds version support
> to ip6tables and updates libip6t_multiport to v1. (Rémi also posted to the
> list but something appears to have gone wrong.)
>
> It Works for Me.

I guess the list software ate the attachment.

diff -Nru iptables-1.3.5.orig/extensions/libip6t_multiport.c
iptables-1.3.5/extensions/libip6t_multiport.c
--- iptables-1.3.5.orig/extensions/libip6t_multiport.c	2005-02-19
21:19:17.000000000 +0200
+++ iptables-1.3.5/extensions/libip6t_multiport.c	2006-08-27
13:03:36.000000000 +0300
 <at>  <at>  -20,6 +20,23  <at>  <at> 
 " --dports ...\n"
 "				match destination port(s)\n"
 " --ports port[,port,port]\n"
+"				match both source and destination port(s)\n"
+" NOTE: this kernel does not support port ranges in multiport.\n",
+IPTABLES_VERSION);
+}
+
(Continue reading)

Permalink | Reply | 3 comments |
headers
Horms | 2 Oct 2006 03:57
Picon
Gravatar

Re: [patch 2/3] Honour source routing for LVS-NAT

On Fri, Sep 29, 2006 at 03:38:28PM +0200, Patrick McHardy wrote:
> Horms wrote:
> > For policy routing, packets originating from this machine itself may be
> > routed differently to packets passing through. We want this packet to be
> > routed as if it came from this machine itself. So re-compute the routing
> > information using ip_route_me_harder().
> 
> Thanks, I've applied the first two patches.

Thanks. To which tree did you apply them?

--

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/
Permalink | Reply | 0 comments |
headers
Yasuyuki KOZAKAI | 2 Oct 2006 06:46
Picon

Re: [PATCH] iptables: ip6table version support and libip6t_multiport.fix


Hello,

From: "Laurence J. Lane" <ljlane <at> debian.org>
Date: Sun, 1 Oct 2006 21:37:54 -0400

> On 9/10/06, Laurence J. Lane <ljlane <at> debian.org> wrote:
> 
> > details: http://bugs.debian.org/329775
> >
> > The 329775-submitter <at> bugs.debian.org address reaches all
> > interested Debian parties.
> >
> > Rémi Denis-Courmont has submitted a patch to that adds version support
> > to ip6tables and updates libip6t_multiport to v1. (Rémi also posted to the
> > list but something appears to have gone wrong.)
> >
> > It Works for Me.
> 
> I guess the list software ate the attachment.

Great! I'll read deeply that.

> +static void
> +parse_multi_ports_v1(const char *portstring,
> +		     struct xt_multiport_v1 *multiinfo,
> +		     const char *proto)
> +{
> +	char *buffer, *cp, *next, *range;
> +	unsigned int i;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pablo Neira Ayuso | 2 Oct 2006 15:10
Favicon

Re: [PATCH] libnfnetlink register callback

Hi Maik,

Sorry for the late reply, I've been overloaded with work.

Maik Hentsche wrote:
> Hi pablo, hello readers of the list!
> I found, that nfnl_callback_register() and nfnl_callback_unregister() in
> libnfnetlink do not behave as documented. Instead of returning -1 and
> setting errno, they return -EINVAL without setting errno at all. Find a
> patch attached, that changes this behaviour. The patch has been build
> and
> tested with the unofficial libnfnetlink-0.0.16-pablo-r1 only, but the
> previous version 0.0.16 also has this bug and therefore, it should also
> apply there.

I'll add this to my tree including the appropiate credits, I'm
periodically posting the patch to the list in the hope that it will be
applied to mainline.

--

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
Permalink | Reply | 0 comments |
headers
Pablo Neira Ayuso | 2 Oct 2006 15:47
Favicon

Re: [PATCH] libnfnetlink

Patrick McHardy wrote:
> Maik Hentsche wrote:
>> Hello Pablo, hello readers of the list,
>> I found another bug in libnfnetlink. The comment of nfnl_recv states, in
>> case of success 0 is returned. In fact at success the returnvalue of
>> recvfrom is returned, which is the number of received bytes
>> (libnfnetlink_recv_comment.patch). The second issue is a little more
>> serious. The comment states, in case of an error, errno is set when in
>> fact it is not. I appended a patch for two occurences, but I since I
>> don't know, in which case addrlen might be != sizeof(peer) and what
>> peer.nl_pid means (and therefore why it is a problem, if it's not 0)
>> two error cases without appropriate errno value still exist.
> 
> addrlen != sizeof(peer) should never happen. I can't think of anything
> better than EINVAL. nl_pid != 0 means the message originated in
> userspace and some other program is trying to feed us messages.
> We could handle this by just calling recvmsg again. But this is mainly
> because I can't think of a proper errno code for this either :)

what do you think about the following solution?

> 	if (len < sizeof(struct nlmsgerr)
> 	    || len < sizeof(struct nlmsghdr))

errno = EBADMSG;

> [...]
> 	if (addrlen != sizeof(peer))

errno = EINVAL;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rémi Denis-Courmont | 2 Oct 2006 16:47

Re: [PATCH] iptables: ip6table version support and libip6t_multiport.fix

Le lundi 2 octobre 2006 07:46, Yasuyuki KOZAKAI a écrit :
(...)
> Please use IP6T_MULTI_PORTS so that we can compile with linux 2.4.

There you go (also resynched with latest SVN), but won't it fail with 
xt_multiport_v1 anyway (there is no ip6t_multiport_v1 in *any* kernel 
version to date, AFAIK)?

Index: include/ip6tables.h
===================================================================
--- include/ip6tables.h	(révision 6678)
+++ include/ip6tables.h	(copie de travail)
 <at>  <at>  -33,6 +33,9  <at>  <at> 

 	ip6t_chainlabel name;

+	/* Revision of match (0 by default). */
+	u_int8_t revision;
+
 	const char *version;

 	/* Size of match data. */
Index: extensions/libip6t_multiport.c
===================================================================
--- extensions/libip6t_multiport.c	(révision 6678)
+++ extensions/libip6t_multiport.c	(copie de travail)
 <at>  <at>  -20,6 +20,23  <at>  <at> 
 " --dports ...\n"
 "				match destination port(s)\n"
 " --ports port[,port,port]\n"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pablo Neira Ayuso | 2 Oct 2006 16:55
Favicon

Re: nfq_set_verdict_mark

Robert Scott wrote:
> i noticed that this function doesn't automatically convert the mark into
> the expected network byte order.  this is a minor detail, but the
> current behavior may confuse users. since nfq_get_nfmark automatically
> converts the mark into host order, i thought nfq_set_verdict_mark would
> also  do the reverse.
> 
> not really a big deal, and this will probably break most existing
> installations in the field, but perhaps a note in the docs to give new
> users a heads up.

Yes, I agree what you, we have to document this minor issue, I think
that we can introduce more API that can solve this inconsistency.

--

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
Permalink | Reply | 6 comments |
headers
Patrick McHardy | 2 Oct 2006 17:46
Favicon

[NETFILTER 01/05]: Kconfig: fix xt_physdev dependencies

[NETFILTER]: Kconfig: fix xt_physdev dependencies

xt_physdev depends on bridge netfilter, which is a boolean, but can still
be built modular because of special handling in the bridge makefile. Add
a dependency on BRIDGE to prevent XT_MATCH_PHYSDEV=y, BRIDGE=m.

Signed-off-by: Patrick McHardy <kaber <at> trash.net>

---
commit 2f253e95a172eaec7de29e3f0951d3a20d3f904c
tree fa38b574cf9b05743058ef38a3fa38bf28a1a399
parent 6656e3c4c8e0c80f2d2bfece574876d269f64861
author Patrick McHardy <kaber <at> trash.net> Mon, 02 Oct 2006 17:39:35 +0200
committer Patrick McHardy <kaber <at> trash.net> Mon, 02 Oct 2006 17:39:35 +0200

 net/netfilter/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 0a28d2c..ce94732 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
 <at>  <at>  -365,7 +365,7  <at>  <at>  config NETFILTER_XT_MATCH_MULTIPORT

 config NETFILTER_XT_MATCH_PHYSDEV
 	tristate '"physdev" match support'
-	depends on NETFILTER_XTABLES && BRIDGE_NETFILTER
+	depends on NETFILTER_XTABLES && BRIDGE && BRIDGE_NETFILTER
 	help
 	  Physdev packet matching matches against the physical bridge ports
(Continue reading)

Permalink | Reply | 0 comments |

Gmane