problem with flowi structure

problem with flowi structure

[Nicola Padovano]

Hi all. I'm "studying" the flowi structure.
I see some source code:

[CODE]
...
fl.nl_u.ip4_u.saddr = 0
...
ip_route_output_key(....,&fl,....)
...
(where fl is a flowi struct)
[/CODE]

what is the meaning of saddr = 0?


-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[Eric Dumazet]

Le jeudi 16 septembre 2010 à 17:14 +0200, Nicola Padovano a écrit :
> Hi all. I'm "studying" the flowi structure.
> I see some source code:
> 
> [CODE]
> ...
> fl.nl_u.ip4_u.saddr = 0
> ...
> ip_route_output_key(....,&fl,....)
> ...
> (where fl is a flowi struct)
> [/CODE]
> 
> what is the meaning of saddr = 0?
> 
> 

This means ip_route_output_key() is allowed to chose whatever source ip
address to reach remote peer.

Re: problem with flowi structure

[Nicola Padovano]

> This means ip_route_output_key() is allowed to chose whatever source ip
> address to reach remote peer.

I don't well understand it yet...what is the reason for choosing
whatever source ip?



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[Eric Dumazet]

Le jeudi 16 septembre 2010 à 17:30 +0200, Nicola Padovano a écrit :
> > This means ip_route_output_key() is allowed to chose whatever source ip
> > address to reach remote peer.
> 
> I don't well understand it yet...what is the reason for choosing
> whatever source ip?
> 
> 
> 

Because some users want a particular source IP ?

man bind



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

Re: problem with flowi structure

[Nicola Padovano]

ok, let's step back...
what's the task of ip_route_output_key function ?

-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[AIJAZ BAIG]

Hi there,

Well..if u see the code, ull see that ip_route_output_key is a wrapper
around ip_route_output_flow which in turn internally calls
__ip_route_output_key. This later function tries to find a route for a
packet first by looking up the routing cache and then if it isnt found
there it  constructs a cache entry by calling its slow counterpart
which is ip_route_output_slow.

Now, the name tells u a lot. First ip_route_output_key tells u that
this function 'routes' an 'output' packet. An output packet normally
means that the packet is a locally generated packet. The routing (L3)
protocol being used is ip (ipv4 specifically) and key tells us that we
are specifying the key to be used to check the routing cache (since
the cache is organized as a hash and it needs a key to retrieve an
entry).

Thus all in all, the ip_route_output_key function is used to get a
route for an output packet either from the routing cache if an entry
is present or create one and update the cache accordingly.

Hope it helped.

Regards,
Aijaz

On 9/17/10, Nicola Padovano <nicola.padovano@gmail.com> wrote:
> ok, let's step back...
> what's the task of ip_route_output_key function ?
>
> --
> Nicola Padovano
> e-mail: nicola.padovano@gmail.com
> web: http://npadovano.altervista.org
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: problem with flowi structure

[Nicola Padovano]

Aijaz, great! Now it' clear. Thank you.
It remains a problem: the meaning of

fl.nl_u.ip4_u.saddr = 0

But, first of all:
- we know that a routing table doesn't contain the ip source
- but the routing cache contains it.

so my first question is: why routing cache has it and routing cache
not? what it its usage?
Then my second question: the meaning of fl.nl_u.ip4_u.saddr = 0

thank you very much

On Fri, Sep 17, 2010 at 7:40 AM, AIJAZ BAIG <aijazbaig1@gmail.com> wrote:
> Hi there,
>
> Well..if u see the code, ull see that ip_route_output_key is a wrapper
> around ip_route_output_flow which in turn internally calls
> __ip_route_output_key. This later function tries to find a route for a
> packet first by looking up the routing cache and then if it isnt found
> there it  constructs a cache entry by calling its slow counterpart
> which is ip_route_output_slow.
>
> Now, the name tells u a lot. First ip_route_output_key tells u that
> this function 'routes' an 'output' packet. An output packet normally
> means that the packet is a locally generated packet. The routing (L3)
> protocol being used is ip (ipv4 specifically) and key tells us that we
> are specifying the key to be used to check the routing cache (since
> the cache is organized as a hash and it needs a key to retrieve an
> entry).
>
> Thus all in all, the ip_route_output_key function is used to get a
> route for an output packet either from the routing cache if an entry
> is present or create one and update the cache accordingly.
>
> Hope it helped.
>
> Regards,
> Aijaz
>
> On 9/17/10, Nicola Padovano <nicola.padovano@gmail.com> wrote:
>> ok, let's step back...
>> what's the task of ip_route_output_key function ?
>>
>> --
>> Nicola Padovano
>> e-mail: nicola.padovano@gmail.com
>> web: http://npadovano.altervista.org
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter-devel"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[Eric Dumazet]

Le vendredi 17 septembre 2010 à 10:46 +0200, Nicola Padovano a écrit :
> Aijaz, great! Now it' clear. Thank you.
> It remains a problem: the meaning of
> 
> fl.nl_u.ip4_u.saddr = 0
> 
> But, first of all:
> - we know that a routing table doesn't contain the ip source
> - but the routing cache contains it.
> 
> so my first question is: why routing cache has it and routing cache
> not? what it its usage?
> Then my second question: the meaning of fl.nl_u.ip4_u.saddr = 0
> 
> thank you very much

# ip addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000 txqueues 4 
    link/ether f4:ce:46:bb:32:d4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.108/24 brd 192.168.20.255 scope global eth1
    inet6 fe80::f6ce:46ff:febb:32d4/64 scope link 
       valid_lft forever preferred_lft forever
# ip addr add 192.168.20.67/24 dev eth1
# ip addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000 txqueues 4 
    link/ether f4:ce:46:bb:32:d4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.108/24 brd 192.168.20.255 scope global eth1
    inet 192.168.20.67/24 scope global secondary eth1
    inet6 fe80::f6ce:46ff:febb:32d4/64 scope link 
       valid_lft forever preferred_lft forever
# ip ro
192.168.20.0/24 dev eth1  proto kernel  scope link  src 192.168.20.108 
default via 192.168.20.254 dev eth1 

# ip ro flush cache
# ip ro flush cache
# ip ro get 192.168.20.110
192.168.20.110 dev eth1  src 192.168.20.108 
    cache  mtu 1500 advmss 1460 hoplimit 64
# ip ro get 192.168.20.110 from 192.168.20.67
192.168.20.110 from 192.168.20.67 dev eth1 
    cache  mtu 1500 advmss 1460 hoplimit 64
# ip ro list cache
192.168.20.110 dev eth1  src 192.168.20.108 
    cache  mtu 1500 advmss 1460 hoplimit 64
192.168.20.110 from 192.168.20.67 dev eth1 
    cache  mtu 1500 advmss 1460 hoplimit 64

You can see two different routes in cache to reach 192.168.20.110,
one from "0.0.0.0" (we force src 192.168.20.108),
one from 192.168.20.67 

With different keys (src addr, tos, fwmark, ...) we can have a lot of
different routes for apparently same destination

Re: problem with flowi structure

[Nicola Padovano]

so, setting fl.nl_u.ip4_u.saddr = 0 is a kind of "jolly" selector of
the source address?

On Fri, Sep 17, 2010 at 11:08 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 17 septembre 2010 à 10:46 +0200, Nicola Padovano a écrit :
>> Aijaz, great! Now it' clear. Thank you.
>> It remains a problem: the meaning of
>>
>> fl.nl_u.ip4_u.saddr = 0
>>
>> But, first of all:
>> - we know that a routing table doesn't contain the ip source
>> - but the routing cache contains it.
>>
>> so my first question is: why routing cache has it and routing cache
>> not? what it its usage?
>> Then my second question: the meaning of fl.nl_u.ip4_u.saddr = 0
>>
>> thank you very much
>
> # ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000 txqueues 4
>    link/ether f4:ce:46:bb:32:d4 brd ff:ff:ff:ff:ff:ff
>    inet 192.168.20.108/24 brd 192.168.20.255 scope global eth1
>    inet6 fe80::f6ce:46ff:febb:32d4/64 scope link
>       valid_lft forever preferred_lft forever
> # ip addr add 192.168.20.67/24 dev eth1
> # ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000 txqueues 4
>    link/ether f4:ce:46:bb:32:d4 brd ff:ff:ff:ff:ff:ff
>    inet 192.168.20.108/24 brd 192.168.20.255 scope global eth1
>    inet 192.168.20.67/24 scope global secondary eth1
>    inet6 fe80::f6ce:46ff:febb:32d4/64 scope link
>       valid_lft forever preferred_lft forever
> # ip ro
> 192.168.20.0/24 dev eth1  proto kernel  scope link  src 192.168.20.108
> default via 192.168.20.254 dev eth1
>
> # ip ro flush cache
> # ip ro flush cache
> # ip ro get 192.168.20.110
> 192.168.20.110 dev eth1  src 192.168.20.108
>    cache  mtu 1500 advmss 1460 hoplimit 64
> # ip ro get 192.168.20.110 from 192.168.20.67
> 192.168.20.110 from 192.168.20.67 dev eth1
>    cache  mtu 1500 advmss 1460 hoplimit 64
> # ip ro list cache
> 192.168.20.110 dev eth1  src 192.168.20.108
>    cache  mtu 1500 advmss 1460 hoplimit 64
> 192.168.20.110 from 192.168.20.67 dev eth1
>    cache  mtu 1500 advmss 1460 hoplimit 64
>
> You can see two different routes in cache to reach 192.168.20.110,
> one from "0.0.0.0" (we force src 192.168.20.108),
> one from 192.168.20.67
>
> With different keys (src addr, tos, fwmark, ...) we can have a lot of
> different routes for apparently same destination
>
>
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with flowi structure

[Nicola Padovano]

> With different keys (src addr, tos, fwmark, ...) we can have a lot of
> different routes for apparently same destination
and why this reasoning it isn't present on the routing table?
I mean: there will be a reason for which this isn't present in the routing table


-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[Eric Dumazet]

Le vendredi 17 septembre 2010 à 18:27 +0200, Nicola Padovano a écrit :
> > With different keys (src addr, tos, fwmark, ...) we can have a lot of
> > different routes for apparently same destination
> and why this reasoning it isn't present on the routing table?
> I mean: there will be a reason for which this isn't present in the routing table
> 
> 

It is present, of course, since route cache can be flushed (or
bypassed), you need to be able to rebuild it from a stable reference.

ip rule ls

ip ro list table xxx



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

Re: problem with flowi structure

[Nicola Padovano]

ok man :)
the last question is about  fl.nl_u.ip4_u.saddr = 0...
is it a kind of "jolly" selector of the source address?
i.e. if we have a simplified cache route

SOURCE IP    DEST IP    NEXT HOP
ips1                  google         nexthop1
ips2                  google         nexthop2

with
...saddr = 0
....daddr = google
....tos =....
i get nexthop1 or nexthop2. right?


On Fri, Sep 17, 2010 at 6:34 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 17 septembre 2010 à 18:27 +0200, Nicola Padovano a écrit :
>> > With different keys (src addr, tos, fwmark, ...) we can have a lot of
>> > different routes for apparently same destination
>> and why this reasoning it isn't present on the routing table?
>> I mean: there will be a reason for which this isn't present in the routing table
>>
>>
>
> It is present, of course, since route cache can be flushed (or
> bypassed), you need to be able to rebuild it from a stable reference.
>
> ip rule ls
>
> ip ro list table xxx
>
>
>
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with flowi structure

[Eric Dumazet]

Dont top post, please.

Le vendredi 17 septembre 2010 à 19:05 +0200, Nicola Padovano a écrit :
> ok man :)
> the last question is about  fl.nl_u.ip4_u.saddr = 0...
> is it a kind of "jolly" selector of the source address?
> i.e. if we have a simplified cache route
> 
> SOURCE IP    DEST IP    NEXT HOP
> ips1                  google         nexthop1
> ips2                  google         nexthop2
> 
> with
> ...saddr = 0
> ....daddr = google
> ....tos =....
> i get nexthop1 or nexthop2. right?


Not "or" but exactly one.

If you have say 65534 ip addresses on your host (a full /16 network)

192.168.X.Y

If you want to send a frame from 182.168.1.2 to google, for sure the
route you are going to use is :

192.168.1.2  ->  google


If you want to send a frame from 182.168.10.20 to google, for sure the
route you are going to use is :

192.168.10.20  ->  google

and not the 192.168.1.2 -> google

if you say now :

Send a packet to google, please, I dont care of what source address you
chose, but I am interested to receive an answer, of course. (application
does not use bind() system call, only a send())

Then we look at the routing table given all the keys (for example, the
socket FWMARK or TOS value), and choose the primary address of the
network device the routes takes to join google.

Re: problem with flowi structure

[Nicola Padovano]

> if you say now :
>
> Send a packet to google, please, I dont care of what source address you
> chose, but I am interested to receive an answer, of course. (application
> does not use bind() system call, only a send())

why an application that wants to send a packet to google would send it
with a different source ip of the host in which it resides?
ie. an application is on a machine which ip is: 192.168.0.2 and the
machine has only one ip address...

-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: problem with flowi structure

[Eric Dumazet]

Le vendredi 17 septembre 2010 à 20:01 +0200, Nicola Padovano a écrit :
> > if you say now :
> >
> > Send a packet to google, please, I dont care of what source address you
> > chose, but I am interested to receive an answer, of course. (application
> > does not use bind() system call, only a send())
> 
> why an application that wants to send a packet to google would send it
> with a different source ip of the host in which it resides?
> ie. an application is on a machine which ip is: 192.168.0.2 and the
> machine has only one ip address...
> 

I dont understand the question or the problem.

If you look closer, you can see your machine has at least two addresses.



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

Re: problem with flowi structure

[Nicola Padovano]

On Fri, Sep 17, 2010 at 8:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 17 septembre 2010 à 20:01 +0200, Nicola Padovano a écrit :
>> > if you say now :
>> >
>> > Send a packet to google, please, I dont care of what source address you
>> > chose, but I am interested to receive an answer, of course. (application
>> > does not use bind() system call, only a send())
>>
>> why an application that wants to send a packet to google would send it
>> with a different source ip of the host in which it resides?
>> ie. an application is on a machine which ip is: 192.168.0.2 and the
>> machine has only one ip address...
>>
>
> I dont understand the question or the problem.
>
> If you look closer, you can see your machine has at least two addresses.

ok, let's try in this way.

the code is this:

[CODE]
if (hooknumber == NF_INET_LOCAL_IN) fl.nl_u.ip4_u.saddr = niph->saddr;
  //niph is the pointer to ip header of the packet to send
if (hooknumber == NF_INET_FORWARD) fl.nl_u.ip4_u.saddr = 0;
[/CODE]

so, i don't understand why saddr = 0 when the hooknumber is NF_INET_FORWARD....

this is the real problem.

-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with flowi structure

[Jan Engelhardt]

On Friday 2010-09-17 20:25, Nicola Padovano wrote:
>
>[CODE]
>if (hooknumber == NF_INET_LOCAL_IN) fl.nl_u.ip4_u.saddr = niph->saddr;
>  //niph is the pointer to ip header of the packet to send
>if (hooknumber == NF_INET_FORWARD) fl.nl_u.ip4_u.saddr = 0;
>[/CODE]
>
>so, i don't understand why saddr = 0 when the hooknumber is NF_INET_FORWARD....
>
>this is the real problem.

0 is automatic address selection.

Re: problem with flowi structure

[Nicola Padovano]

i.e. like a wildcard?

On Sat, Oct 2, 2010 at 1:46 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Friday 2010-09-17 20:25, Nicola Padovano wrote:
>>
>>[CODE]
>>if (hooknumber == NF_INET_LOCAL_IN) fl.nl_u.ip4_u.saddr = niph->saddr;
>>  //niph is the pointer to ip header of the packet to send
>>if (hooknumber == NF_INET_FORWARD) fl.nl_u.ip4_u.saddr = 0;
>>[/CODE]
>>
>>so, i don't understand why saddr = 0 when the hooknumber is NF_INET_FORWARD....
>>
>>this is the real problem.
>
> 0 is automatic address selection.
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

"My only ambition is not be anything at all; it seems the most
sensible thing" (C. Bukowski)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with flowi structure

[David Miller]

From: Nicola Padovano <nicola.padovano@gmail.com>
Date: Sat, 2 Oct 2010 10:08:56 +0200

> i.e. like a wildcard?

Please do not top-post, because when you top-post people need
to scroll down and read the context you're replying to, then
scroll back up to read your reply.

If, instead of top-posting, you reply after the context you're
replying to, people need to do less work to read your email.

Thanks.