Re: First line in /etc/hosts
On Feb 23, Junichi Uekawa [EMAIL PROTECTED] wrote: Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? No, packets /from/ locally configured addresses coming from external interfaces are always dropped no matter how rp_filter is configured. -- ciao, Marco signature.asc Description: Digital signature
Re: First line in /etc/hosts
On Wed, 23 Feb 2005, Paul Hampson wrote: On Sat, Feb 19, 2005 at 12:13:34AM -0200, Henrique de Moraes Holschuh wrote: Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. Can't you just leave rp_filter on for lo, or disable it only on those interfaces on which you are likely to see asymmetric routes arriving? Yes. But rp_filter won't get all instances of trouble trying to reach lo through some other interface, I think. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Hi, Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Wed, 23 Feb 2005, Junichi Uekawa wrote: The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? Only if the kernel is starking mad and buggy as all hell, you cannot take over a local IP from the network, especially one that belongs to a NOARP interface. OTOH, you can probably reach all sort of nice stuff that is bound to 127.0.0.1 in another host over the network, and a lot of people will be caught with their ports open on that one. If you send a packet to 127.0.0.1 with the MAC address of any of the local interfaces, and forwarding is enabled, well... I am not sure it will work with forwarding disabled. Anyone cares to test? Disable rp_filter first. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sat, Feb 19, 2005 at 12:13:34AM -0200, Henrique de Moraes Holschuh wrote: Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. Can't you just leave rp_filter on for lo, or disable it only on those interfaces on which you are likely to see asymmetric routes arriving? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: First line in /etc/hosts
In article [EMAIL PROTECTED] you wrote: So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? no, there are some obvious illegal addresses excluded. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Am 2005-02-19 10:13:42, schrieb Junichi Uekawa: Hi Do you mean: 1. on linux there is a principal IP address that is assigned to a node regardless of NIC due to the implementation of ARP etc. 2. on linux there is some magic IP *number* that is assigned to a node; and IP addresses are assigned to individual NICs. - if so, what is a IP number? 127.0.0.1 regards, junichi Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: First line in /etc/hosts
Hi Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. Indeed. For Linux, nodes have IP *numbers* which are all equal, and you have to take great pains to make sure it behaves in any different way. iproute2, arptables and the relative black magic of arp_filter are your only ways to try to influence that. Usual route, ifconfig, etc are useless. This portion is unclear to me; could you shed some light ? Do you mean: 1. on linux there is a principal IP address that is assigned to a node regardless of NIC due to the implementation of ARP etc. 2. on linux there is some magic IP *number* that is assigned to a node; and IP addresses are assigned to individual NICs. - if so, what is a IP number? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. This portion is unclear to me; could you shed some light ? Do you mean: [wrong guesses omitted] A machine may use the same IP on multiple interfaces. A machine may use multiple IP addresses on a single interface. The two may be combined. A router may use proxy arp. A machine may use the same ethernet address on multiple interfaces on different physical networks. This tends not to work well with vlans. (switches pretending to be multiple networks) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Fri, 18 Feb 2005, Blars Blarson wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. This portion is unclear to me; could you shed some light ? Do you mean: [wrong guesses omitted] A machine may use the same IP on multiple interfaces. A machine may use multiple IP addresses on a single interface. The two may be combined. A router may use proxy arp. A machine may use the same ethernet address on multiple interfaces on different physical networks. This tends not to work well with vlans. (switches pretending to be multiple networks) Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: Every machine with more than one interface has at least two hostnames: localhost on network 127 and something else on the external networks. Nitpicking: every machine have exactly one hostname, that is contained in /proc/sys/kernel/hostname. The host _may_ have one or more network interfaces, every network interface _may_ have one or more addresses, and those addresses _may_ resolve to domain names (which are also called hostnames, but are completely independent from /proc/sys/kernel/hostname). I think there are two problems here: some packages make assumptions about *the* IP number and/or *the* hostname, and /etc/hosts gets misconfigured either by buggy software or the admin. Well, there is a quite sensible default for desktop machines with just one physical network interface. You just have to realize that this may not work for an increasing number of machines (think about laptops with both a wireless and a TP interface, connected to two different DHCP-managed networks at the same time). The biggest mistake people are used to make is thinking that the contents of /proc/sys/kernel/hostname has _anything_ to do with any address on any network interface, and just blindly use the output of `hostname`. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 03:01:26PM +, Mark Brown wrote: On Sun, Feb 13, 2005 at 01:25:15PM +0100, Steinar H. Gunderson wrote: However, now we've suddenly discovered that _other_ programs get confused by this! In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) This also causes problems for NIS servers, for the same reason - NIS needs to hand out the IP address of the machine in some circumstances and 127.0.0.1 is inappropriate. Resolving the hostname is a standard method for obtaining an IP address for the machine and it would be helpful if it could be reverted since I imagine other programs are also going to run into the same issue. Changing that could also confuse some inner features (e.g.filtering hosts by name) for programs like proftpd. Unfortunately also order is important, I received at leat one report about that, due to changes in /etc/hosts... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
First line in /etc/hosts
Current d-i writes the following line to the beginning of /etc/hosts: 127.0.0.1localhost.localdomain localhost Traditionally, this confuses some programs; at least pvm used to have problems with this, and I'm fairly sure cfengine2 doesn't like it either, so we've changed to 127.0.0.1machinename.our domain machinename localhost However, now we've suddenly discovered that _other_ programs get confused by this! In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) So, one program has to be buggy here, but which? :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Feb 13, Steinar H. Gunderson [EMAIL PROTECTED] wrote: So, one program has to be buggy here, but which? :-) The first ones. 127.0.0.1 IS localhost. -- ciao, Marco signature.asc Description: Digital signature
Re: First line in /etc/hosts
On Sun, 13 Feb 2005 13:30:11 +0100, Steinar H. Gunderson wrote: Current d-i writes the following line to the beginning of /etc/hosts: 127.0.0.1localhost.localdomain localhost This is correct. Traditionally, this confuses some programs; at least pvm used to have problems with this, and I'm fairly sure cfengine2 doesn't like it either What problems? If there are problems then they probably arise from a faulty _combination_ of /etc/hosts, hostname, /etc/nsswitch.conf and /etc/resolv.conf settings. so we've changed to 127.0.0.1machinename.our domain machinename localhost However, now we've suddenly discovered that _other_ programs get confused by this! So revert the change? In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) Make your /etc/hosts look like this: 127.0.0.1localhost.localdomain localhost w.x.y.z machinename.our domain machinename Make w.x.y.z either the permanent IP address of your machine's permanently connected network adapter, or, if it does not have one of those, 127.0.1.1. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 01:25:15PM +0100, Steinar H. Gunderson wrote: However, now we've suddenly discovered that _other_ programs get confused by this! In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) This also causes problems for NIS servers, for the same reason - NIS needs to hand out the IP address of the machine in some circumstances and 127.0.0.1 is inappropriate. Resolving the hostname is a standard method for obtaining an IP address for the machine and it would be helpful if it could be reverted since I imagine other programs are also going to run into the same issue. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Mark Brown writes: ...NIS needs to hand out the IP address of the machine... Machines don't have IP numbers. Interfaces have IP numbers. Every machine with one or more external interfaces has at least two: 127.0.0.1 for the loopback interface and one for each external interface. Resolving the hostname is a standard method for obtaining an IP address for the machine... Every machine with more than one interface has at least two hostnames: localhost on network 127 and something else on the external networks. Routers often have different hostnames on different external interfaces. I think there are two problems here: some packages make assumptions about *the* IP number and/or *the* hostname, and /etc/hosts gets misconfigured either by buggy software or the admin. The purpose of /etc/hosts is to associate IP numbers with hostnames. I can see no good reason to associate 127.0.0.1 with any name other than localhost. It is also not always necessary for all of a machine's IP numbers and/or hostnames to appear in /etc/hosts. (I'm sure you know all this, Mark, but I'm not sure everyone else in the thread does. I *am* sure that some people writing Linux programs don't.) -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
In article [EMAIL PROTECTED] you wrote: Resolving the hostname is a standard method for obtaining an IP address for the machine And pretty broken in a lot of the cases :) It is much better to retrieve the local current IP address of the connection you are going to send the ip (if it is needed). This works at least for TCP. For UDP it should be configurable, a lookup by name is of course a possible default. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: Mark Brown writes: ...NIS needs to hand out the IP address of the machine... Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, 13 Feb 2005, Mark Brown wrote: On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: Mark Brown writes: ...NIS needs to hand out the IP address of the machine... Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. Indeed. For Linux, nodes have IP *numbers* which are all equal, and you have to take great pains to make sure it behaves in any different way. iproute2, arptables and the relative black magic of arp_filter are your only ways to try to influence that. Usual route, ifconfig, etc are useless. BTW, as a corolary, always firewall off 127.0.0.1 to any non-lo traffic, even when interface forwarding is disabled. You Have Been Warned. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
