Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Andi Kleen]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:
> 
> I believe this would require fixing for compatibility reasons, in the
> sense that the address is also compared to figure the interface, but I'm
> out of time now and cannot try anything before tomorrow, I'd happily
> test patches sent by then.


Even if it checked the address it would not be unique because you can have multiple
interfaces with the same addresses but different netmasks.
The SIOCGIFNETMASK interface is just broken. If you really wanted it you should use
rtnetlink instead, which allows multiple answers to a single question.
Likely postfix doesn't really need it though, the concept of checking for "local"
address is pretty dubious and likely to be incorrect for many cases.

-Andi

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

Andi Kleen schrieb am Mittwoch, den 05. September 2001:

> Even if it checked the address it would not be unique because you can
> have multiple interfaces with the same addresses but different
> netmasks.  The SIOCGIFNETMASK interface is just broken. If you really

Well, I cannot configure the same address/netmask pair more than once
for the same interface, I'm getting "file exists" back from the ip
command. FreeBSD looks up the name/address pair.

> wanted it you should use rtnetlink instead, which allows multiple
> answers to a single question.  Likely postfix doesn't really need it
> though, the concept of checking for "local" address is pretty dubious
> and likely to be incorrect for many cases.

Well, Postfix used to look at the addresses and deduce the network class
for that, but there have been many complaints by people that this would
get subnets wrong. A couple of months ago, Postfix has started to look
up the netmasks as well.

-- 
Matthias Andree

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Andrey Savochkin]

Hi,

On Wed, Sep 05, 2001 at 09:26:50PM +0200, Andi Kleen wrote:
> Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:
> > 
> > I believe this would require fixing for compatibility reasons, in the
> > sense that the address is also compared to figure the interface, but I'm
> > out of time now and cannot try anything before tomorrow, I'd happily
> > test patches sent by then.
> 
> Even if it checked the address it would not be unique because you can have multiple
> interfaces with the same addresses but different netmasks.
> The SIOCGIFNETMASK interface is just broken. If you really wanted it you should use
> rtnetlink instead, which allows multiple answers to a single question.
> Likely postfix doesn't really need it though, the concept of checking for "local"
> address is pretty dubious and likely to be incorrect for many cases.

Andi, it's right to the point.
The only one good reason for an SMTP server to bother about IP addresses at
all is a quick check for mail loops, i.e. a check at the moment of opening
TCP connection to send a message whether your peer is yourself.
Bothering about network masks just doesn't have any valid grounds.

In fact, sending message to yourself this way is not a disaster, mail system
has loop protection by design.  However, sending message to yourself wastes
system resources.

It's not possible to answer the right question (whether you talk to yourself)
inspecting IP addresses.
One may have several mail servers on a single computer, each with its own
configuration file, using different local IP addresses.
In the original example, mail systems on 192.168.0.4 and 192.168.1.1 may be
different.

So, the very right way of doing things is:
 - make admin specify the listening addresses for a mail system in the
   configuration and use them to check for loops;
 - never try to learn anything about networking configuration.

	Andrey

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Wietse Venema]

Andrey Savochkin:
> > Even if it checked the address it would not be unique because you can have multiple
> > interfaces with the same addresses but different netmasks.

The same IP address with different netmasks on the same hardware
interface? The mind boggles. How does one handle broadcasts?

> The only one good reason for an SMTP server to bother about IP addresses at
> all is a quick check for mail loops, i.e. a check at the moment of opening
> TCP connection to send a message whether your peer is yourself.
> Bothering about network masks just doesn't have any valid grounds.

The issue is not MTA loop detection.

Postfix uses the local netmask info to distinguish between local
and remote networks. At the discretion of the sysadmin, systems on
local subnets can be granted different rights than random systems
on the Internet.

If Linux insists on breaking SIOCGIFCONF then so be it, even though
it works perfectly well on any non-Linux system that I could lay
my hands on.

	Wietse

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

On Thu, 06 Sep 2001, Wietse Venema wrote:

> If Linux insists on breaking SIOCGIFCONF then so be it, even though
> it works perfectly well on any non-Linux system that I could lay
> my hands on.

Linux does not break SIOCGIFCONF as far as I can see, but
SIOCGIFNETMASK. Your inet_addr_local obtains all interfaces's addresses,
it just gets the wrong netmasks back.

notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 04:21:24PM +0200, Matthias Andree wrote:
> On Thu, 06 Sep 2001, Wietse Venema wrote:
> 
> > If Linux insists on breaking SIOCGIFCONF then so be it, even though
> > it works perfectly well on any non-Linux system that I could lay
> > my hands on.
> 
> Linux does not break SIOCGIFCONF as far as I can see, but
> SIOCGIFNETMASK. Your inet_addr_local obtains all interfaces's addresses,
> it just gets the wrong netmasks back.

Of course, SIOCGIFCONF isn't even close to provide the list of local
addresses.
Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
on common systems.  If you handle 127.0.0.2 as local, you apply side
knowledge about properties of loopback interface.
Less obvious example: routes added to `local' table.
SIOCGIFCONF can never show them.

On Thu, Sep 06, 2001 at 04:17:49PM +0200, Matthias Andree wrote:
> I'm not sure where and why you deduce the idea this is about MTA loop
> detection or peer recognition.

Because it's the obvious reason to start to be aware about networking
configuration, and all MTAs known to me try to do it.

All other reasons are absolutely artificial.
You just complicate things without a good reason by linking policies in
different areas.
If I prefer to use wider network mask than it should be and use proxy arp
service of some of my neighbours, why should it affect SMTP?
Or, vice versa, if I use narrower mask and want to use IP gateway for
directly reachable IPs?
You don't look for .htaccess files to get the idea what other IPs have
special meaning for administrators/users of the system, right?

[snip]
> > So, the very right way of doing things is:
> >  - make admin specify the listening addresses for a mail system in the
> >    configuration and use them to check for loops;
> 
> Or just use IPADDR_ANY...

If the mailer's socket is bound to IPADDR_ANY, it's hard to find which
connection attempts will be handled locally, so the best way to handle it is
to ask the admin.
I personally do not use IPADDR_ANY, use of explicit IP addresses makes things
a lot simpler.

> >  - never try to learn anything about networking configuration.
> 
> ...which is wrong, because the MTA must know its own IP addresses to
> accept domain literals, and SIOCGIFCONF works and returns all addresses,
> it just happens that looking up the second and subsequent masks fails.
> Please see RFC-1123, section 5.2.17, for details.

The language of that section is amazing:
         An SMTP MUST accept and recognize a domain literal for any of
	 its own IP addresses.
What might be ``own IP addresses'' of ``an SMTP''?..
Does SMTP server have ``own IP addresses'' at all?
It's difficult to explain what ``own IP addresses'' of a host are, not
speaking about a server...

Are ``own IP addresses'' of ``an SMTP'' the same as ``set of IP addresses,
for which packets coming from interface eth0, for example, and destined to
port 25 on them are handled locally according to the routing policy set for
the system where SMTP server is running''?
Hmm, these 2 notions don't look identical...

Hey, may be its ``own IP addresses'' are just what is specified in the
configuration file as ``own IP addresses''?
That looks like the real answer.

Best regards
		Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Wietse Venema]

Andrey Savochkin:
> Of course, SIOCGIFCONF isn't even close to provide the list of local
> addresses.
> Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> on common systems.  If you handle 127.0.0.2 as local, you apply side

127.0.0.2 is not local on any of my systems. The only exceptions
are some Linux boxen that I did not ask to do so.

I welcome suggestions, maybe even code fragments, that will allow
an MTA to correctly recognize user@[ip.address] as local, as required
by the SMTP RFC.

> On Thu, Sep 06, 2001 at 04:17:49PM +0200, Matthias Andree wrote:
> > I'm not sure where and why you deduce the idea this is about MTA loop
> > detection or peer recognition.
> 
> Because it's the obvious reason to start to be aware about networking
> configuration, and all MTAs known to me try to do it.
> 
> All other reasons are absolutely artificial.

It is perfectly OK for an MTA to make a distinction between local
subnets and the rest of the Internet.

I welcome suggestions, maybe even code fragments, that will allow
an MTA to correctly recognize the subnetworks that the machine is
attached to.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> 127.0.0.2 is not local on any of my systems. The only exceptions
> are some Linux boxen that I did not ask to do so.

Todays reading is from RFC990 in the book of Reynolds & Postel, page number 6

And the IETF spake thusly

|  The class A network number 127 is assigned the "loopback" function, that
| is, a datagram sent by a higher level protocol to a network 127 address
| should loop back inside the host. No datagram "sent" to a network 127
| address should ever appear on any network anywhere.

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Alan Cox:
> > 127.0.0.2 is not local on any of my systems. The only exceptions
> > are some Linux boxen that I did not ask to do so.
> 
> Todays reading is from RFC990 in the book of Reynolds & Postel, page number 6
> 
> And the IETF spake thusly
> 
> |  The class A network number 127 is assigned the "loopback" function, that
> | is, a datagram sent by a higher level protocol to a network 127 address
> | should loop back inside the host. No datagram "sent" to a network 127
> | address should ever appear on any network anywhere.

That's routing.

I was talking about accepting connections. None of my systems
accepts connections on 127.0.0.2, except for a couple Linux boxen
that I did not ask to do so.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 11:58:11AM -0400, Wietse Venema wrote:
> Andrey Savochkin:
> > Of course, SIOCGIFCONF isn't even close to provide the list of local
> > addresses.
> > Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> > on common systems.  If you handle 127.0.0.2 as local, you apply side
> 
> 127.0.0.2 is not local on any of my systems. The only exceptions
> are some Linux boxen that I did not ask to do so.
> 
> I welcome suggestions, maybe even code fragments, that will allow
> an MTA to correctly recognize user@[ip.address] as local, as required
> by the SMTP RFC.

The question was which ip.address in user@[ip.address] should be treated as
local.
My comment was that the only reasonable solution on Linux is to treat this
way addresses explicitly specified in the configuration file.
Postfix may show its guess at the installation time.

Now the question of recognizing user@[ip.address] as local is a question of a
simple table lookup.

Best regards
		Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andi Kleen]

On Thu, Sep 06, 2001 at 08:44:23PM +0400, Andrey Savochkin wrote:
> The question was which ip.address in user@[ip.address] should be treated as
> local.
> My comment was that the only reasonable solution on Linux is to treat this
> way addresses explicitly specified in the configuration file.
> Postfix may show its guess at the installation time.
> 
> Now the question of recognizing user@[ip.address] as local is a question of a
> simple table lookup.

It would be at least possible to ask the routing engine via RTM_GETROUTE
and checking for RTN_LOCAL if it considers an address local.
It won't cover all cases with netfilter rules etc.; but probably be a good
enough approximation.

-Andi

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 06:47:42PM +0200, Andi Kleen wrote:
> On Thu, Sep 06, 2001 at 08:44:23PM +0400, Andrey Savochkin wrote:
> > The question was which ip.address in user@[ip.address] should be treated as
> > local.
> > My comment was that the only reasonable solution on Linux is to treat this
> > way addresses explicitly specified in the configuration file.
> > Postfix may show its guess at the installation time.
> > 
> > Now the question of recognizing user@[ip.address] as local is a question of a
> > simple table lookup.
> 
> It would be at least possible to ask the routing engine via RTM_GETROUTE
> and checking for RTN_LOCAL if it considers an address local.
> It won't cover all cases with netfilter rules etc.; but probably be a good
> enough approximation.

Well, you need to enlist local addresses, not to verify, so I would suggest
inspecting `local' routing table.

But it doesn't help with the other example I provided a couple of messages
earlier: several MTAs on one system listening on their own IP addresses.
Some time ago, when I was engaged in system administration activity, almost
all my mail relays had several MTAs, each in its own chroot environments...

So, using routing in the post-install script to provide suggestion what
should be written in the configuration file is very reasonable, probably,
it's the best guess that the script can make.

	Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Wietse Venema]

Andrey Savochkin:
> > I welcome suggestions, maybe even code fragments, that will allow
> > an MTA to correctly recognize user@[ip.address] as local, as required
> > by the SMTP RFC.
> 
> The question was which ip.address in user@[ip.address] should be treated as
> local.
> My comment was that the only reasonable solution on Linux is to treat this
> way addresses explicitly specified in the configuration file.
> Postfix may show its guess at the installation time.

That is not practical. Surely there is an API to find out if an IP
address connects to the machine itself. If every UNIX system on
this planet can do it, then surely Linux can do it.

The same issue is true for local subnets. Surely there exists an
API to find out what subnetworks a machine is attached to. If every
UNIX system on this planet can do it, then surely Linux can do it.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> That is not practical. Surely there is an API to find out if an IP
> address connects to the machine itself. If every UNIX system on
> this planet can do it, then surely Linux can do it.

There are a very large number of networking configurations that Unix (here 
meaning 4.*BSD networking or its various stream hacked abuses) cannot
handle. 

How for example do you propose to answer the question for the case
Q: "is this local" A: "it depends on the sender"

With netfilter and transparent proxying active this is entirely possible

Alan

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Alan Cox:
> How for example do you propose to answer the question for the case
> Q: "is this local" A: "it depends on the sender"
> With netfilter and transparent proxying active this is entirely possible

Please explain the relevance for a real-world, SMTP based, MTA.

If an MTA receives a delivery request for user@[ip.address] then
the MTA has to decide if it is the final destination. This is
required by the SMTP RFC.

In order to enable SMTP RFC compliance, Linux has to provide the
MTA with the necessary information.  Requiring the sysadmin to
enumerate all IP addresses in a file, as suggested by some other
poster, is impractical.

If an MTA receives a mail relaying request for user@domain.name
then it would be very useful if Linux could provide the MTA with
the necessary information to distinguish between local subnetworks
and the rest of the world. Requiring the local sysadmin to enumerate
all local subnetwork blocks by hand is not practical.

I will ignore denigrating comments about competing IP stacks.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Charles Cazabon]

Wietse Venema <wietse@porcupine.org> wrote:
> Alan Cox:
> > How for example do you propose to answer the question for the case
> > Q: "is this local" A: "it depends on the sender"
> > With netfilter and transparent proxying active this is entirely possible
> 
> Please explain the relevance for a real-world, SMTP based, MTA.
> 
> If an MTA receives a delivery request for user@[ip.address] then
> the MTA has to decide if it is the final destination. This is
> required by the SMTP RFC.
> 
> In order to enable SMTP RFC compliance, Linux has to provide the
> MTA with the necessary information.  Requiring the sysadmin to
> enumerate all IP addresses in a file, as suggested by some other
> poster, is impractical.

I was that other poster.  Typing "is impractical" into your MUA doesn't
make it a fact.  It's not only a very practical solution, it's the
_most_ practical solution.

As other posters have noted, there's no magic incantation to tell you
which IP addresses happen to have an smtpd listening which are the
self-same MTA.  The only person who's going to have this information is
the administrator.

Why are you afraid to ask the mail administrator to do configuration of
the MTA?  Are you afraid they're idiots?

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> Alan Cox:
> > How for example do you propose to answer the question for the case
> > Q: "is this local" A: "it depends on the sender"
> > With netfilter and transparent proxying active this is entirely possible
> 
> Please explain the relevance for a real-world, SMTP based, MTA.

Certainly

> If an MTA receives a delivery request for user@[ip.address] then
> the MTA has to decide if it is the final destination. This is
> required by the SMTP RFC.

Lets take an absolutely clear every day of the week scenario. I have a 
mail server with two connections, eth0 is through a corporate firewall
out on to the internet. We have an ip address and name visible to the
world. Say example.com and 192.193.194.165. eth1 is the private office
network and contains private address space not visible to the outside
world. Indeed in some cases the choice of the private address space might
be considered security sensitive, but say its 10.0.0.*

You get 
RCPT root@[10.0.0.1]

is that local valid mail.

If it is from the outside world then the answer is "never heard of them,
not me". If it is from the private network the answer is "yes fine"

If you accept 10.0.0.1 from the outside you are leaking information. It
might not be 10.* it might be something like an ibm internal address range
revealing your company was bought by ibm before the press releases, it might
indicate connection to a military network ..

> In order to enable SMTP RFC compliance, Linux has to provide the
> MTA with the necessary information.  Requiring the sysadmin to

Strict RFC compliance isn't a real world goal. I doubt any mailer implements 
SEND, SOML or SAML for example. I definitely agree that the #Number and
[a.b.c.d] forms are important though, and that you need to be able to
answer the question. However you need to answer it "is this my address
from the viewpoint of the peer on this connection". I don't see why 
user configured data isnt a solution. For the 99.9% of normal cases 
SIOCGIFCONF is going to give the right data. People doing clever things
will have to set up config files. simple easy - hard possible.

> If an MTA receives a mail relaying request for user@domain.name
> then it would be very useful if Linux could provide the MTA with
> the necessary information to distinguish between local subnetworks

Define "local". Same ASN ?, by OSPF - "directly plugged into this host"
certainly doesn't cut.

> and the rest of the world. Requiring the local sysadmin to enumerate
> all local subnetwork blocks by hand is not practical.
> 
> I will ignore denigrating comments about competing IP stacks.

Reread my mail. Now think about when the API in question was designed.
The 4.* BSD world up 4.4BSD supported a much smaller subset of the possible
configurations than current stacks do. Needless to say it should not be
suprising that the API's available still reflect that limitation. That
always happens. Thats why sockets are broken for 0 length datagrams and
the C language is bad at unicode. It happens everywhere, and its not
denigrating anything.

Its unfortunate you have to go around labelling everything as "competing"
and "denigrating". You also appear confused still about the 127/8 issue.
You say "you didnt ask it to", well you certainly did, since you bound
to INADDR_ANY. Since 127/8 is looped back I don't think you can reasonably
argue that it is not one of your addresses.

Alan

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Alan Cox:
> Strict RFC compliance isn't a real world goal. I doubt any mailer implements 
> SEND, SOML or SAML for example. I definitely agree that the #Number and
> [a.b.c.d] forms are important though, and that you need to be able to
> answer the question. However you need to answer it "is this my address
> from the viewpoint of the peer on this connection". I don't see why 
> user configured data isnt a solution. For the 99.9% of normal cases 
> SIOCGIFCONF is going to give the right data. People doing clever things
> will have to set up config files. simple easy - hard possible.

Cool. I will not waste further time on this until someone takes
SIOCGIFCONF away.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> > SIOCGIFCONF is going to give the right data. People doing clever things
> > will have to set up config files. simple easy - hard possible.
> 
> Cool. I will not waste further time on this until someone takes
> SIOCGIFCONF away.

I think that is a reasonable solution. Very few people have configurations
that SIOCGIFCONF cannot properly report. If there are configurations that
are totally sane and SIOCGIFCONF can report but misreports them I consider
it a bug.

Alan

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Matthias Andree]

On Thu, 06 Sep 2001, Alan Cox wrote:

> If you accept 10.0.0.1 from the outside you are leaking information. It

No, if you accept 10.*.*.* from the outside, your routers are broken.

> user configured data isnt a solution. For the 99.9% of normal cases 
> SIOCGIFCONF is going to give the right data. People doing clever things
> will have to set up config files. simple easy - hard possible.

Alan, SIOCGIFCONF is working sufficiently, it's SIOCGIFNETMASK that
we're talking about. SIOCGIFNETMASK works properly on any other system
or - as far as I can currently test - with my patch.

-- 
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin  dont_click_this_virus.exe
end

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> On Thu, 06 Sep 2001, Alan Cox wrote:
> > If you accept 10.0.0.1 from the outside you are leaking information. It
> 
> No, if you accept 10.*.*.* from the outside, your routers are broken.

Your router does not read mail RCPT headers.

RCPT root@[10.0.0.1]

can come from any ip address.

> Alan, SIOCGIFCONF is working sufficiently, it's SIOCGIFNETMASK that
> we're talking about. SIOCGIFNETMASK works properly on any other system
> or - as far as I can currently test - with my patch.

Then that is worth looking into.

Alan

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Andi Kleen]

On Thu, Sep 06, 2001 at 09:23:43PM +0100, Alan Cox wrote:
> > Alan, SIOCGIFCONF is working sufficiently, it's SIOCGIFNETMASK that
> > we're talking about. SIOCGIFNETMASK works properly on any other system
> > or - as far as I can currently test - with my patch.
> 
> Then that is worth looking into.

First it would break lots of linux user land (which doesn't initialise sin_addr
in SIOCGIFNETMASK) and special casing for "local networks" is in any case bogus.
Netmask checking is only needed for that; it's not even needed for local address
checking.

-Andi

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Matthias Andree]

Andi Kleen did not read the patch, but flamed:

> On Thu, Sep 06, 2001 at 09:23:43PM +0100, Alan Cox wrote:
> > > Alan, SIOCGIFCONF is working sufficiently, it's SIOCGIFNETMASK that
> > > we're talking about. SIOCGIFNETMASK works properly on any other system
> > > or - as far as I can currently test - with my patch.
> > 
> > Then that is worth looking into.
> 
> First it would break lots of linux user land (which doesn't initialise sin_addr
> in SIOCGIFNETMASK) and special casing for "local networks" is in any case bogus.
> Netmask checking is only needed for that; it's not even needed for local address
> checking.

Sorry, Sir. You are missing the point, and it seems to me you have
neither looked at my patch nor at its description.

As a special service, I'll reiterate:

1. The new behaviour (match address and name) is only tried at all if
   user space passes in an AF_INET address. If userspace passes AF_INET
   and a bogus address, the lookup will fail, and 2. below will kick in.

2. If the new behaviour doesn't come up with an interface, because the
   address was wrong or not member of the AF_INET family, we just do it
   the old way (match just name).

If it breaks user land, show an honest example that my patch breaks. Any
objection is invalid without accompanying counter example.

(TCP/IP stack bug fingerprinting doesn't count.)

It's frustrating when people discuss patches they haven't even looked at
and then start flaming around randomly because someone wants to change
for portability. That's doing Linux a disservice.

-- 
Matthias Andree

O si tacuisses, poeta mansisses.

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Henning P. Schmiedehausen]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

>On Thu, 06 Sep 2001, Alan Cox wrote:

>> If you accept 10.0.0.1 from the outside you are leaking information. It

>No, if you accept 10.*.*.* from the outside, your routers are broken.

BS. This has nothing to do with "accepting connections from addresses":

% telnet mail.intermeta.de smtp
Trying 212.34.181.3...            <---- Note!
Connected to mail.intermeta.de.
Escape character is '^]'.
220 mail.intermeta.de ESMTP Sendmail 8.11.6/8.11.6; Fri, 7 Sep 2001 11:00:01 +0200
HELO mail.hometree.net
250 mail.intermeta.de Hello IDENT:henning@tangens.hometree.net [212.34.181.34], pleased to meet you
MAIL FROM: <henning@hometree.net>
250 2.1.0 <henning@hometree.net>... Sender ok
RCPT TO: <henning@[192.168.2.1]>
550 5.7.1 <henning@[192.168.2.1]>... Relaying denied
RCPT TO: <henning@[192.168.2.3]>
250 2.1.5 <henning@[192.168.2.3]>... Recipient ok
RCPT TO: <henning@[10.11.12.13]>
550 5.7.1 <henning@[10.11.12.13]>... Relaying denied
QUIT

You may guess now, which the _real_ IP address of "mail.intermeta.de"
is.  Yes, "that other mailer" leaks this information. But only for its
own, local IP address.

More "real world" you can't get as in this example. The box transfers
about 1000 Mails per day which may not be much in todays internet but
is fine as "my little mail home". Percentage of failed mails because
of [ip-addr] adressing: 0.00%

So where lies the problem with all this? If the current reporting of
the netmasks is a bug: Fine, fix it, get on with life.  

I agree totally with Alan here. If the config can be reported by the
4.3 API, then it should be and be correct. If it can't: Well tough
luck for "really, really" portable mailers.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Matthew Kirkwood]

On Thu, 6 Sep 2001, Wietse Venema wrote:

> If an MTA receives a delivery request for user@[ip.address] then
> the MTA has to decide if it is the final destination. This is
> required by the SMTP RFC.

Would it not suffice, in the common case, to check if the
local address that the SMTP connection was accepted on is
the same as the IP address in the email address?

As I see it, it breaks only for multihomed relays or weird
configurations, (with values of "breaks" close to "incurs
an extra SMTP transaction").

You could even maintain a cache of IPs that SMTP connections
had been accepted on.

Matthew.

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Matthew Kirkwood:
> On Thu, 6 Sep 2001, Wietse Venema wrote:
> 
> > If an MTA receives a delivery request for user@[ip.address] then
> > the MTA has to decide if it is the final destination. This is
> > required by the SMTP RFC.
> 
> Would it not suffice, in the common case, to check if the
> local address that the SMTP connection was accepted on is
> the same as the IP address in the email address?

That would not work with local mail submissions.  Mail may arrive
via channels other than SMTP, yet use addressing methods according
to Internet standards.

I thank those who made useful suggestions.

I apologize to those who mis-understood my question as a request
to have kernel programmers explain me the mail RFC standards.
I can RTFM the mail RFC standards just fine.

The other folks need to grow up a bit.

Over and out.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Steve VanDevender]

Wietse Venema writes:
 > If an MTA receives a mail relaying request for user@domain.name
 > then it would be very useful if Linux could provide the MTA with
 > the necessary information to distinguish between local subnetworks
 > and the rest of the world. Requiring the local sysadmin to enumerate
 > all local subnetwork blocks by hand is not practical.

I think you're making a couple of unjustified assumptions here:

First, you shouldn't assume that all the other hosts on a local subnet
are under the same administrative control as the host with the MTA in
question (think of a host in a colocation facility), and therefore you
also shouldn't assume that you should allow mail relaying to or from
other hosts on the same subnet by default.

Second, you can't assume that an administrator can or will put all hosts
he wants to allow relaying to or from on the same subnet as the MTA.

It's not only practical to require the sysadmin to enumerate which hosts
or networks he wants to permit relaying from, it's the only solution
that gives the sysadmin the required level of control over relaying
based on client IP addresses.

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Steve VanDevender:
> Wietse Venema writes:
>  > If an MTA receives a mail relaying request for user@domain.name
>  > then it would be very useful if Linux could provide the MTA with
>  > the necessary information to distinguish between local subnetworks
>  > and the rest of the world. Requiring the local sysadmin to enumerate
>  > all local subnetwork blocks by hand is not practical.
> 
> I think you're making a couple of unjustified assumptions here:

You are making unjustified assumptions:

If the kernel knows about subnets, then an application should be
able to find out about them. Whether or not you agree with the
application's reasons does not matter.

To close with yet another analogy:

A musician complained to Mozart that his music was so difficult to
play. Mozart asked: are these notes on your instrument? The musician
replied: yes. Mozart said: so play these notes.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Alan Cox]

> If the kernel knows about subnets, then an application should be
> able to find out about them. Whether or not you agree with the
> application's reasons does not matter.

There I agree - entirely. I'd also say that an application using legacy
4.3BSD API's ought to get correct answers for configurations which are
validly expressed in that specific worldview

Alan

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Wietse Venema]

Alan Cox:
> > If the kernel knows about subnets, then an application should be
> > able to find out about them. Whether or not you agree with the
> > application's reasons does not matter.
> 
> There I agree - entirely. I'd also say that an application using legacy
> 4.3BSD API's ought to get correct answers for configurations which are
> validly expressed in that specific worldview

Putting on a different hat, that of forensics and auditing, I would
claim that such functionality is useful for every API. If something
can be set, then there must be a corresponding way to find out.

For settings created with *netlink, it is entirely reasonable to
use the *netlink API to query its state. It's just a pain in the
butt for people like me to find out and advise users.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Steve VanDevender]

Wietse Venema writes:
 > Steve VanDevender:
 > > Wietse Venema writes:
 > >  > If an MTA receives a mail relaying request for user@domain.name
 > >  > then it would be very useful if Linux could provide the MTA with
 > >  > the necessary information to distinguish between local subnetworks
 > >  > and the rest of the world. Requiring the local sysadmin to enumerate
 > >  > all local subnetwork blocks by hand is not practical.
 > > 
 > > I think you're making a couple of unjustified assumptions here:
 > 
 > You are making unjustified assumptions:
 > 
 > If the kernel knows about subnets, then an application should be
 > able to find out about them. Whether or not you agree with the
 > application's reasons does not matter.

The only justification I've seen you offer so far for wanting this
netmask information is apparently to use to decide whether your MTA
should allow relaying to another host or not.  As a sysadmin who manages
several large MTA installations I'd say that allowing relaying to or
from other hosts on "local" subnets as determined by available
interfaces and netmasks should at best be an option, and that option
should be off by default -- there are too many common situations where
that would open an MTA to abuse, or circumvent other controls one would
want to put on an MTA's relaying permissions.  If you were just talking
about the problem of determining which IP addresses are bound to the
host, I wouldn't disagree with you, but you keep saying things that make
it look like you really want to have your MTA permit relaying by default
to all hosts in "local" networks based on available interfaces and
netmasks.

So if the only reason your application wants this information is to
apply it in a useless or even awful way, I'd have to question why you
feel the need to obtain the information at all.  In a pure sense maybe
an application should be able to obtain this information, but in a
practical sense if there's no good use for the information in this
specific situation then why make a big fuss about not being able to
obtain it?

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Pavel Machek]

Hi!

> How for example do you propose to answer the question for the case
> Q: "is this local" A: "it depends on the sender"

Say yes every odd second ;-).
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andi Kleen]

On Thu, Sep 06, 2001 at 12:50:51PM -0400, Wietse Venema wrote:
> That is not practical. Surely there is an API to find out if an IP
> address connects to the machine itself. If every UNIX system on
> this planet can do it, then surely Linux can do it.

It's not possible in the general case; e.g. it has to ignore NAT rules
and some of the more advanced features of policy routing

The API is rtnetlink. You can send a RTM_GETROUTE message and the kernel
will send you the routing entry for it; which has the RTN_LOCAL type for
local addresses.  

> The same issue is true for local subnets. Surely there exists an
> API to find out what subnetworks a machine is attached to. If every
> UNIX system on this planet can do it, then surely Linux can do it.

You could resolve the backwards address using rtnetlink again and check
the resulting route for LINK scope.  Again it is only an approximation
and will break in some/many cases.


-Andi

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 12:50:51PM -0400, Wietse Venema wrote:
> Andrey Savochkin:
> > > I welcome suggestions, maybe even code fragments, that will allow
> > > an MTA to correctly recognize user@[ip.address] as local, as required
> > > by the SMTP RFC.
> > 
> > The question was which ip.address in user@[ip.address] should be treated as
> > local.
> > My comment was that the only reasonable solution on Linux is to treat this
> > way addresses explicitly specified in the configuration file.
> > Postfix may show its guess at the installation time.
> 
> That is not practical. Surely there is an API to find out if an IP
> address connects to the machine itself. If every UNIX system on
> this planet can do it, then surely Linux can do it.

Let me correct you: you need to recognize not addresses that result in
connecting to the _machine_ itself, but connecting to the same _MTA_.

Let's put it this way:
trying to find those "local" IP addresses automatically,
1. you have high rate of false negatives:
   checking networking configuration by SIOCGIFCONF, you misses almost entire
   127.0.0.0/8 network, and all routes in `local' table;
2. you have potentially high rate of false positives:
   you won't work in any reasonable way if someone puts more than one MTA on
   a single system, even if he sets dedicated IP addresses for them;
   proper recognition of local mail addresses is absolutely necessary for
   mail traffic inside one system but across several MTAs.

You cannot always guess right automatically.
You can walk routing tables (looking for local routes, routes without a
gateway or whatever else) and get much better approximation.
But you can never have it right in 100% cases.

My suggestion is just not to try to be too smart.
You can't know the right configuration for everybody.
Make a right guess in 90% cases.
Always ask administrator what _he_ really wants.

	Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Wietse Venema]

Andrey Savochkin:
> > That is not practical. Surely there is an API to find out if an IP
> > address connects to the machine itself. If every UNIX system on
> > this planet can do it, then surely Linux can do it.
> 
> Let me correct you: you need to recognize not addresses that result in
> connecting to the _machine_ itself, but connecting to the same _MTA_.

The SMTP RFC requires that user@[ip.address] is correctly recognized
as a final destination.  This requires that Linux provides the MTA
with information about IP addresses that correspond with INADDR_ANY.

I am susprised that it is not possible to ask such information up
front (same with netmasks), and that an application has to actually
query a complex oracle, again and again, for every IP address.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[H. Peter Anvin]

Followup to:  <20010906173948.502BFBC06C@spike.porcupine.org>
By author:    wietse@porcupine.org (Wietse Venema)
In newsgroup: linux.dev.kernel
> 
> The SMTP RFC requires that user@[ip.address] is correctly recognized
> as a final destination.  This requires that Linux provides the MTA
> with information about IP addresses that correspond with INADDR_ANY.
> 
> I am susprised that it is not possible to ask such information up
> front (same with netmasks), and that an application has to actually
> query a complex oracle, again and again, for every IP address.
> 

In autofs, I use the following technique to determine if the IP number
for a host is local (and therefore vfsbinds can be used rather than
NFS mounts):

connect a datagram socket (which won't produce any actual traffic) to
the remote host with INADDR_ANY as the local address, and then query
the local address.  If the local address is the same as the remote
address, the address is local.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Jamie Lokier]

H. Peter Anvin wrote:
> In autofs, I use the following technique to determine if the IP number
> for a host is local (and therefore vfsbinds can be used rather than
> NFS mounts):
> 
> connect a datagram socket (which won't produce any actual traffic) to
> the remote host with INADDR_ANY as the local address, and then query
> the local address.  If the local address is the same as the remote
> address, the address is local.

Nice.  Gives false negatives in some cases (e.g. a local tunnel) but
that doesn't really matter.

I've considered this technique for deciding whether it's safe to use the
MIT-SHM extension with X:

Open a SHM segment; write fairly secure random data into it; ask the X
server to connect to that segment and read it back as an image over the
X protocol; check whether they match.

If the X server reports an error, it's remote.  If it finds a SHM
segment it may still be remote, hence the random data check.

-- Jamie

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19]

[Ben Greear]

"H. Peter Anvin" wrote:

> In autofs, I use the following technique to determine if the IP number
> for a host is local (and therefore vfsbinds can be used rather than
> NFS mounts):
> 
> connect a datagram socket (which won't produce any actual traffic) to
> the remote host with INADDR_ANY as the local address, and then query
> the local address.  If the local address is the same as the remote
> address, the address is local.

That will always work, even when you have multiple ethernet
interfaces??

Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19]

[H. Peter Anvin]

Ben Greear wrote:
> 
> That will always work, even when you have multiple ethernet
> interfaces??
> 

It better.  Otherwise you'd have the machine sending packets out one 
interface and in the other, and the two networks might not even be 
connected...

	-hpa

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19]

[Ben Greear]

"H. Peter Anvin" wrote:
> 
> Ben Greear wrote:
> >
> > That will always work, even when you have multiple ethernet
> > interfaces??
> >
> 
> It better.  Otherwise you'd have the machine sending packets out one
> interface and in the other, and the two networks might not even be
> connected...
> 
>         -hpa

This is actually quite easy to have happen unless you turn on
arp-filter.  Put both interfaces on the same network and funny
things happen (pkts go in one IF, and out the other...).  Now,
you could probably argue that for such advanced (or broken)
networks, the user has to just be more careful/specific.  I don't
know about the details for this specific issue, but so long as
the tool(s) allow (even if it's a PITA) one to force the
configuration to happen correctly, then it's no big deal...

Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 10:48:54PM -0700, Ben Greear wrote:
> "H. Peter Anvin" wrote:
> 
> > In autofs, I use the following technique to determine if the IP number
> > for a host is local (and therefore vfsbinds can be used rather than
> > NFS mounts):
> > 
> > connect a datagram socket (which won't produce any actual traffic) to
> > the remote host with INADDR_ANY as the local address, and then query
> > the local address.  If the local address is the same as the remote
> > address, the address is local.
> 
> That will always work, even when you have multiple ethernet
> interfaces??

It will work almost always, except cases where administrator set different
preffered sources in local routes.
I.e. it is indeed a very good approximation, but autofs shouldn't still hang
or do nasty things if the check with the datagram socket shows that address
isn't local, but in reality it happens to be local.
A subtle misbehavior or loss of efficiency are acceptable, in my opinion.

Theoretically, it might be possible to create a configuration which gives
false positive in this check, but I can't see how it may be harmful...

	Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19]

[H. Peter Anvin]

Andrey Savochkin wrote:
> 
> It will work almost always, except cases where administrator set different
> preffered sources in local routes.
> I.e. it is indeed a very good approximation, but autofs shouldn't still hang
> or do nasty things if the check with the datagram socket shows that address
> isn't local, but in reality it happens to be local.
> A subtle misbehavior or loss of efficiency are acceptable, in my opinion.
> 
> Theoretically, it might be possible to create a configuration which gives
> false positive in this check, but I can't see how it may be harmful...
> 

If the check gives a false negative, autofs will create an NFS mount 
even though it's a local file (which may fail if the filesystem isn't 
exported, and is definitely slower.)

If the check gives a false positive, it will try a local bind (and 
probably fail) even though it is a remote filesystem.

	-hpa

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[dean gaudet]

On Thu, 6 Sep 2001, Wietse Venema wrote:

> Andrey Savochkin:
> > > That is not practical. Surely there is an API to find out if an IP
> > > address connects to the machine itself. If every UNIX system on
> > > this planet can do it, then surely Linux can do it.
> >
> > Let me correct you: you need to recognize not addresses that result in
> > connecting to the _machine_ itself, but connecting to the same _MTA_.
>
> The SMTP RFC requires that user@[ip.address] is correctly recognized
> as a final destination.  This requires that Linux provides the MTA
> with information about IP addresses that correspond with INADDR_ANY.
>
> I am susprised that it is not possible to ask such information up
> front (same with netmasks), and that an application has to actually
> query a complex oracle, again and again, for every IP address.

how does your MTA figure out that it's behind a NAT?  it doesn't matter
what unix it's running on, there's no standard way for it to know that an
address translation has occured before getting to its front-door.

i've dealt with almost the exact same problem you're dealing with now when
i was correcting apache's virtual hosting mechanism.  the only solution
which i found to work *always* was to force the administrator to
explicitly list the addresses.

-dean

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Wietse Venema]

dean gaudet:
> On Thu, 6 Sep 2001, Wietse Venema wrote:
> 
> > Andrey Savochkin:
> > > > That is not practical. Surely there is an API to find out if an IP
> > > > address connects to the machine itself. If every UNIX system on
> > > > this planet can do it, then surely Linux can do it.
> > >
> > > Let me correct you: you need to recognize not addresses that result in
> > > connecting to the _machine_ itself, but connecting to the same _MTA_.
> >
> > The SMTP RFC requires that user@[ip.address] is correctly recognized
> > as a final destination.  This requires that Linux provides the MTA
> > with information about IP addresses that correspond with INADDR_ANY.
> >
> > I am susprised that it is not possible to ask such information up
> > front (same with netmasks), and that an application has to actually
> > query a complex oracle, again and again, for every IP address.
> 
> how does your MTA figure out that it's behind a NAT?  it doesn't matter
> what unix it's running on, there's no standard way for it to know that an
> address translation has occured before getting to its front-door.

The MTA does not have to know. The DNS on the inside of the NAT
gateway should list "inside" machines by their "inside" address.

That eliminates a lot of other problems as well.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Matti Aarnio]

On Thu, Sep 06, 2001 at 01:39:48PM -0400, Wietse Venema wrote:
> Andrey Savochkin:
> > > That is not practical. Surely there is an API to find out if an IP
> > > address connects to the machine itself. If every UNIX system on
> > > this planet can do it, then surely Linux can do it.
> > 
> > Let me correct you: you need to recognize not addresses that result in
> > connecting to the _machine_ itself, but connecting to the same _MTA_.
> 
> The SMTP RFC requires that user@[ip.address] is correctly recognized
> as a final destination.  This requires that Linux provides the MTA
> with information about IP addresses that correspond with INADDR_ANY.

	[ This is one of (at least) three different things that
	  have been mentioned in this thread, but lets limit
	  into only this one thing in this email ...  ]


	Why that needs a list of all addresses in the system ?

	Reception can query with standard BSD API what is
	the local address of the socket _at_the_moment_ at
	receiving side.  (  getsockname()  )

	Is there, really, any reason to detect locally anything else ?
	At the receiver all you do is to detect that the IP address
	literal matches the incoming connection, and you strip away
	the literal.


	Of course if the connection is coming in via some NAT box
	somewhere causing your SMTP server to show up with other
	address than what it knows about itself, things get complicated,
	and no matter of what you code into automagic self-address
	detection, you won't get that case solved with it.


> I am susprised that it is not possible to ask such information up
> front (same with netmasks), and that an application has to actually
> query a complex oracle, again and again, for every IP address.

	Of course it can be asked for, and ZMailer does it all
	the time when it considers contacting remote servers.
	If IP address of the remote server appears to be any
	of the local ones (or an invalidone), the message gets
	rejected with "a configuration error detected, this
	must be looping"...

> 	Wietse

/Matti Aarnio

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

Matti,

On Thu, Sep 06, 2001 at 11:51:57PM +0300, Matti Aarnio wrote:
> On Thu, Sep 06, 2001 at 01:39:48PM -0400, Wietse Venema wrote:
> > Andrey Savochkin:
> > > > That is not practical. Surely there is an API to find out if an IP
> > > > address connects to the machine itself. If every UNIX system on
> > > > this planet can do it, then surely Linux can do it.
> > > 
> > > Let me correct you: you need to recognize not addresses that result in
> > > connecting to the _machine_ itself, but connecting to the same _MTA_.
> > 
> > The SMTP RFC requires that user@[ip.address] is correctly recognized
> > as a final destination.  This requires that Linux provides the MTA
> > with information about IP addresses that correspond with INADDR_ANY.
> 
> 	[ This is one of (at least) three different things that
> 	  have been mentioned in this thread, but lets limit
> 	  into only this one thing in this email ...  ]
> 
> 	Why that needs a list of all addresses in the system ?
> 
> 	Reception can query with standard BSD API what is
> 	the local address of the socket _at_the_moment_ at
> 	receiving side.  (  getsockname()  )
> 
> 	Is there, really, any reason to detect locally anything else ?

The question is about what to do if you got a message to root@[10.0.0.1]
through a socket with local address (getsockname()) being 192.193.194.165.
If the local address is 10.0.0.1 also, there is no problem, the message is
clearly for your MTA.

Technically, Andi proposed to do route lookup at the moment of receiving the
message to check if it's local.
It provides a very close approximation to whether the address is "local" from
the point of view of networking engine.
But I'm not convinced that it's what you really want and need to check.

[snip]
> 
> > I am susprised that it is not possible to ask such information up
> > front (same with netmasks), and that an application has to actually
> > query a complex oracle, again and again, for every IP address.
> 
> 	Of course it can be asked for, and ZMailer does it all
> 	the time when it considers contacting remote servers.
> 	If IP address of the remote server appears to be any
> 	of the local ones (or an invalidone), the message gets
> 	rejected with "a configuration error detected, this
> 	must be looping"...

Right.
But how do you check for the destination IP being in the "local ones"?
Will I get this error if I type a message to root@[127.0.0.2] in a telnet
session to your MTA with 127.0.0.3 source address?
BTW, does ZMailer listen on INADDR_ANY by default?

There are different acceptable solutions.
If the message is delivered to root in the above example, it may be ok.
If I get an error, some people may agree to live with that, not sure about
Wietse :-)
Peter told us how he checked for local addresses in autofs, and that's what
may be done at the sending time in MTAs.
Alternatively, you may connect to port 25 on the target and by some "magic"
way determine that you talk to yourself.
But again I'm unsure if that's what you want and need to check.

The absolutely error-prone solution would be to listen on one specific IP
address and handle this address and only it as local in destinations.
That's how mail works on my own system now :-)
But it isn't very flexible.

My suggestion was to allow the administrator to list "local" IP addresses in
the configuration file, for example, in terms of prefixes, like 127.0.0.0/8
and 192.193.194.165/32.  It's a policy not technical decision, anyway.
If the MTA listens on INADDR_ANY, you should list all addresses connection to
which lead to socket lookup on this system, i.e. all "local" addresses from
the networking configuration's point of view.
If the MTA listens on specific addresses, list them.
The configuration file syntax may be optimized whatever way you want, but the
idea is clear.

The advantages are:
 1. MTA never makes mistakes in what addresses to consider as "local"
 2. you can have several different MTA on the same system
 3. you can have policies which addresses to accept connections on, and it
    won't cause any problems in mail delivery.

Best regards
		Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Matthias Andree]

On Fri, 07 Sep 2001, Andrey Savochkin wrote:

> > 	[ This is one of (at least) three different things that
> > 	  have been mentioned in this thread, but lets limit
> > 	  into only this one thing in this email ...  ]
> > 
> > 	Why that needs a list of all addresses in the system ?
> > 
> > 	Reception can query with standard BSD API what is
> > 	the local address of the socket _at_the_moment_ at
> > 	receiving side.  (  getsockname()  )
> > 
> > 	Is there, really, any reason to detect locally anything else ?
> 
> The question is about what to do if you got a message to root@[10.0.0.1]
> through a socket with local address (getsockname()) being 192.193.194.165.
> If the local address is 10.0.0.1 also, there is no problem, the message is
> clearly for your MTA.

Stop this pointless loop detection discussion, or take it off list and
me of the Cc: please.

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Mike Jagdis]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

Wietse Venema wrote:
> The SMTP RFC requires that user@[ip.address] is correctly recognized
> as a final destination.  This requires that Linux provides the MTA
> with information about IP addresses that correspond with INADDR_ANY.
> 
> I am susprised that it is not possible to ask such information up
> front (same with netmasks), and that an application has to actually
> query a complex oracle, again and again, for every IP address.

If I understand correctly you want to get a full list of addresses
and netmasks that have been assigned to interfaces?

   Use netlink. I'm sure someone else has said that but I haven't
read the entire thread, just scanned for the almost certainly
required example attachment (netlink is only straight forward once
you have an example :-( ). Attached is something that simply
asks for the current addresses (and "aliases"). It should be fairly
easy to use.

   The advantage with netlink is that you can just add the socket to
your select/poll list and listen for address changes as they happen
(useful for DHCP clients, maybe fail over scenarios etc.?). This code
doesn't do that. But if you add "while (1) netlink_read(s);" at the
bottom it will merrily report address changes - probably while sucking
CPU time, I suddenly have the feeling I left the set non-blocking
line in there!

				Mike
P.S. It's IPv4. Adding IPv6 is left as an exercise for the reader :-)

[-- Attachment #2: netlink.c --]
[-- Type: text/plain, Size: 4184 bytes --]

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/syslog.h>
#include <sys/time.h>
#include <sys/uio.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>
#include <errno.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <asm/types.h>
#include <linux/rtnetlink.h>


static int netlink_seq = 0;


static void
netlink_parse_rtattr(struct rtattr **tb, int max, struct rtattr *rta, int len)
{
	while (RTA_OK(rta, len)) {
		if (rta->rta_type <= max)
			tb[rta->rta_type] = rta;
		rta = RTA_NEXT(rta,len);
	}
}


static int
netlink_ifaddr(struct sockaddr_nl *snl, struct nlmsghdr *h)
{
	int len;
	struct ifaddrmsg *ifa;
	struct rtattr *tb[IFA_MAX + 1];
	struct in_addr *addr = NULL;

	ifa = NLMSG_DATA(h);

	len = h->nlmsg_len - NLMSG_LENGTH(sizeof(struct ifaddrmsg));
	if (len < 0)
		return -1;

	memset(tb, '\0', sizeof(tb));
	netlink_parse_rtattr(tb, IFA_MAX, IFA_RTA(ifa), len);

	if (tb[IFA_LOCAL])
		addr = RTA_DATA(tb[IFA_LOCAL]);
  	else if (tb[IFA_ADDRESS])
    		addr = RTA_DATA(tb[IFA_ADDRESS]);
	else
		return -1;

	fprintf(stderr,
		"Netlink %s: iface index %d, IPv4 address: %s/%d\n",
		h->nlmsg_type == RTM_NEWADDR ? "add" : "del",
		ifa->ifa_index, inet_ntoa(*addr), ifa->ifa_prefixlen);
	return 0;
}


int
netlink_open()
{
	int s;
	struct sockaddr_nl snl;

	s = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
	if (s < 0) {
		fprintf(stderr, "Can't open netlink socket: %s\n", strerror(errno));
		return -1;
	}

	fcntl(s, F_SETFL, O_NONBLOCK);
  
	memset(&snl, '\0', sizeof(snl));
	snl.nl_family = AF_NETLINK;
	snl.nl_groups = RTMGRP_IPV4_IFADDR;
  
	if (bind(s, (struct sockaddr *)&snl, sizeof(snl)) < 0) {
		fprintf(stderr, "Can't bind netlink socket: %s\n", strerror(errno));
		close(s);
		return -1;
	}

	return s;
}


int
netlink_request(int s, int family, int type)
{
	struct sockaddr_nl snl;

	struct {
		struct nlmsghdr nlh;
		struct rtgenmsg g;
	} req;

	memset(&snl, '\0', sizeof(snl));
	snl.nl_family = AF_NETLINK;

	req.nlh.nlmsg_len = sizeof(req);
	req.nlh.nlmsg_type = type;
	req.nlh.nlmsg_flags = NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST;
	req.nlh.nlmsg_pid = 0;
	req.nlh.nlmsg_seq = ++netlink_seq;
	req.g.rtgen_family = family;
  
	if (sendto(s, (void *)&req, sizeof(req), 0, 
		(struct sockaddr *)&snl, sizeof(snl)) < 0)
	{
		fprintf(stderr, "netlink sendto failed: %s\n", strerror (errno));
		return -1;
	}

	return 0;
}


int
netlink_read(int s)
{
	int status;
	int seq = 0;

	while (1) {
		char buf[4096];
		struct iovec iov = { buf, sizeof(buf) };
		struct sockaddr_nl snl;
		struct msghdr msg = {
			(void *)&snl, sizeof(snl), &iov, 1, NULL, 0, 0
		};
		struct nlmsghdr *h;

		status = recvmsg(s, &msg, 0);
		if (status < 0) {
			if (errno == EINTR)
				continue;
			if (errno == EWOULDBLOCK)
				return 0;
			fprintf(stderr, "netlink recvmsg: %s\n", strerror(errno));
	  		continue;
		}

		if (status == 0) {
			fprintf(stderr, "netlink EOF\n");
			return -1;
		}

		if (msg.msg_namelen != sizeof(snl)) {
			fprintf(stderr, "netlink length error: %d != %d\n",
				msg.msg_namelen, sizeof(snl));
			return -1;
		}

		for (h = (struct nlmsghdr *) buf;
			NLMSG_OK(h, status); 
			h = NLMSG_NEXT(h, status))
		{
			seq = h->nlmsg_seq;
			if (h->nlmsg_type == NLMSG_DONE)
				return 0;

			if (h->nlmsg_type == NLMSG_ERROR) {
				struct nlmsgerr *err = (struct nlmsgerr *)NLMSG_DATA(h);
				if (h->nlmsg_len < NLMSG_LENGTH(sizeof(struct nlmsgerr)))
					fprintf(stderr, "netlink: message truncated\n");
				else
					fprintf(stderr, "netlink: %s\n", strerror(-err->error));
				return -1;
			}

			switch (h->nlmsg_type) {
				case RTM_NEWADDR:
				case RTM_DELADDR:
					netlink_ifaddr(&snl, h);
					break;
			}
		}

		if (msg.msg_flags & MSG_TRUNC) {
			fprintf(stderr, "netlink: message truncated\n");
			continue;
		}

		if (status) {
			fprintf(stderr, "netlink: excess data, size %d\n", status);
			return -1;
		}

		/* This message is in reply to a user request. */
		if (seq == 0)
			return 0;
	}

	return 0;
}


int
main(int argc, char *argv[])
{
	int s;

	s = netlink_open();
	if (s >= 0) {
		netlink_request(s, AF_INET, RTM_GETADDR);
		netlink_read(s);
	}
}

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Matthias Andree]

On Fri, 07 Sep 2001, Mike Jagdis wrote:

> If I understand correctly you want to get a full list of addresses
> and netmasks that have been assigned to interfaces?
> 
>   Use netlink. I'm sure someone else has said that but I haven't
> read the entire thread, just scanned for the almost certainly
> required example attachment (netlink is only straight forward once
> you have an example :-( ). Attached is something that simply
> asks for the current addresses (and "aliases"). It should be fairly
> easy to use.

Whoa. 215 lines for just getting addresses.

No personal offense, but what do people think this is if not bloat?

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Kurt Roeckx]

On Thu, Sep 06, 2001 at 01:39:48PM -0400, Wietse Venema wrote:
> Andrey Savochkin:
> > > That is not practical. Surely there is an API to find out if an IP
> > > address connects to the machine itself. If every UNIX system on
> > > this planet can do it, then surely Linux can do it.
> > 
> > Let me correct you: you need to recognize not addresses that result in
> > connecting to the _machine_ itself, but connecting to the same _MTA_.
> 
> The SMTP RFC requires that user@[ip.address] is correctly recognized
> as a final destination.  This requires that Linux provides the MTA
> with information about IP addresses that correspond with INADDR_ANY.

I see no such thing in the RFC.  What I do see is that you're
allow to use the [IP address] notation.  It can't see where it
says that if that IP address is an IP address of the local host,
that it should accept it as the final destination.

I can perfectly imagine that the same hosts runs serveral MTAs,
on different IP addresses, and that both might have the same
username, but it's for a different person.

If an MTA doesn't listen to INADDR_ANY, why should it need to
know all addresses that might correspond to it?  That shouldn't
mean that if it does listen to INADDR_ANY, it should know them
all, but that could be something an MTA might want to do.
Like Andrey says, it needs to go to the same MTA.

If for some reason it was needed to use the IP address in the
destination, it's very likely that when it reaches the final
host, it will be a connection to that IP address.  Atleast, seen
from the connecting host.  If it's using NAT, maybe there should
be some option to tell it to accept that IP address as a final
destination too.


Kurt

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

[Kai Henningsen]

saw@saw.sw.com.sg (Andrey Savochkin)  wrote on 07.09.01 in <20010907112935.A26353@castle.nmd.msu.ru>:

[MTA]

> But how do you check for the destination IP being in the "local ones"?

Exim does it like this (approximately):

1. There is a list of domains considered "local".

2. There is an option that means the list will automatically contain the  
local hostname

3. There is another option that says the list will automatically include  
the [] notion of local interface addresses, as determined the usual way

4. The admin can add to that list anything (s)he wants.

(Note: 2 and 3 are both optional!)

As for netmasks: just use netmask notation when configuring how to treat  
hosts (such as who to allow relaying for). The probability that looking at  
the local network interfaces gives the right answer is close to zero.

MfG Kai

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[H. Peter Anvin]

Followup to:  <20010906155811.BC78DBC06C@spike.porcupine.org>
By author:    wietse@porcupine.org (Wietse Venema)
In newsgroup: linux.dev.kernel
>
> Andrey Savochkin:
> > Of course, SIOCGIFCONF isn't even close to provide the list of local
> > addresses.
> > Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> > on common systems.  If you handle 127.0.0.2 as local, you apply side
> 
> 127.0.0.2 is not local on any of my systems. The only exceptions
> are some Linux boxen that I did not ask to do so.
> 

The RFCs declare that 127.0.0.0/8 is all local.  If what you write is
true, all your systems are noncompliant.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Matthias Andree]

On Thu, 06 Sep 2001, Andrey Savochkin wrote:

> Of course, SIOCGIFCONF isn't even close to provide the list of local
> addresses.
> Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> on common systems.  If you handle 127.0.0.2 as local, you apply side
> knowledge about properties of loopback interface.

Well, 127.0.0.2 isn't a local address on my systems. It happens to pong
if you ping, but that's a matter of its netmask (/255.0.0.0) and the
"bounce all traffic" feature.

> Less obvious example: routes added to `local' table.
> SIOCGIFCONF can never show them.

We're not talking about routes and rules, we're still talking about
network addresses and the corresponding subnet masks. Don't digress to
complicate things.

> On Thu, Sep 06, 2001 at 04:17:49PM +0200, Matthias Andree wrote:
> > I'm not sure where and why you deduce the idea this is about MTA loop
> > detection or peer recognition.
> 
> All other reasons are absolutely artificial.

Well, Postfix itself uses netmasks to obtain DEFAULT values. You can
override these, so there is absolutely no point in discussing this.

> > Or just use IPADDR_ANY...
> 
> If the mailer's socket is bound to IPADDR_ANY, it's hard to find which
> connection attempts will be handled locally, so the best way to handle it is
> to ask the admin.

The MTA is to handle every connection attempt, and it is to make other
decisions based on whether the /peer/ is on a direct link or is routed.
There's absolutely no point in making decisions based on the local
address the client connected to.

> The language of that section is amazing:
>          An SMTP MUST accept and recognize a domain literal for any of
> 	 its own IP addresses.
> What might be ``own IP addresses'' of ``an SMTP''?..
> Does SMTP server have ``own IP addresses'' at all?

Please stop these harassments. We're talking about broken or
non-portable SIOCGIFNETMASK behaviour and not ranting about anything
else, particularly not about Internet Standards.

-- 
Matthias Andree

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

On Thu, Sep 06, 2001 at 06:01:30PM +0200, Matthias Andree wrote:
> On Thu, 06 Sep 2001, Andrey Savochkin wrote:
> 
> > Of course, SIOCGIFCONF isn't even close to provide the list of local
> > addresses.
> > Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> > on common systems.  If you handle 127.0.0.2 as local, you apply side
> > knowledge about properties of loopback interface.
> 
> Well, 127.0.0.2 isn't a local address on my systems. It happens to pong
> if you ping, but that's a matter of its netmask (/255.0.0.0) and the
> "bounce all traffic" feature.

Hell, how else could you define the notion of a local address as not the
address which responds to pings without external network, the address for
which
	telnet 127.0.0.2 25
will give you the greeting of your MTA if you happen to have it listening on
INADDR_ANY and so on?
It _is_ local, and there are no other IP address being "less" local than
127.0.0.2.
All 127.0.0.0/8 addresses are local to the same extent.

> > Less obvious example: routes added to `local' table.
> > SIOCGIFCONF can never show them.
> 
> We're not talking about routes and rules, we're still talking about
> network addresses and the corresponding subnet masks. Don't digress to
> complicate things.

You are missing my point.
Local addresses do not exist at all, there are no such entity in the physical
world.
The only thing that exists is rules.
The rules defining how packets are processed.
According to the rules, some packets are handled locally, i.e. for them a
socket lookup is performed, the host answers by ICMP and so on.
If a class of packets with the same destination IP address is handled locally
independently of other circumstances such as source address, incoming
interface and so on, that destination IP address is the first approximation
to what may be called "local IP address".
But I couldn't help to repeat myself: those IP addresses do not exist as
objects, there are no data structures representing local IP addresses, and so
on, the property of being local is just a conclusion from the rules.
Packet handling rules (represented in FIB rules, FIB info structures and
netfilter data structures) are the only real universe.

> > On Thu, Sep 06, 2001 at 04:17:49PM +0200, Matthias Andree wrote:
> > > I'm not sure where and why you deduce the idea this is about MTA loop
> > > detection or peer recognition.
> > 
> > All other reasons are absolutely artificial.
> 
> Well, Postfix itself uses netmasks to obtain DEFAULT values. You can
> override these, so there is absolutely no point in discussing this.

My point is that you use wrong terms to represent any security policy.

> > The language of that section is amazing:
> >          An SMTP MUST accept and recognize a domain literal for any of
> > 	 its own IP addresses.
> > What might be ``own IP addresses'' of ``an SMTP''?..
> > Does SMTP server have ``own IP addresses'' at all?
> 
> Please stop these harassments. We're talking about broken or
> non-portable SIOCGIFNETMASK behaviour and not ranting about anything
> else, particularly not about Internet Standards.

What Andi was thinking about and I continued is to bring the question whether
you looked for what you wanted and needed.

It looks like you're looking for a non-existing thing.
I still don't understand what you expect to get from SIOCGIFNETMASK if there
are multiple address/mask pairs with different masks.
I don't understand why you want to prevent mail loops and handle mail
destined to user@[127.0.0.1] and don't want even to prevent loops on
[127.0.0.2].

My advice is to re-consider your terms.
If I were involved in the development of postfix or a similar system, I would
immediately drop attempts to auto-configure local addresses and remove
"local networks" as a way to express access policy.

Being realistic, I consider the chances of you following my advice as very
low.  However, I hope that you at least understand my points and realize that
you have serious terminology problems in this area in general, and
the results of your SIOCG* calls do not have real-world sense, at least on
Linux.  SIOCG* calls just show what was previously set by SIOCS* calls, and
it has little to do with the real world, network configuration, packet
handling and so on.

	Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Wietse Venema]

Andrey Savochkin:
> You are missing my point.
> Local addresses do not exist at all, there are no such entity in the physical
> world.

Allow me to be the first to welcome you to the real world. Welcome!

An SMTP MTA is required to correctly recognize user@[ip.address]
as local.  That's the rules, like it or not. These address forms
are actually being used, like it or not.

It also is desirable for an MTA to treat clients on local subnets
different than strangers that happen to be on the same class A,
like it or not.  Failure to do so can make one end up on black
lists, like it or not.

So, I repeat my request for *constructive* contributions on how to
deal with these issues on Linux, when everything already works
correctly for all other Postfix-supported systems, like it or not.

	Wietse

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Charles Cazabon]

Wietse Venema <wietse@porcupine.org> wrote:
> 
> An SMTP MTA is required to correctly recognize user@[ip.address]
> as local.  That's the rules, like it or not. These address forms
> are actually being used, like it or not.

Yes.  MTAs have to work around this; qmail does a reasonable job.  Why
not look at how djb does this?  See ipme.c.
 
> It also is desirable for an MTA to treat clients on local subnets
> different than strangers that happen to be on the same class A,
> like it or not.  Failure to do so can make one end up on black
> lists, like it or not.

Having an MTA automatically treat clients on "local subnets" differently
than the rest of the 'net at large is definitely _not_ desirable.  The
administrator should have to explicitly configure the MTA to grant
additional access to every subnet he desires; anything else is begging
for trouble in the form of absued relaying privileges.
 
Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Alex Bligh - linux-kernel]

Andrey,

--On Thursday, September 06, 2001 8:38 PM +0400 Andrey Savochkin 
<saw@saw.sw.com.sg> wrote:

> Hell, how else could you define the notion of a local address as not the
> address which responds to pings without external network, the address for
> which

So the remote end of a looped /30 serial line is now a local address?
Can you bind() to 127.0.0.2? In any case, all you've found is a
peculiarity of the loopback driver. So send a patch.

The read RFC1122. (hosts & routers requirements).
Not only does this define local address, but specifically writes:

         3.3.4.2  Multihoming Requirements

            The following general rules apply to the selection of an IP
            source address for sending a datagram from a multihomed
            host.

            (1)  If the datagram is sent in response to a received
                 datagram, the source address for the response SHOULD be
                 the specific-destination address of the request.  See
                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
                 section of [INTRO:1] for more specific requirements on
                 higher layers.

                 Otherwise, a source address must be selected.

            (2)  An application MUST be able to explicitly specify the
                 source address for initiating a connection or a
                 request.

How can (2) be usefully true if the application cannot determine
what the list of valid local addresses are? Or is your argument
that all such addresses should be configured manually, rather
than by the application? Which would not only be a rather
odd point of view, but makes implementing things like
BGP, which depends on being able to get the outbound interface
address used for a session up to the higher layers, rather hard.

--
Alex Bligh

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[Andrey Savochkin]

Alex,

On Thu, Sep 06, 2001 at 06:05:30PM +0100, Alex Bligh - linux-kernel wrote:
> 
> --On Thursday, September 06, 2001 8:38 PM +0400 Andrey Savochkin 
> <saw@saw.sw.com.sg> wrote:
> 
> > Hell, how else could you define the notion of a local address as not the
> > address which responds to pings without external network, the address for
> > which
> 
> So the remote end of a looped /30 serial line is now a local address?

If it's looped, i.e. the remote end is plugged in my own port, its address is
local, isn't it?
In any case, such a serial line, or an Ethernet cable

> Can you bind() to 127.0.0.2? In any case, all you've found is a

Of course, anyone can bind, why not?

> peculiarity of the loopback driver. So send a patch.

It's not a peculiarity, it's a regular case.
127.0.0.0/8 is a local network.
If the other entry in the local routing table says `192.168.1.217/32',
it just happens to be /32, not any other prefix length.

And what should I patch?  Postfix?

>             (2)  An application MUST be able to explicitly specify the
>                  source address for initiating a connection or a
>                  request.
> 
> How can (2) be usefully true if the application cannot determine
> what the list of valid local addresses are? Or is your argument
> that all such addresses should be configured manually, rather
> than by the application? Which would not only be a rather
> odd point of view, but makes implementing things like
> BGP, which depends on being able to get the outbound interface
> address used for a session up to the higher layers, rather hard.
[snip]

If the application doesn't know which address to bind to, or it doesn't
matter, it uses INADDR_ANY.
If it matters, user specifies one.
Application may also use the same address as the address of incoming TCP
connection.  That's fine.

For really odd cases, like with routing daemons, application has knowledge
about the routing or may bind to interface (not address), but it's not for
regular use.

	Andrey

Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19]

[kuznet]

Hello!

> Of course, SIOCGIFCONF isn't even close to provide the list of local
> addresses.

Nobody prohibited for example to load netfilter module, which
will accept _all_ the packets to port 6666 as destined locally. :-)

However, the statement is wrong: SIOCGIFCONF really returns
all the addresses which are local "officially". If MTA
fails to deliver mail to "unofficial" address, it is problem
of adminstrator, which either should not create such addresses
or use proper MTA, which has enough reach set of rules, controlling
delivery, sendmail, for example. 

Alexey

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Alan Cox]

> > > Even if it checked the address it would not be unique because you can have multiple
> > > interfaces with the same addresses but different netmasks.
> 
> The same IP address with different netmasks on the same hardware
> interface? The mind boggles. How does one handle broadcasts?

Same as before. You have two for a single IP address/netmask
(255.255.255.255 and the local one). You have another per address/mask pair
you add.

The application supplies a target broadcast address so there isnt any real
problem

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

On Thu, 06 Sep 2001, Andrey Savochkin wrote:

> Andi, it's right to the point.

It's false.

> The only one good reason for an SMTP server to bother about IP addresses at
> all is a quick check for mail loops, i.e. a check at the moment of opening
> TCP connection to send a message whether your peer is yourself.
> Bothering about network masks just doesn't have any valid grounds.
> It's not possible to answer the right question (whether you talk to yourself)
> inspecting IP addresses.
> In the original example, mail systems on 192.168.0.4 and 192.168.1.1 may be
> different.

I'm not sure where and why you deduce the idea this is about MTA loop
detection or peer recognition.

Any application that uses SIOCGIFNETMASK would do, it just happened that
Postfix's inet_addr_local was the tool I used when I found out the
sysctl had returned the first netmask for the second address on Linux,
but not on FreeBSD.

> So, the very right way of doing things is:
>  - make admin specify the listening addresses for a mail system in the
>    configuration and use them to check for loops;

Or just use IPADDR_ANY...

>  - never try to learn anything about networking configuration.

...which is wrong, because the MTA must know its own IP addresses to
accept domain literals, and SIOCGIFCONF works and returns all addresses,
it just happens that looking up the second and subsequent masks fails.
Please see RFC-1123, section 5.2.17, for details.

-- 
Matthias Andree

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Kai Henningsen]

matthias.andree@gmx.de (Matthias Andree)  wrote on 06.09.01 in <20010906151113.A29583@maggie.dt.e-technik.uni-dortmund.de>:

> Well, Postfix used to look at the addresses and deduce the network class
> for that,

The WHAT?!

Classes have been dead since around 1993!

> but there have been many complaints by people that this would
> get subnets wrong. A couple of months ago, Postfix has started to look
> up the netmasks as well.

Modern software trying to work with classes should not allowed on the  
Internet; people who don't know this should not allowed to write network  
software.


MfG Kai

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

Kai Henningsen schrieb am Samstag, den 08. September 2001:

[old Postfix versions consider network classes]
> The WHAT?!
> 
> Classes have been dead since around 1993!

In case you missed that from the paragraph below that you quoted,
Postfix tries to look up the netmasks from the interfaces nowadays - and
stumbles across incompatibilities that are the reason for this thread.
You can always manually override this configuration.

> > but there have been many complaints by people that this would
> > get subnets wrong. A couple of months ago, Postfix has started to look
> > up the netmasks as well.

-- 
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin  dont_click_this_virus.exe
end

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Sam Varshavchik]

Alan Cox writes: 

>> > how everyone did it but they guys with the "newfangled, really not how it
>> > should be done, definitely not cricket"  machine guns got the last laugh 
>> 
>> Keep your superiority complex out of my mailbox, thank you.
> 
> What is it about so many mail system authors and lacking sense of humour. 

I resemble that remark in the most strongest terms possible.  I have you 
know that I am very well known for my easy-going nature, and friendly 
attitude.  So there. 

-- 
Sam 

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[jamal]

Andi, Alexey,

Whats wrong with this patch (just a thought, not tested or even compiled)?

---------------------------------------
--- devinet.c   2001/09/04 19:18:51     1.1
+++ devinet.c   2001/09/04 19:31:13
@@ -530,7 +530,7 @@

        if ((in_dev=__in_dev_get(dev)) != NULL) {
                for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL;
ifap=&ifa->ifa_next)
-                       if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0)
+                       if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) ||
(sin->sin_addr.s_addr == ifa->ifa_address))
                                break;
        }
--------------------------------

cheers,
jamal

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[kuznet]

Hello!

> Whats wrong with this patch (just a thought, not tested or even compiled)?

Wrong is that it stops to work if you do not fill ifr_data.
This field in write only in 4.3BSD and in Linux.

Alexey

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

On Wed, 05 Sep 2001, jamal wrote:

> --- devinet.c   2001/09/04 19:18:51     1.1
> +++ devinet.c   2001/09/04 19:31:13
> @@ -530,7 +530,7 @@
> 
>         if ((in_dev=__in_dev_get(dev)) != NULL) {
>                 for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL;
> ifap=&ifa->ifa_next)
> -                       if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0)
> +                       if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) ||
> (sin->sin_addr.s_addr == ifa->ifa_address))
>                                 break;
>         }

Thanks for trying to help, however, that's not going to work this way, sorry.

1. "sin" is cleared a few lines above, so you end up comparing 0.0.0.0
   against "ifa->ifa_address".

2. two interfaces can have the same configured address, your patch might
   end up returning the wrong address. You'd need to write && where you
   wrote ||, and you'd need to save the old address.

See the patch that I sent.

-- 
Matthias Andree

ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

-----BEGIN PGP SIGNED MESSAGE-----

Dear network experts, dear lurkers,

Wietse Venema and I are wondering about different Linux 2.2/2.4 and
FreeBSD 4.4-RC behaviour when using ioctls to figure interface netmasks,
FreeBSD gets it right, Linux 2.4.9 and 2.4.9-ac7 get it wrong, and from
looking at the source, I think, Linux 2.2.19 gets it wrong as well.

Please Cc: replies back, I'm not on the -net list, and I'm not sure if
Wietse is on either list.

In either case, inet_addr_local, which Postfix uses to figure local
address/netmask pairs, does this:

1. obtain SIOCGIFCONF list
2. for each AF_INET entry in the list from (1.), do:
   2.1 pull out the address from ifr and store it away
   2.2 copy the whole request to an ifr_mask structure
   2.3 ioctl(somesocket, SIOCGIFNETMASK, ifr_mask)
   2.4 pull out the mask and store it away

Example:

FreeBSD 4.4-RC:

# ifconfig xl0 alias 192.168.1.1/28    # add alias
# ifconfig xl0                         # display, only relevant part quoted
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.1.1 netmask 0xfffffff0 broadcast 192.168.1.15
# ./inet_addr_local # what Postfix figures
192.168.0.4/255.255.255.0
192.168.1.1/255.255.255.240
127.0.0.1/255.0.0.0

- -> works.

Linux: 

# ip addr add 192.168.1.1/28 dev eth0  # add alias without label eth0:0
# ip addr show dev eth0                # 
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:60:08:6f:8a:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
    inet 192.168.1.1/28 scope global eth0
# ./inet_addr_local
127.0.0.1/255.0.0.0
192.168.0.1/255.255.255.0
192.168.1.1/255.255.255.0

- -> oops, 192.168.1.1 got wrong netmask.

Digging with gdb on either platform, the interface name is xl0 for all
addresses on FreeBSD (no :0 or something) and eth0 on Linux (no :0 or
something). There is no platform-dependent code in inet_addr_local.

Looking at FreeBSD's Kernel source, FreeBSD iterates over the addresses:
/usr/src/sys/netinet/in.c, function in_control, ll. 189ff in my version,
comparing against ifr_addr.

Looking at Linux' Kernel source, Linux 2.4.9 compares just the ifr_name,
/usr/src/linux/net/ipv4/devinet.c, function devinet_ioctl, ll.  463 ff.
in 2.4.9, so Linux always returns the mask for the first address, not
the mask for the requested address. This doesn't matter as long as
eth0:0-style aliases are configured with ifconfig, but it does matter as
soon as ip comes into play and both addresses are assigned to eth0
rather than eth0 and eth0:0.




I believe this would require fixing for compatibility reasons, in the
sense that the address is also compared to figure the interface, but I'm
out of time now and cannot try anything before tomorrow, I'd happily
test patches sent by then.

Would net/ipv4/devinet.c be the only place to fix or are there other
places that do also need fixing?


Non-Postfix guys: Here's how to build inet_addr_local:

1. fetch /mirrors/postfix-release/official/postfix-20010228-pl04.tar.gz
   from ftp.porcupine.org
2. unpack the sources, then do:
   make Makefiles ; cd src/util ; make inet_addr_local
3. add an IP alias to any network (eth in my case), but let it have a
   different netmask than the primary address of the net.

Thanks a lot in advance!

Cheers,

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iQCVAwUBO5ZQgydEoB0mv1ypAQEzvAP+IMWRaKR+Bvzxbhd/fJCNR8oq//U06kP3
mg1KIoOKX3PBfNkxIZW4l+oTt9wxHAXHJUJ1W6w3T43xlBlcHi4Y70XNKqbyCFiB
n6l+q0JFHv+qV4pWxJCG1sz20nrwK/nUwf+5nxcGAdetPnPBXpndGtiX66nzNtka
NGO38uOvIuA=
=587q
-----END PGP SIGNATURE-----

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Christopher Friesen]

Matthias Andree wrote:

> Wietse Venema and I are wondering about different Linux 2.2/2.4 and
> FreeBSD 4.4-RC behaviour when using ioctls to figure interface netmasks,
> FreeBSD gets it right, Linux 2.4.9 and 2.4.9-ac7 get it wrong, and from
> looking at the source, I think, Linux 2.2.19 gets it wrong as well.

> Looking at Linux' Kernel source, Linux 2.4.9 compares just the ifr_name,
> /usr/src/linux/net/ipv4/devinet.c, function devinet_ioctl, ll.  463 ff.
> in 2.4.9, so Linux always returns the mask for the first address, not
> the mask for the requested address. This doesn't matter as long as
> eth0:0-style aliases are configured with ifconfig, but it does matter as
> soon as ip comes into play and both addresses are assigned to eth0
> rather than eth0 and eth0:0.


I think the silence you are hearing from the lkml is a bunch of people thinking
"Oh, crap!".

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Alan Cox]

> > the mask for the requested address. This doesn't matter as long as
> > eth0:0-style aliases are configured with ifconfig, but it does matter as
> > soon as ip comes into play and both addresses are assigned to eth0
> > rather than eth0 and eth0:0.
> 
> I think the silence you are hearing from the lkml is a bunch of people thinking
> "Oh, crap!".

Actually its probably a bunch of people thinking "I wonder if someone else
forwarded this to netdev@oss.sgi.com"

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Wietse Venema]

On a more serious note, what portable primitives does Linux offer
to look up all interface IP addresses and their corresponding
netmasks?

The primitives used in Postfix work on all supported systems, except
for Linux where they work partially.

Portability is a relative thing - it would be wonderful already if
your primitive supports the past three years of kernel releases.

	Wietse

Alan Cox:
> > > the mask for the requested address. This doesn't matter as long as
> > > eth0:0-style aliases are configured with ifconfig, but it does matter as
> > > soon as ip comes into play and both addresses are assigned to eth0
> > > rather than eth0 and eth0:0.
> > 
> > I think the silence you are hearing from the lkml is a bunch of people thinking
> > "Oh, crap!".
> 
> Actually its probably a bunch of people thinking "I wonder if someone else
> forwarded this to netdev@oss.sgi.com"
> 

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Andi Kleen]

[Sending a similar mail for the third time now; you conveniently chosed 
to ignore all earlier ones of me in the discussion. I will not send another
one, but just quietly think "Wietse is a moron" before forgetting the issue]

On Wed, Sep 05, 2001 at 05:23:26PM -0400, Wietse Venema wrote:
> On a more serious note, what portable primitives does Linux offer
> to look up all interface IP addresses and their corresponding
> netmasks?

man rtnetlink 7

> The primitives used in Postfix work on all supported systems, except
> for Linux where they work partially.
> 
> Portability is a relative thing - it would be wonderful already if
> your primitive supports the past three years of kernel releases.

It does (Since 2.1.x;x>=2x or so)

-Andi

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Wietse Venema]

Andi Kleen:
> [Sending a similar mail for the third time now; you conveniently chosed 
> to ignore all earlier ones of me in the discussion. I will not send another
> one, but just quietly think "Wietse is a moron" before forgetting the issue]

Oh, come on. I was asking for more than RTFM.

> On Wed, Sep 05, 2001 at 05:23:26PM -0400, Wietse Venema wrote:
> > On a more serious note, what portable primitives does Linux offer
> > to look up all interface IP addresses and their corresponding
> > netmasks?
> 
> man rtnetlink 7

It's not portable as you may believe.

    [root@redhat52 /root]# man rtnetlink
    No manual entry for rtnetlink

This was released only three years ago.

But it does not matter. The code needs to be written anyway.

Do you have more to share than RFTM? Pointers to code?

	Wietse

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Andi Kleen]

On Thu, Sep 06, 2001 at 02:51:24PM -0400, Wietse Venema wrote:
> > On Wed, Sep 05, 2001 at 05:23:26PM -0400, Wietse Venema wrote:
> > > On a more serious note, what portable primitives does Linux offer
> > > to look up all interface IP addresses and their corresponding
> > > netmasks?
> > 
> > man rtnetlink 7
> 
> It's not portable as you may believe.

The man pages are actually came years later than the code due to some accidents.
That doesn't change the existence of the code.

> 
>     [root@redhat52 /root]# man rtnetlink
>     No manual entry for rtnetlink
> 
> This was released only three years ago.
> 
> But it does not matter. The code needs to be written anyway.
> 
> Do you have more to share than RFTM? Pointers to code?

Most prominent example is iproute2. It should be included as source with any 
recent linux distribution. Others are zebra or bird.

-Andi

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Henning P. Schmiedehausen]

wietse@porcupine.org (Wietse Venema) writes:

>It's not portable as you may believe.

>    [root@redhat52 /root]# man rtnetlink
>    No manual entry for rtnetlink

% cd /home/distribution/RedHat-5.2/i386/
% ls -la kernel*
-r--r--r--    1 root     root      2216232 Oct 14  1998 kernel-2.0.36-0.7.i386.rpm
-r--r--r--    1 root     root       536848 Oct 14  1998 kernel-headers-2.0.36-0.7.i386.rpm
-r--r--r--    1 root     root        94694 Oct 14  1998 kernel-ibcs-2.0.36-0.7.i386.rpm
-r--r--r--    1 root     root       320370 Oct 14  1998 kernel-pcmcia-cs-2.0.36-0.7.i386.rpm
-r--r--r--    1 root     root      9625252 Oct 14  1998 kernel-source-2.0.36-0.7.i386.rpm

You don't _WANT_ to listen, do you? Andi told you many times, that
this is an Linux 2.1+ API. RH 5.2 is a 2.0 distribution. Of course,
there is no man page in it for this. It's almost three years
old. There are from this particular vendor, _FIVE_ newer distributions. 
What do you want to tell us? That you're living in the past?

Please stop constructing cases. Linux did move on slightly in the last
three years. Maybe some other OSes didn't.

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19

[Matthias Andree]

Henning P. Schmiedehausen schrieb am Freitag, den 07. September 2001:

> wietse@porcupine.org (Wietse Venema) writes:
> 
> % cd /home/distribution/RedHat-5.2/i386/
> % ls -la kernel*
> -r--r--r--    1 root     root      2216232 Oct 14  1998 kernel-2.0.36-0.7.i386.rpm

> You don't _WANT_ to listen, do you? Andi told you many times, that
> this is an Linux 2.1+ API. RH 5.2 is a 2.0 distribution. Of course,

So Postfix would still need the code for the -2.0 (BSD) API...