Is there any standard way of doing this? I looked into ipv4 code but I did
not find a function that would provide a direct, clean way to query the
local IPv4 addresses of a given node.
If this information is not available could we create an interface for it?
Any suggestions on the way to do it?
The interfaces provided to user-level applications do the copy to/from user
that I guess will not work with kernel modules...
Juan
Juan Gomez wrote :
>
> Is there any standard way of doing this? I looked into ipv4 code but I did
> not find a function that would provide a direct, clean way to query the
> local IPv4 addresses of a given node.
There is no such thing as the local IPv4 addresses of a given
node. IP addresses are assigned for each network interfaces, so you
may have more than one IP address. Note that I have many systems that
don't have any "eth0" and still have many IP addresses (on wlan0,
ppp0, bnep0...).
On top of that, the DNS may assign an IP address that map to
your current hostname (which may correspond to one of the addresses
above). That's purely a user space stuff.
So, you are basically starting on a wrong assumption, the
information you are looking for doesn't exist, and I therefore suspect
that you need to rethink the thing you want to do.
I suggest you use a user space application to pick the IP
address most relevant to your setup (i.e. policy decision) and inject
it in your module.
Good luck,
Jean
Jean,
I am aware of all this, however, my application will be happy to get any
IPv4 assigned to any of the local interfaces as far as you consistently
get the same on repeated calls.
I think there should be an interface to query this from within the kernel
so since I did not find it I am proposing to get one
or may be there is something hidden which I missed so I decided to ask
here.
Juan
|---------+---------------------------------->
| | Jean Tourrilhes |
| | <[email protected]>|
| | Sent by: |
| | linux-kernel-owner@vger|
| | .kernel.org |
| | |
| | |
| | 10/30/02 06:38 PM |
| | Please respond to jt |
| | |
|---------+---------------------------------->
>------------------------------------------------------------------------------------------------------------------|
| |
| To: Linux kernel mailing list <[email protected]> |
| cc: |
| Subject: Re: How to get a local IPv4 address from within a kernel module? |
| |
| |
>------------------------------------------------------------------------------------------------------------------|
Juan Gomez wrote :
>
> Is there any standard way of doing this? I looked into ipv4 code but I
did
> not find a function that would provide a direct, clean way to query the
> local IPv4 addresses of a given node.
There is no such thing as the local IPv4 addresses of a given
node. IP addresses are assigned for each network interfaces, so you
may have more than one IP address. Note that I have many systems that
don't have any "eth0" and still have many IP addresses (on wlan0,
ppp0, bnep0...).
On top of that, the DNS may assign an IP address that map to
your current hostname (which may correspond to one of the addresses
above). That's purely a user space stuff.
So, you are basically starting on a wrong assumption, the
information you are looking for doesn't exist, and I therefore suspect
that you need to rethink the thing you want to do.
I suggest you use a user space application to pick the IP
address most relevant to your setup (i.e. policy decision) and inject
it in your module.
Good luck,
Jean
Josh
That is the purpose of my orignal message. In fact I have implemented
somthing along the lines of what you suggest below and I just want to test
the waters on whether this will be accepted. My current implementation is a
little more specific as it only gets the interfaces with IPv4 enabled on
them and skip lo but the idea is to get a consensus on what would be
genrally useful and then introduce that.
Regards, Juan
|---------+----------------------------->
| | Josh Myer |
| | <[email protected]|
| | om> |
| | Sent by: Josh Myer|
| | <[email protected]|
| | sanerd.com> |
| | |
| | |
| | 10/31/02 10:01 AM |
| | |
|---------+----------------------------->
>------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: [email protected], <[email protected]> |
| Subject: Re: How to get a local IPv4 address from within a kernel module? |
| |
| |
>------------------------------------------------------------------------------------------------------------------|
In general, the only way a "get interface address" function would be
accepted into mainline is if it was Generally Useful.
In order for it to be Generally Useful, you'll want to make it able to
get any address of any interface. Otherwise it's useless cruft for one
specific purpose, which can't be used anywhere else.
I'd suggest a function to get a list of interfaces, and then a function to
get a list of addresses for a given interface. Then you could just grab
the first address of the first interface for your application. Don't
forget to take into account that interfaces can change address, go up and
down, disappear/reappear, and change actual hardware...
And even that isn't Generally Useful. In fact, what the hell it's good for
is left as an exercise for the reader (implementation, too).
Though if "any IPv4 on any interface" will do, just assume 127.0.0.1 on
lo. Anyone that changes that has sins to atone for, and finding kernel
quirks is appropriate penance.
Did we mention that you'd be best to get the address in userspace and pass
it into the module? That's really the best bet...
--
/jbm, but you can call me Josh. Really, you can!
"What's a metaphor?" "For sheep to graze in"
7958 1C1C 306A CDF8 4468 3EDE 1F93 F49D 5FA1 49C4
On Thu, 31 Oct 2002, Juan Gomez wrote:
>
>
>
>
>
> Jean,
>
> I am aware of all this, however, my application will be happy to get any
> IPv4 assigned to any of the local interfaces as far as you consistently
> get the same on repeated calls.
> I think there should be an interface to query this from within the kernel
> so since I did not find it I am proposing to get one
> or may be there is something hidden which I missed so I decided to ask
> here.
>
> Juan
>
>
>
>
> |---------+---------------------------------->
> | | Jean Tourrilhes |
> | | <[email protected]>|
> | | Sent by: |
> | | linux-kernel-owner@vger|
> | | .kernel.org |
> | | |
> | | |
> | | 10/30/02 06:38 PM |
> | | Please respond to jt |
> | | |
> |---------+---------------------------------->
>
>------------------------------------------------------------------------------------------------------------------|
> |
|
> | To: Linux kernel mailing list
<[email protected]> |
> | cc:
|
> | Subject: Re: How to get a local IPv4 address from within a
kernel module? |
> |
|
> |
|
>
>------------------------------------------------------------------------------------------------------------------|
>
>
>
> Juan Gomez wrote :
> >
> > Is there any standard way of doing this? I looked into ipv4 code but I
> did
> > not find a function that would provide a direct, clean way to query the
> > local IPv4 addresses of a given node.
>
> There is no such thing as the local IPv4 addresses of a
given
> node. IP addresses are assigned for each network interfaces, so you
> may have more than one IP address. Note that I have many systems that
> don't have any "eth0" and still have many IP addresses (on wlan0,
> ppp0, bnep0...).
> On top of that, the DNS may assign an IP address that map to
> your current hostname (which may correspond to one of the addresses
> above). That's purely a user space stuff.
>
> So, you are basically starting on a wrong assumption, the
> information you are looking for doesn't exist, and I therefore suspect
> that you need to rethink the thing you want to do.
>
> I suggest you use a user space application to pick the IP
> address most relevant to your setup (i.e. policy decision) and inject
> it in your module.
>
> Good luck,
>
> Jean
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
In general, the only way a "get interface address" function would be
accepted into mainline is if it was Generally Useful.
In order for it to be Generally Useful, you'll want to make it able to
get any address of any interface. Otherwise it's useless cruft for one
specific purpose, which can't be used anywhere else.
I'd suggest a function to get a list of interfaces, and then a function to
get a list of addresses for a given interface. Then you could just grab
the first address of the first interface for your application. Don't
forget to take into account that interfaces can change address, go up and
down, disappear/reappear, and change actual hardware...
And even that isn't Generally Useful. In fact, what the hell it's good for
is left as an exercise for the reader (implementation, too).
Though if "any IPv4 on any interface" will do, just assume 127.0.0.1 on
lo. Anyone that changes that has sins to atone for, and finding kernel
quirks is appropriate penance.
Did we mention that you'd be best to get the address in userspace and pass
it into the module? That's really the best bet...
--
/jbm, but you can call me Josh. Really, you can!
"What's a metaphor?" "For sheep to graze in"
7958 1C1C 306A CDF8 4468 3EDE 1F93 F49D 5FA1 49C4
On Thu, 31 Oct 2002, Juan Gomez wrote:
>
>
>
>
>
> Jean,
>
> I am aware of all this, however, my application will be happy to get any
> IPv4 assigned to any of the local interfaces as far as you consistently
> get the same on repeated calls.
> I think there should be an interface to query this from within the kernel
> so since I did not find it I am proposing to get one
> or may be there is something hidden which I missed so I decided to ask
> here.
>
> Juan
>
>
>
>
> |---------+---------------------------------->
> | | Jean Tourrilhes |
> | | <[email protected]>|
> | | Sent by: |
> | | linux-kernel-owner@vger|
> | | .kernel.org |
> | | |
> | | |
> | | 10/30/02 06:38 PM |
> | | Please respond to jt |
> | | |
> |---------+---------------------------------->
> >------------------------------------------------------------------------------------------------------------------|
> | |
> | To: Linux kernel mailing list <[email protected]> |
> | cc: |
> | Subject: Re: How to get a local IPv4 address from within a kernel module? |
> | |
> | |
> >------------------------------------------------------------------------------------------------------------------|
>
>
>
> Juan Gomez wrote :
> >
> > Is there any standard way of doing this? I looked into ipv4 code but I
> did
> > not find a function that would provide a direct, clean way to query the
> > local IPv4 addresses of a given node.
>
> There is no such thing as the local IPv4 addresses of a given
> node. IP addresses are assigned for each network interfaces, so you
> may have more than one IP address. Note that I have many systems that
> don't have any "eth0" and still have many IP addresses (on wlan0,
> ppp0, bnep0...).
> On top of that, the DNS may assign an IP address that map to
> your current hostname (which may correspond to one of the addresses
> above). That's purely a user space stuff.
>
> So, you are basically starting on a wrong assumption, the
> information you are looking for doesn't exist, and I therefore suspect
> that you need to rethink the thing you want to do.
>
> I suggest you use a user space application to pick the IP
> address most relevant to your setup (i.e. policy decision) and inject
> it in your module.
>
> Good luck,
>
> Jean
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Oct 31, 2002 at 10:09:54AM -0800, Juan Gomez wrote:
>
> Josh
>
> That is the purpose of my orignal message. In fact I have implemented
> somthing along the lines of what you suggest below and I just want to test
> the waters on whether this will be accepted. My current implementation is a
> little more specific as it only gets the interfaces with IPv4 enabled on
> them and skip lo but the idea is to get a consensus on what would be
> genrally useful and then introduce that.
>
> Regards, Juan
I personally think it's a very bad idea, because it will lead
to confusion. You will define a concept of "the node IP address",
which doesn't exist and is a very dangerous assumption.
Just take VPN, which is becoming very widespread. You have two
IP addresses, one on the interface, one on the tunnel. Which one do
you get ? Those two IP address will have widely different behaviour
and you can't exchange them.
My fear is that people will start coding around this API and
flawed concept, and most of their programs will be immediately flawed,
because incapable to adapt to the reality of networking (it will work
in the simple case, but give bizarre behavior in non simple cases).
Don't get me wrong, there is a small class of applications
where the IP address doesn't matter (and for those, 127.0.0.1 should
be fine). But, from my experience, the vast majority of people wanting
"the node IP address" have broken designs, i.e. it's not that they
want any one of them, it's that they assume that only one exist.
Now, there is only one thing that could qualify as "the node
IP address", this is the IP address associated with the hostname :
gethostbyname(hostname());
IMHO, if you define the interface you are proposing, it should
always return the result above, because this is a well defined
semantic and it is more useful.
But, I'm only one of the little guy here, so what I say
doesn't matter much. Ask Alan or DaveM.
Regards,
Jean
I think wht you propose below is exactly what I would like to have, my
problem is that implementing
gethostbyname(hostname()) within the kernel is not that easy as most of the
code that supports these calls is designed to be used from user-land
Let's hope some other people will also advise on this so I can combine
ideas and propose something that will likely be accepted.
Juan
|---------+---------------------------->
| | Jean Tourrilhes |
| | <[email protected]|
| | p.com> |
| | |
| | 10/31/02 10:30 AM|
| | Please respond to|
| | jt |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: Josh Myer <[email protected]>, [email protected], [email protected] |
| Subject: Re: How to get a local IPv4 address from within a kernel module? |
| |
| |
>------------------------------------------------------------------------------------------------------------------|
On Thu, Oct 31, 2002 at 10:09:54AM -0800, Juan Gomez wrote:
>
> Josh
>
> That is the purpose of my orignal message. In fact I have implemented
> somthing along the lines of what you suggest below and I just want to
test
> the waters on whether this will be accepted. My current implementation is
a
> little more specific as it only gets the interfaces with IPv4 enabled on
> them and skip lo but the idea is to get a consensus on what would be
> genrally useful and then introduce that.
>
> Regards, Juan
I personally think it's a very bad idea, because it will lead
to confusion. You will define a concept of "the node IP address",
which doesn't exist and is a very dangerous assumption.
Just take VPN, which is becoming very widespread. You have two
IP addresses, one on the interface, one on the tunnel. Which one do
you get ? Those two IP address will have widely different behaviour
and you can't exchange them.
My fear is that people will start coding around this API and
flawed concept, and most of their programs will be immediately flawed,
because incapable to adapt to the reality of networking (it will work
in the simple case, but give bizarre behavior in non simple cases).
Don't get me wrong, there is a small class of applications
where the IP address doesn't matter (and for those, 127.0.0.1 should
be fine). But, from my experience, the vast majority of people wanting
"the node IP address" have broken designs, i.e. it's not that they
want any one of them, it's that they assume that only one exist.
Now, there is only one thing that could qualify as "the node
IP address", this is the IP address associated with the hostname :
gethostbyname(hostname());
IMHO, if you define the interface you are proposing, it should
always return the result above, because this is a well defined
semantic and it is more useful.
But, I'm only one of the little guy here, so what I say
doesn't matter much. Ask Alan or DaveM.
Regards,
Jean
On Thursday 31 October 2002 12:30 pm, Jean Tourrilhes wrote:
> Now, there is only one thing that could qualify as "the node
> IP address", this is the IP address associated with the hostname :
> gethostbyname(hostname());
> IMHO, if you define the interface you are proposing, it should
> always return the result above, because this is a well defined
> semantic and it is more useful.
Ummmmm... not quite the right answer - gethostbyname(hostname());
doesn't even have to return an IP number.
I have an environment right now that would make that result
useless. It is equivalent to using the 127.0.0.1 loopback.
We have a cluster where the address assgned to the hostname
is a nonroutable address, used only for internal communication
with other nodes in a cluster. The only way to get a "proper"
internet address is to request DNS for the address. And then
you might get back 35 addresses (would get 330 if the library
function would work properly).
It is also possible that NONE of the interfaces are assigned the
same name as the local host name. One of our environments
identifies a node by a frame/node construct. Addressing is
totally independant.
This association is only a convention, and is not something
mandatory.
Even at home, my systems have two or three addreses.
<external IP> applied to the firewall for external use
192.168.1.x for a small wireless network
192.168.0.x for the internal network
<external IP> for a dummy network device to make Kerberos work
192.168.2.x for a cluster network (some experimental systems).
The firewall has the first three, my workstation has the third and
fourth, and my toy cluster has the third and last.
There is no "node" IP number. Especially if you have more
than one network device.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Thu, 31 Oct 2002, Jean Tourrilhes wrote:
> On Thu, Oct 31, 2002 at 10:09:54AM -0800, Juan Gomez wrote:
> >
> > Josh
> >
> > That is the purpose of my orignal message. In fact I have implemented
> > somthing along the lines of what you suggest below and I just want to test
> > the waters on whether this will be accepted. My current implementation is a
> > little more specific as it only gets the interfaces with IPv4 enabled on
> > them and skip lo but the idea is to get a consensus on what would be
> > genrally useful and then introduce that.
> >
> > Regards, Juan
>
> I personally think it's a very bad idea, because it will lead
> to confusion. You will define a concept of "the node IP address",
> which doesn't exist and is a very dangerous assumption.
> Just take VPN, which is becoming very widespread. You have two
> IP addresses, one on the interface, one on the tunnel. Which one do
> you get ? Those two IP address will have widely different behaviour
> and you can't exchange them.
> My fear is that people will start coding around this API and
> flawed concept, and most of their programs will be immediately flawed,
> because incapable to adapt to the reality of networking (it will work
> in the simple case, but give bizarre behavior in non simple cases).
> Don't get me wrong, there is a small class of applications
> where the IP address doesn't matter (and for those, 127.0.0.1 should
> be fine). But, from my experience, the vast majority of people wanting
> "the node IP address" have broken designs, i.e. it's not that they
> want any one of them, it's that they assume that only one exist.
>
> Now, there is only one thing that could qualify as "the node
> IP address", this is the IP address associated with the hostname :
> gethostbyname(hostname());
> IMHO, if you define the interface you are proposing, it should
> always return the result above, because this is a well defined
> semantic and it is more useful.
>
> But, I'm only one of the little guy here, so what I say
> doesn't matter much. Ask Alan or DaveM.
> Regards,
>
> Jean
> -
Also, many machines have many IP addresses, even when using the
same controller:
eth0 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.100.2.224 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8339427 errors:4 dropped:0 overruns:0 frame:4
TX packets:650046 errors:0 dropped:0 overruns:0 carrier:0
collisions:4954 txqueuelen:100
Interrupt:10 Base address:0xb800
eth0:1 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.106.100.167 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xb800
eth0:2 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.106.100.232 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xb800
eth0:3 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.106.100.233 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xb800
eth0:4 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.106.100.234 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xb800
eth0:5 Link encap:Ethernet HWaddr 00:50:DA:19:7A:7D
inet addr:10.106.100.235 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xb800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:19174 errors:0 dropped:0 overruns:0 frame:0
TX packets:19174 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America