All of lore.kernel.org
 help / color / mirror / Atom feed
* Re IPv6 MARK support
@ 2007-02-28  8:04 Boutin Maël
  2007-02-28  9:55 ` Boutin Maël
  0 siblings, 1 reply; 11+ messages in thread
From: Boutin Maël @ 2007-02-28  8:04 UTC (permalink / raw)
  To: netfilter

No one have an idea ? Is RPDB (routing policy database) working in
Ipv6 ?? Seems to me that it should work, since NEPL (Nemo
implementation for linux) is using it...


On 2/27/07,  mael.boutin@laposte.net <mael.boutin@laposte.net> wrote:
>  Hi,
>
>   I have a problem with the MARK target support. I want to MARK locally generated IPv6 packets (UDP, TCP, ICMP ...). For this i use the following ip6tables command :
>
> ip6tables -t mangle -A OUTPUT -p udp -j MARK 0x1
> ip6tables -t mangle -A OUTPUT -p tcp -j MARK 0x2
>
> All works fine, the rule is added in the OUPUT chain of mangle table. Now i want to retrieve this mark and route packets according to their mark :
>
> ip -6 route add 2001:688:dd00::5 via 2001:688:bb00::5 dev eth0 table TEST1
> ip -6 route add 2001:688:dd00::5 via 2001:688:cc00::5 dev eth1 table TEST2
>
> => Routes seems to be taken into account and added to the tables (it doesn't appear but when you type ip -6 route show table 0 | grep TEST1 you can see the rules in TEST1)
>
> ip -6 rule add fwmark 0x1 table TEST1
> ip -6 rule add fwmark 0x2 table TEST2
>
> => Rules are added and can be viewed with ip -6 rule show
>
> The test bed is set up correctly (all interfaces can be pinged).
>
> My problem is that when i generate a UDP flow (via nc) the packets are not marked (i suppose) by ip6tables and therefore iproute does not lookup table TEST1 as it should.
>
> My kernel is  2.6.19.3 with ip6tables compiled as module with all available targets, IPv6 multiple routing tables is built in as well as "use netfilter MARK value as routing key"
>
> Best regards,
>
> Maël
>
> Envoyez vos cartes de voeux depuis  www.laposte.net
> Elles seront ensuite distribuées par le facteur : pratique et malin !
>
>
>



-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-02-28  8:04 Re IPv6 MARK support Boutin Maël
@ 2007-02-28  9:55 ` Boutin Maël
  2007-02-28 10:53   ` Yasuyuki KOZAKAI
  0 siblings, 1 reply; 11+ messages in thread
From: Boutin Maël @ 2007-02-28  9:55 UTC (permalink / raw)
  To: netfilter

After some tests, it appears that it is the OUTPUT chain that does not
work. Indeed with the PREROUTING chain the mark is taken into account
by iproute and the packet is routed as indicated in the corresponding
tables.

Is it a bug or something i missed ?

On 2/28/07, Boutin Maël <mael.boutin@laposte.net> wrote:
> No one have an idea ? Is RPDB (routing policy database) working in
> Ipv6 ?? Seems to me that it should work, since NEPL (Nemo
> implementation for linux) is using it...
>
>
> On 2/27/07,  mael.boutin@laposte.net <mael.boutin@laposte.net> wrote:
> >  Hi,
> >
> >   I have a problem with the MARK target support. I want to MARK locally generated IPv6 packets (UDP, TCP, ICMP ...). For this i use the following ip6tables command :
> >
> > ip6tables -t mangle -A OUTPUT -p udp -j MARK 0x1
> > ip6tables -t mangle -A OUTPUT -p tcp -j MARK 0x2
> >
> > All works fine, the rule is added in the OUPUT chain of mangle table. Now i want to retrieve this mark and route packets according to their mark :
> >
> > ip -6 route add 2001:688:dd00::5 via 2001:688:bb00::5 dev eth0 table TEST1
> > ip -6 route add 2001:688:dd00::5 via 2001:688:cc00::5 dev eth1 table TEST2
> >
> > => Routes seems to be taken into account and added to the tables (it doesn't appear but when you type ip -6 route show table 0 | grep TEST1 you can see the rules in TEST1)
> >
> > ip -6 rule add fwmark 0x1 table TEST1
> > ip -6 rule add fwmark 0x2 table TEST2
> >
> > => Rules are added and can be viewed with ip -6 rule show
> >
> > The test bed is set up correctly (all interfaces can be pinged).
> >
> > My problem is that when i generate a UDP flow (via nc) the packets are not marked (i suppose) by ip6tables and therefore iproute does not lookup table TEST1 as it should.
> >
> > My kernel is  2.6.19.3 with ip6tables compiled as module with all available targets, IPv6 multiple routing tables is built in as well as "use netfilter MARK value as routing key"
> >
> > Best regards,
> >
> > Maël
> >
> > Envoyez vos cartes de voeux depuis  www.laposte.net
> > Elles seront ensuite distribuées par le facteur : pratique et malin !
> >
> >
> >
>
>
>
> --
> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
>
> --
> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
>


-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-02-28  9:55 ` Boutin Maël
@ 2007-02-28 10:53   ` Yasuyuki KOZAKAI
  2007-02-28 11:36     ` Yasuyuki KOZAKAI
       [not found]     ` <200702281136.l1SBaJLe019021@toshiba.co.jp>
  0 siblings, 2 replies; 11+ messages in thread
From: Yasuyuki KOZAKAI @ 2007-02-28 10:53 UTC (permalink / raw)
  To: mael.boutin; +Cc: netfilter


Hi,

From: "Boutin Maël" <mael.boutin@laposte.net>
Date: Wed, 28 Feb 2007 10:55:01 +0100

> After some tests, it appears that it is the OUTPUT chain that does not
> work. Indeed with the PREROUTING chain the mark is taken into account
> by iproute and the packet is routed as indicated in the corresponding
> tables.
> 
> Is it a bug or something i missed ?

I suspect IPv6 routing. But for conformation, can you try

	ip6tables -t mangle -A OUTPUT -m mark --mark 0x1 -j LOG	--log-prefix "out6 "
	ip6tables -t mangle -A POSTROUTING -m mark --mark 0x1 -j LOG --log-prefix "post6 "

after your rules and check whether you can see some log by LOG target ?
And do you have any chance to try 2.6.20 ?

-- Yasuyuki Kozakai


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-02-28 10:53   ` Yasuyuki KOZAKAI
@ 2007-02-28 11:36     ` Yasuyuki KOZAKAI
       [not found]     ` <200702281136.l1SBaJLe019021@toshiba.co.jp>
  1 sibling, 0 replies; 11+ messages in thread
From: Yasuyuki KOZAKAI @ 2007-02-28 11:36 UTC (permalink / raw)
  To: yasuyuki.kozakai; +Cc: netfilter


Hi again,

From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Date: Wed, 28 Feb 2007 19:53:22 +0900 (JST)

> 
> Hi,
> 
> From: "Boutin Maël" <mael.boutin@laposte.net>
> Date: Wed, 28 Feb 2007 10:55:01 +0100
> 
> > After some tests, it appears that it is the OUTPUT chain that does not
> > work. Indeed with the PREROUTING chain the mark is taken into account
> > by iproute and the packet is routed as indicated in the corresponding
> > tables.
> > 
> > Is it a bug or something i missed ?
> 
> I suspect IPv6 routing. But for conformation, can you try
> 
> 	ip6tables -t mangle -A OUTPUT -m mark --mark 0x1 -j LOG	--log-prefix "out6 "
> 	ip6tables -t mangle -A POSTROUTING -m mark --mark 0x1 -j LOG --log-prefix "post6 "
> 
> after your rules and check whether you can see some log by LOG target ?
> And do you have any chance to try 2.6.20 ?

I found that ip6_route_me_harder() doesn't take into account of mark.

Can you try this patch ?

Regards,

[NETFILTER]: ip6_route_me_harder should take into account mark

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
index f6294e5..ca50b58 100644
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
 	struct dst_entry *dst;
 	struct flowi fl = {
 		.oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
+		.mark = skb->mark,
 		.nl_u =
 		{ .ip6_u =
 		  { .daddr = iph->daddr,


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
       [not found]     ` <200702281136.l1SBaJLe019021@toshiba.co.jp>
@ 2007-02-28 11:53       ` Boutin Maël
  2007-02-28 12:38         ` Yasuyuki KOZAKAI
       [not found]         ` <200702281238.l1SCcE4F016826@toshiba.co.jp>
  0 siblings, 2 replies; 11+ messages in thread
From: Boutin Maël @ 2007-02-28 11:53 UTC (permalink / raw)
  To: Yasuyuki KOZAKAI; +Cc: netfilter

Thanks for the patch, however it does not work, the kernel does not compile :

line 18:

struct sk_buff has no member named mark (it should be nfmark no ?)
unknown field "mark" specified in initializer

To answer your previous questions :
yes i have logs in the kernel for both out6 and post6.
Of course i can try 2.6.20 but it seems to me that there is the same
problem (i tried before)

In my opinion the problem is due to the fact that the routing decision
is made before OUTPUT chain but not relaunched once the nfmark routing
key is changed which is i think how it should work.

Best regards,

Maël

On 2/28/07, Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp> wrote:
>
> Hi again,
>
> From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> Date: Wed, 28 Feb 2007 19:53:22 +0900 (JST)
>
> >
> > Hi,
> >
> > From: "Boutin Maël" <mael.boutin@laposte.net>
> > Date: Wed, 28 Feb 2007 10:55:01 +0100
> >
> > > After some tests, it appears that it is the OUTPUT chain that does not
> > > work. Indeed with the PREROUTING chain the mark is taken into account
> > > by iproute and the packet is routed as indicated in the corresponding
> > > tables.
> > >
> > > Is it a bug or something i missed ?
> >
> > I suspect IPv6 routing. But for conformation, can you try
> >
> >       ip6tables -t mangle -A OUTPUT -m mark --mark 0x1 -j LOG --log-prefix "out6 "
> >       ip6tables -t mangle -A POSTROUTING -m mark --mark 0x1 -j LOG --log-prefix "post6 "
> >
> > after your rules and check whether you can see some log by LOG target ?
> > And do you have any chance to try 2.6.20 ?
>
> I found that ip6_route_me_harder() doesn't take into account of mark.
>
> Can you try this patch ?
>
> Regards,
>
> [NETFILTER]: ip6_route_me_harder should take into account mark
>
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
>
> diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> index f6294e5..ca50b58 100644
> --- a/net/ipv6/netfilter.c
> +++ b/net/ipv6/netfilter.c
> @@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
>         struct dst_entry *dst;
>         struct flowi fl = {
>                 .oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
> +               .mark = skb->mark,
>                 .nl_u =
>                 { .ip6_u =
>                   { .daddr = iph->daddr,
>


-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-02-28 11:53       ` Boutin Maël
@ 2007-02-28 12:38         ` Yasuyuki KOZAKAI
       [not found]         ` <200702281238.l1SCcE4F016826@toshiba.co.jp>
  1 sibling, 0 replies; 11+ messages in thread
From: Yasuyuki KOZAKAI @ 2007-02-28 12:38 UTC (permalink / raw)
  To: mael.boutin; +Cc: netfilter


Hi,

From: "Boutin Maël" <mael.boutin@laposte.net>
Date: Wed, 28 Feb 2007 12:53:44 +0100

> Thanks for the patch, however it does not work, the kernel does not compile :
> 
> line 18:
> 
> struct sk_buff has no member named mark (it should be nfmark no ?)
> unknown field "mark" specified in initializer

Ah yes. nfmark is renamed to mark at 2.6.20.

> To answer your previous questions :
> yes i have logs in the kernel for both out6 and post6.

Thanks.

> Of course i can try 2.6.20 but it seems to me that there is the same
> problem (i tried before)

I think so.

> In my opinion the problem is due to the fact that the routing decision
> is made before OUTPUT chain but not relaunched once the nfmark routing
> key is changed which is i think how it should work.

Yes. That is what ip6_route_me_harder does.

How about this for 2.6.19 ?

[NETFILTER]: ip6_route_me_harder should take into account mark

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
index f6294e5..ca50b58 100644
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
 	struct dst_entry *dst;
 	struct flowi fl = {
 		.oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
+		.mark = skb->nfmark,
 		.nl_u =
 		{ .ip6_u =
 		  { .daddr = iph->daddr,


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
       [not found]         ` <200702281238.l1SCcE4F016826@toshiba.co.jp>
@ 2007-03-01 10:32           ` Boutin Maël
  2007-03-01 11:05             ` Boutin Maël
  0 siblings, 1 reply; 11+ messages in thread
From: Boutin Maël @ 2007-03-01 10:32 UTC (permalink / raw)
  To: Yasuyuki KOZAKAI; +Cc: netfilter

Sorry, i did not answer to the netfilter list.

It does not work with the 2.6.20 kernel although the patch is applied.
I followed the functions calls and i really do not understand what is
missing. In my opinion the ip rule is matched and applied to the
packet (the dst_entry seems to be good, at least the net_device
structure). The skb->dev field contain the good device (eth0) from
which the paket should leave the terminal (tested in function
ip6_output2) however the pcket continues to leave through the default
interface.

I am not an expert of Linux and the IPv6 stack, so your help would be
greatly appreciated !

On 2/28/07, Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp> wrote:
>
> Hi,
>
> From: "Boutin Maël" <mael.boutin@laposte.net>
> Date: Wed, 28 Feb 2007 12:53:44 +0100
>
> > Thanks for the patch, however it does not work, the kernel does not compile :
> >
> > line 18:
> >
> > struct sk_buff has no member named mark (it should be nfmark no ?)
> > unknown field "mark" specified in initializer
>
> Ah yes. nfmark is renamed to mark at 2.6.20.
>
> > To answer your previous questions :
> > yes i have logs in the kernel for both out6 and post6.
>
> Thanks.
>
> > Of course i can try 2.6.20 but it seems to me that there is the same
> > problem (i tried before)
>
> I think so.
>
> > In my opinion the problem is due to the fact that the routing decision
> > is made before OUTPUT chain but not relaunched once the nfmark routing
> > key is changed which is i think how it should work.
>
> Yes. That is what ip6_route_me_harder does.
>
> How about this for 2.6.19 ?
>
> [NETFILTER]: ip6_route_me_harder should take into account mark
>
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
>
> diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> index f6294e5..ca50b58 100644
> --- a/net/ipv6/netfilter.c
> +++ b/net/ipv6/netfilter.c
> @@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
>         struct dst_entry *dst;
>         struct flowi fl = {
>                 .oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
> +               .mark = skb->nfmark,
>                 .nl_u =
>                 { .ip6_u =
>                   { .daddr = iph->daddr,
>


-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-03-01 10:32           ` Boutin Maël
@ 2007-03-01 11:05             ` Boutin Maël
  2007-03-01 15:18               ` Pascal Hambourg
  0 siblings, 1 reply; 11+ messages in thread
From: Boutin Maël @ 2007-03-01 11:05 UTC (permalink / raw)
  To: Yasuyuki KOZAKAI; +Cc: netfilter

Sorry,

Ok with the patch it works... I expected that ipv6 source address
would change and take the ipv6 adress of the new interface, which is
after reflexion stupid ... The packet exits the terminal with the new
interface, everything good... almost this creates a new problem for us
...

We would like to have the Source IPv6 address of the new interface and
not the IPv6 adress of the default route. Is it possible on PREROUTING
hook to change the IPv6 address of the outgoing packets ?


On 3/1/07, Boutin Maël <mael.boutin@laposte.net> wrote:
> Sorry, i did not answer to the netfilter list.
>
> It does not work with the 2.6.20 kernel although the patch is applied.
> I followed the functions calls and i really do not understand what is
> missing. In my opinion the ip rule is matched and applied to the
> packet (the dst_entry seems to be good, at least the net_device
> structure). The skb->dev field contain the good device (eth0) from
> which the paket should leave the terminal (tested in function
> ip6_output2) however the pcket continues to leave through the default
> interface.
>
> I am not an expert of Linux and the IPv6 stack, so your help would be
> greatly appreciated !
>
> On 2/28/07, Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp> wrote:
> >
> > Hi,
> >
> > From: "Boutin Maël" <mael.boutin@laposte.net>
> > Date: Wed, 28 Feb 2007 12:53:44 +0100
> >
> > > Thanks for the patch, however it does not work, the kernel does not compile :
> > >
> > > line 18:
> > >
> > > struct sk_buff has no member named mark (it should be nfmark no ?)
> > > unknown field "mark" specified in initializer
> >
> > Ah yes. nfmark is renamed to mark at 2.6.20.
> >
> > > To answer your previous questions :
> > > yes i have logs in the kernel for both out6 and post6.
> >
> > Thanks.
> >
> > > Of course i can try 2.6.20 but it seems to me that there is the same
> > > problem (i tried before)
> >
> > I think so.
> >
> > > In my opinion the problem is due to the fact that the routing decision
> > > is made before OUTPUT chain but not relaunched once the nfmark routing
> > > key is changed which is i think how it should work.
> >
> > Yes. That is what ip6_route_me_harder does.
> >
> > How about this for 2.6.19 ?
> >
> > [NETFILTER]: ip6_route_me_harder should take into account mark
> >
> > Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
> >
> > diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> > index f6294e5..ca50b58 100644
> > --- a/net/ipv6/netfilter.c
> > +++ b/net/ipv6/netfilter.c
> > @@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
> >         struct dst_entry *dst;
> >         struct flowi fl = {
> >                 .oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
> > +               .mark = skb->nfmark,
> >                 .nl_u =
> >                 { .ip6_u =
> >                   { .daddr = iph->daddr,
> >
>
>
> --
> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
>


-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-03-01 11:05             ` Boutin Maël
@ 2007-03-01 15:18               ` Pascal Hambourg
  2007-03-01 15:42                 ` Eray Aslan
  0 siblings, 1 reply; 11+ messages in thread
From: Pascal Hambourg @ 2007-03-01 15:18 UTC (permalink / raw)
  To: netfilter

Hello,

Boutin Maël a écrit :
> 
> We would like to have the Source IPv6 address of the new interface

Which address ? You know that it is common for an interface to have 
multiple global IPv6 addresses, or no global IPv6 address (only a link 
local address).

> and
> not the IPv6 adress of the default route. Is it possible on PREROUTING
> hook to change the IPv6 address of the outgoing packets ?

I'm afraid not. This is not even possible in IPv4. It is possible to NAT 
the IPv4 source address in the POSTROUTING chain, but there is no such 
support for IPv6 NAT (and don't think there will ever be any).


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-03-01 15:18               ` Pascal Hambourg
@ 2007-03-01 15:42                 ` Eray Aslan
  2007-03-01 21:31                   ` Boutin Maël
  0 siblings, 1 reply; 11+ messages in thread
From: Eray Aslan @ 2007-03-01 15:42 UTC (permalink / raw)
  To: netfilter

Pascal Hambourg wrote:
 >> and
>> not the IPv6 adress of the default route. Is it possible on PREROUTING
>> hook to change the IPv6 address of the outgoing packets ?
> 
> I'm afraid not. This is not even possible in IPv4. It is possible to NAT
> the IPv4 source address in the POSTROUTING chain, but there is no such
> support for IPv6 NAT (and don't think there will ever be any).

I remember reading a comment for such a request from a member of the
core team (think it was Harald Welte).  The comment was  "over my dead
body".  So yeah it is a pretty safe bet that it won't happen.

-- 
Eray


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re IPv6 MARK support
  2007-03-01 15:42                 ` Eray Aslan
@ 2007-03-01 21:31                   ` Boutin Maël
  0 siblings, 0 replies; 11+ messages in thread
From: Boutin Maël @ 2007-03-01 21:31 UTC (permalink / raw)
  To: Eray Aslan; +Cc: netfilter

Ok... Well i will see what we can do

Thank you evrybody for ur help and particularly Yasuyuki for his patch

On 3/1/07, Eray Aslan <eray.aslan@caf.com.tr> wrote:
> Pascal Hambourg wrote:
>  >> and
> >> not the IPv6 adress of the default route. Is it possible on PREROUTING
> >> hook to change the IPv6 address of the outgoing packets ?
> >
> > I'm afraid not. This is not even possible in IPv4. It is possible to NAT
> > the IPv4 source address in the POSTROUTING chain, but there is no such
> > support for IPv6 NAT (and don't think there will ever be any).
>
> I remember reading a comment for such a request from a member of the
> core team (think it was Harald Welte).  The comment was  "over my dead
> body".  So yeah it is a pretty safe bet that it won't happen.
>
> --
> Eray
>
>


-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-03-01 21:31 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-28  8:04 Re IPv6 MARK support Boutin Maël
2007-02-28  9:55 ` Boutin Maël
2007-02-28 10:53   ` Yasuyuki KOZAKAI
2007-02-28 11:36     ` Yasuyuki KOZAKAI
     [not found]     ` <200702281136.l1SBaJLe019021@toshiba.co.jp>
2007-02-28 11:53       ` Boutin Maël
2007-02-28 12:38         ` Yasuyuki KOZAKAI
     [not found]         ` <200702281238.l1SCcE4F016826@toshiba.co.jp>
2007-03-01 10:32           ` Boutin Maël
2007-03-01 11:05             ` Boutin Maël
2007-03-01 15:18               ` Pascal Hambourg
2007-03-01 15:42                 ` Eray Aslan
2007-03-01 21:31                   ` Boutin Maël

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.