dieter@lynn.cs.ucla.edu (Dieter Rothmeier) (12/02/89)
While reading some code, I came across the following construct: struct sockaddr_in sin; .... sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK); ... I know about INADDR_ANY, but I've never seen this one. It's defined in <netinet/in.h>. I looked through the documentation (this is on a Sun 3/80) quite extensively, but couldn't find anything. Any help would be appreciated. Dieter
mcgrath@paris.Berkeley.EDU (Roland McGrath) (12/02/89)
INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called `localhost'. Talking to this address gets you back to where you started from, without going through the network hardware. -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland
housel@en.ecn.purdue.edu (Peter S. Housel) (12/02/89)
In article <MCGRATH.89Dec1142539@paris.Berkeley.EDU>, mcgrath@paris (Roland McGrath) writes: >INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called >`localhost'. Talking to this address gets you back to where you started from, >without going through the network hardware. The nifty thing is that (on many systems with BSD-derived networking) you can disable the loopback-net, through which address 127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the "loopback interface" and the machine will be unable to talk to itself. We once had cause to do this. Due to some kernel bug, packets were occasionally getting stuck in loops within the loopback. The system would get very sluggish, forwarding packets in tight little circles. Until the problem was fixed we just disabled the "interface" for 30 seconds or so until the offending packet timed out. -Peter S. Housel- housel@ecn.purdue.edu ...!pur-ee!housel
swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) (12/04/89)
>Date: 2 Dec 89 15:15:27 GMT >From: ea.ecn.purdue.edu!housel@ee.ecn.purdue.edu (Peter S. Housel) >Subject: Re: What is INADDR_LOOPBACK for in sockets? >To: tcp-ip@nic.ddn.mil > > The nifty thing is that (on many systems with BSD-derived >networking) you can disable the loopback-net, through which address >127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the >"loopback interface" and the machine will be unable to talk to itself. I can't resist adding that you have to be careful, though, of situations where you lose a route to 127.0.0.1 but you have a "default" route floating around your net. For example, I used to see not infrequent situations where a BSD Unix-based router would be generating a "default" route -- say because it was EGPing with a backbone -- and on a broken system further away from the backbone, sendmail would try to connect to 127.0.0.1, and would end up following the default route and accidentally connecting to the default-generating machine (which knew where "127.0.0.1" was -- itself!), so that all mail from the broken one would appear to be from the correct userid but the incorrect system (the default-generating one). Scott
PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) (03/18/91)
>>>In article <MCGRATH.89Dec1142539@paris.Berkeley.EDU>, mcgrath@paris (Roland >>> McGrath) writes: >>>INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called >>>`localhost'. Talking to this address gets you back to where you started from >>From: ea.ecn.purdue.edu!housel@ee.ecn.purdue.edu (Peter S. Housel) >> The nifty thing is that (on many systems with BSD-derived >>networking) you can disable the loopback-net, through which address >>127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the >>"loopback interface" and the machine will be unable to talk to itself. >I can't resist adding that you have to be careful, though, of >situations where you lose a route to 127.0.0.1 but you have a >"default" route floating around your net. For example, I used to see 1) On my IBM TCP/IP for VM, "own-address" goes through the network, as you say. 2) But trying FTP 127.0.0.1 gets me talking to the first non such router on the path to the Internet. 3) 14.0.0.0 is used instead to stay local. 4) and, of course, ftp 14.0.0.0 from a host whose Internet path I am on gets to my system. So, it looks like the specific address is implementation dependent. A question is: how can a procedure (script or whatever) wishing to use the loopback address be made portable when there is no "localhost" to refer to in the dns? Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
BRUCE@UMDD.BITNET (Bruce Crabill) (03/18/91)
>1) On my IBM TCP/IP for VM, "own-address" goes through the network, as you say. >2) But trying FTP 127.0.0.1 gets me talking to the first non such router on the > path to the Internet. >3) 14.0.0.0 is used instead to stay local. >4) and, of course, ftp 14.0.0.0 from a host whose Internet path I am on gets > to my system. > >So, it looks like the specific address is implementation dependent. >A question is: how can a procedure (script or whatever) wishing to use the >loopback address be made portable when there is no "localhost" to refer to >in the dns? In this respect, the IBM TCP/IP (FAL) is broken (maybe it has been fixed in version 2). The "Assigned Numbers" RFC (RFC-1010) states: (g) {127, <any>} Internal host loopback address. Should never appear outside a host. I.e., any class A network address that starts with a 127 in the first octet is a loopback address. This has been brought to IBM's attention in the past and the response is that it is this way for historical purposes and compatibility to previous versions. The fact that it will actually place a 127.x.x.x number on the network is just plain broken. If it isn't fixed in version 2 (which is just now getting out to people), I will try to make a SHARE requirement of it at the next SHARE meeting. Bruce