574 lines
23 KiB
Plaintext
574 lines
23 KiB
Plaintext
Subject: Linux-Development Digest #551
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Date: Mon, 14 Mar 94 04:13:08 EST
|
|
|
|
Linux-Development Digest #551, Volume #1 Mon, 14 Mar 94 04:13:08 EST
|
|
|
|
Contents:
|
|
Re: dip for PPP when? (Michael Callahan)
|
|
Misleading ENODEV from SCSI open and messages from mount(8) (Ian Jackson)
|
|
Re: Problem with NET-2 and Winsock Gopher/HTTP clients? (NetDog)
|
|
Re: A truely non-debugging Kernel? (Frank Lofaro)
|
|
0.99p15j: bug in SLIP ? And unusual hang in NE*-Detection (System Administrator)
|
|
Re: DIP: tty: getc: I/O error (Tin Le)
|
|
cleaning rbuf for sk=00694410 tcp_ack (root@jaxnet.com)
|
|
127.x.x.x (was Re: UDP report card) (Frank Lofaro)
|
|
Real-Time Linux and a/d device drivers (David G. Boney)
|
|
Re: A truely non-debugging Kernel? (Alex Ramos)
|
|
Re: 127.x.x.x (was Re: UDP report card) (Charles Hedrick)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: callahan@cluanie.maths (Michael Callahan)
|
|
Subject: Re: dip for PPP when?
|
|
Date: Sun, 13 Mar 94 22:48:53 GMT
|
|
|
|
In article <stock.763204643@dutsh7.tudelft.nl>,
|
|
Robert Stockmann <stock@dutsh7.tudelft.nl> wrote:
|
|
>After looking at dip , I noticed that there is an option for
|
|
>choosing PPP as protocol. however looking at the
|
|
>ppp.c routine it gives a message that its not implemented yet.
|
|
>
|
|
>When will this be? is someone working on it?
|
|
>
|
|
>The main advantage of dip over chat is that the script language
|
|
>is much more flexible, which is important when one wants
|
|
>to connect with PPP after a call back from a PPP server.
|
|
>
|
|
>robert stockmann <stock@dutsh7.tudelft.nl>
|
|
|
|
I have no plans on working on PPP support for dip, but would be
|
|
happy if someone else took it on.
|
|
|
|
If DIP can be made to call an external executable, then just have
|
|
it run pppd when the PPP server is on the line.
|
|
|
|
Michael
|
|
callahan@maths.ox.ac.uk
|
|
|
|
------------------------------
|
|
|
|
From: iwj10@cus.cam.ac.uk (Ian Jackson)
|
|
Subject: Misleading ENODEV from SCSI open and messages from mount(8)
|
|
Date: Sun, 13 Mar 1994 20:13:09 GMT
|
|
|
|
It seems that the kernel returns ENODEV ("No such device") if you try
|
|
to pass a filesystem type to mount(2) that it doesn't support
|
|
(fs/super.c).
|
|
|
|
However, the SCSI device drivers (drivers/scsi/sd.c) return ENODEV if
|
|
you try to access a disk that's not there. Most other devices return
|
|
ENXIO ("No such device or address") in this case.
|
|
|
|
The mount(8) program does some rather nasty return code translation.
|
|
It interprets the ENODEV as having come from a bad filesystem type,
|
|
and so prints "fs type ext2 not supported by kernel" or whatever, when
|
|
it should have said "No such device or address" or something similar.
|
|
|
|
I therefore suggest that:
|
|
|
|
(a) drivers/scsi/sd.c be modified to return ENXIO if the disk doesn't
|
|
exist.
|
|
|
|
(b) mount say what was wrong in more detail by at the very least
|
|
having a different message for each value of errno (most would be the
|
|
ones from strerror).
|
|
|
|
--
|
|
Ian Jackson, at home <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
|
|
PGP2 public key available on server. Urgent email: <iwj10@phx.cam.ac.uk>
|
|
2 Lexington Close, Cambridge, CB4 3LS, England; phone: +44 223 64238
|
|
|
|
------------------------------
|
|
|
|
From: cdent@yod.honors.indiana.edu (NetDog)
|
|
Subject: Re: Problem with NET-2 and Winsock Gopher/HTTP clients?
|
|
Date: Mon, 14 Mar 1994 05:23:55 GMT
|
|
|
|
>>>>> "Steven" == Steven Kirby <kirby@scarlett.libs.uga.edu> writes:
|
|
|
|
[snipped info on problems with winsock gopher clients and linux servers]
|
|
|
|
Steven> Any advice/information will be most appreciated,
|
|
Steven> especially if it will help me figure out who to bother
|
|
Steven> first with this problem.
|
|
|
|
Your posting in comp.infosystems.gopher seems to say that you have
|
|
found a solution to the problem. What is it?
|
|
|
|
Also, does Linux 1.0 solve this problem?
|
|
|
|
I've been messing around in the gopherd.c code (adding close(sockfd)
|
|
after every writing of ".\r\n") but really have no idea if that is a
|
|
valid solution.
|
|
|
|
Could someone (Steven, Alan, whoever) clear up what's going on hear?
|
|
|
|
Thanks,
|
|
|
|
Chris
|
|
--
|
|
cdent@indiana.edu | Chris Dent IU
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Re: A truely non-debugging Kernel?
|
|
Date: Mon, 14 Mar 94 00:37:41 GMT
|
|
|
|
In article <1994Mar13.222442.15907@ringer.cs.utsa.edu> ferovick@runner (David C Ferovick) writes:
|
|
>In article <1994Mar13.205037.24215@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
>>In article <1994Mar12.195624.9113@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes:
|
|
>>>In article <DOUG.94Mar11165709@midget.towson.edu> doug@midget.towson.edu (Doug McNaught) writes:
|
|
>>>>In article <2loo9h$fo8@aurora.engr.latech.edu> ramos@engr.latech.edu (Alex Ramos) writes:
|
|
>>>>
|
|
>>>>>Geez! The kernel has _so much_ debugging code (sanity checks, etc) that
|
|
>>>>>I wonder how much smaller it could be. It seems most kernel developers
|
|
>>>>>have never heard of #ifdef... Just a thought :-)
|
|
>>>>
|
|
>>>> Well, I'd rather give up some memory and have something that panics
|
|
>>>>and shuts itself down rather than blindly hosing my filesystems and/or
|
|
>>>>hardware... I *like* sanity checks. A lot.
|
|
>>>
|
|
>>>That's all or nothing thinking -- ship the kernel with #ifdef DEBUG and
|
|
>>>after a few weeks when you are happy, recompile with -UDEBUG.
|
|
>>>
|
|
>>
|
|
>>Well what do you do then if the kernel suddenly goes bonkers one day,
|
|
>>and clobbers you /usr partition or something awful like that?!
|
|
>>Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
|
|
>>you have a very intermittent problem, the debug stuff might make it
|
|
>>possible to find out what it is, else you'll never know. You'd have to
|
|
>>recompile with debugging after the fact and wait for it to happen again.
|
|
>>That might be an uncomfortable wait for those with mission-critical or
|
|
>>security related problems.
|
|
>>
|
|
>
|
|
>Well, if there was #ifdef's in there, it would be the USER's choice to run
|
|
>witht the debugging code or not...If a user thinks he may have a problem
|
|
>or is paranoid about not having the debugging code in the kernel, then they
|
|
>can leave it running. If you want to save memory and increase performance,
|
|
>then the user can take the risk of #undef'ing the debug code...
|
|
>
|
|
>--
|
|
>Dave Ferovick
|
|
>(ferovick@runner.jpl.utsa.edu)
|
|
|
|
There is a problem with that thought. Suppose a user compiles without
|
|
debugging and has a problem. They just say: "It crashes!", "It don't
|
|
work!", "Its broken!" and they can't give us the information we need
|
|
to fix a problem. Now if they do compile with debugging, they can tell
|
|
use what is in syslog files, what is printed, etc. No debugging means
|
|
error go unreported and unnoticed until something gets hosed, which
|
|
may be way to far after the fact (e.g. memory allocation errors, bad
|
|
I/O statuses, etc.)
|
|
|
|
We would have to make it clear that we could only help users that had
|
|
problems if they would compile with debugging enabled. I wouldn't
|
|
waste my time trying to help someone in a case where I had to try to
|
|
deduce what caused the failure, instead of having the information I
|
|
need to fix it without undue difficulty. I'd say (nicely of course),
|
|
please recompile with debugging and try again and tell us what
|
|
happens. Some subtle bugs might go unnoticed with non-debug kernels,
|
|
causing possible security holes or weird failures when they finally
|
|
"express" themselves.
|
|
Also, what does one do if there is an error that shows up in
|
|
an non-debugging kernel, but goes away in the debugging one? Then you
|
|
would HAVE TO work without the aid of debugging code. Or what if the
|
|
developers all test with debugging (wouldn't surprise me in the least)
|
|
and something the "debug" code does, e.g zero out memory,is depended
|
|
on by "normal" code. That could cause (possibly hard to find) errors
|
|
with non-debugging kernels. Developers would have to test with
|
|
debugging and normal kernels, wasting time. Or what if someone's
|
|
driver, etc works with the normal code, but changes in the debug code
|
|
cause it to break under newer debugging kernels. This would force
|
|
people to pull debugging out of their kernel or not use the driver, a
|
|
bad choice to have to make. I'd consider the driver broken: and not
|
|
use it, fix it, or not buy the hardware it uses due to poor linux
|
|
support if possible, e.g. not floppy code or somesuch, then I would be
|
|
hosed. If such a thing got mainstreamed it would be even worse.
|
|
Imagine if most of the "debug" code ended up like the malloc debugging
|
|
(okay, I admit that should be #ifdef'd, but the concept applies) code:
|
|
it is hashed out in config.in, and re-enabling it resulted in a kernel
|
|
which refused to link due to unresolved symbols (looks like stuff just
|
|
got out of sync and incompatible). This begs the question: would debug
|
|
code be supported well?
|
|
|
|
Some things should be #ifdef'd I agree, but not all. The current
|
|
situation is good I think. There real hefty debug code is left out,
|
|
but the other stuff is left in. Better for tracking problems and makes
|
|
testing, figuring out and debugging the kernel easier without having
|
|
to recompile.
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: root@desaster.sunflower.sub.org (System Administrator)
|
|
Subject: 0.99p15j: bug in SLIP ? And unusual hang in NE*-Detection
|
|
Date: Sat, 5 Mar 1994 03:06:20 GMT
|
|
|
|
I was using SLIP (not CSLIP :-( ) for some time, had two ncftp running when
|
|
the line dropped. I killed the ncftp-programs, and dialed again.
|
|
After reconnection, data came in, I suspect for the no-longer-there
|
|
ftp-connections - but netstat reportet they where still there!
|
|
(status: ESTABLISHED).
|
|
|
|
After a while this went away (the incoming data, not the netstat-status
|
|
for the long-ago-killed ftp-sessions), and I just worked on. Then, quite
|
|
some time after that, the following appeared in my syslog.err:
|
|
|
|
Mar 4 07:52:19 desaster linux: net timer expired - reason unknown, sk=007CCDFC
|
|
Mar 4 07:52:50 desaster linux: kfree of non-kmalloced memory: 007CCDF4, next= 00748000, order=4
|
|
Mar 4 07:53:10 desaster linux: kfree of non-kmalloced memory: 007CCDF4, next= 00748000, order=4
|
|
Mar 4 07:53:50 desaster last message repeated 2 times
|
|
|
|
Any idea what this is, and any idea how to trace down a potential bug ahere?
|
|
|
|
Another thing that I experienced this morning when I booted my machine, it
|
|
hung at the NE2000-detection (trying 0x300). It was completely hung, I had
|
|
to press the red-button. This never (!) happened before.
|
|
|
|
Cheers, Michael Will
|
|
|
|
------------------------------
|
|
|
|
From: tinle@starbase.sj.unisys.com (Tin Le)
|
|
Subject: Re: DIP: tty: getc: I/O error
|
|
Date: 12 Mar 1994 02:45:34 GMT
|
|
|
|
In article <2lgqt8$buo@nic.ott.hookup.net>, root@borg.ott.ca (Sys admin) writes:
|
|
|> * No gettys on the serial ports *
|
|
|> When I first boot my machine, I can run kermit as much as I want with no
|
|
|> problems. My first DIP script runs fine, but when I kill DIP via kill -9 pid,
|
|
|> enter kermit, enter hang command to hang up modem, I have to re-boot!
|
|
|> DIP now gives me the error in the subject, or sometimes it hangs when setting
|
|
|> the port to ttyS0. Kermit starts, then hangs untill I enter CTRL-C, which
|
|
|> brings me to the kermit prompt. When I enter 'connect' I get
|
|
|> Kermit -> Can't send character: I/O error.
|
|
|>
|
|
|> Can anyone else confirm this????
|
|
|>
|
|
|> Linux 99pl15j. Libc4.5.21.
|
|
|
|
I am running pre-1.0 and have seen similar error message. What seems to have
|
|
happened is that my DIP script set the modem to return result (ATQ0), and that
|
|
causes the serial driver problems. My system does not hang, but DIP and cu will
|
|
always give me those errors (actually cu will report receiving hangup [HUP] signal
|
|
and disconnect every time).
|
|
|
|
The fix is to power cycle my modem, which defaults to ATQ1E0V0. Then DIP, cu and
|
|
anything else that uses the port will work again. I have not had time to look at
|
|
the source yet. Perhaps someone more familiar with it can tell right away what
|
|
the problem is.
|
|
|
|
Regards,
|
|
Tin Le
|
|
|
|
--
|
|
=====
|
|
Tin Le | comp.binaries.ms-windows Moderator
|
|
TL Consulting | Send submissions to cbmsw@Saigon.COM
|
|
Current Office: 408-456-5587 | Requests to cbmsw-request@Saigon.COM
|
|
tinle@sj.unisys.com | Archive on wuarchive.wustl.edu
|
|
Or tin@saigon.com | MailServer at mailserv@Saigon.COM
|
|
|
|
------------------------------
|
|
|
|
From: root@jaxnet.com
|
|
Subject: cleaning rbuf for sk=00694410 tcp_ack
|
|
Date: Thu, 10 Mar 1994 05:35:27 GMT
|
|
|
|
Last night I got some strange messages out of the kernel. I am posting them
|
|
in case some developer out there is trying to fix bugs and that this one is
|
|
unknown. I strongly suspect what is wrong is way over my head. The system
|
|
did not crash and my slip connection is still running.
|
|
|
|
I run Linux 0.99.pl15j
|
|
CPU AMD386dx40
|
|
RAM 8meg
|
|
2 IDE hard drives
|
|
|
|
I am a heavy user of SLIP _NOT_ CSLIP
|
|
I am running DIP 3.3.4 SLIP/DIP work great I don't have to do any special
|
|
routing commands to make it work. my MTU is 1500.
|
|
|
|
The tty66 input overruns are _NOT_ from my slip connection I run my slip
|
|
connection on the 16550a chip on tty01
|
|
|
|
Here are the messages from my kernel:
|
|
|
|
<6>Console: colour EGA+ 80x50, 8 virtual consoles
|
|
<6>Serial driver version 3.99a with no serial options enabled
|
|
<6>tty00 at 0x03f8 (irq = 4) is a 16450
|
|
<6>tty01 at 0x02f8 (irq = 3) is a 16550A
|
|
<6>tty02 at 0x03e8 (irq = 4) is a 16450
|
|
<6>tty03 at 0x02e8 (irq = 3) is a 16450
|
|
<6>lp_init: lp1 exists (0), using polling driver
|
|
<6>Calibrating delay loop.. ok - 7.98 BogoMips
|
|
<6>Memory: 7404k/8448k available (456k kernel code, 384k reserved, 204k data)
|
|
<6>Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M
|
|
<6>Swansea University Computer Society Net2Debugged [1.27]
|
|
<6>IP Protocols: ICMP, UDP, TCP
|
|
<6>SLIP: version 0.7.5 (4 channels)
|
|
<6>CSLIP: code copyright 1989 Regents of the University of California
|
|
<6>Linux version 0.99.15j (root@jaxnet) #1 Wed Mar 2 22:05:44 GMT 1994
|
|
<6>Partition check:
|
|
<6> hda: hda1 hda2
|
|
<6> hdb: hdb1 hdb2 hdb3
|
|
<6>VFS: Mounted root (ext2 filesystem) readonly.
|
|
<6>Adding Swap: 8184k swap-space
|
|
<6>Adding Swap: 16792k swap-space
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>tty66: input overrun
|
|
<6>cleaning rbuf for sk=00694410
|
|
<6>sk->rspace = 4096, was 4096
|
|
<6>tcp_ack: seq a5d05de6 ack 13d04455
|
|
<6>Data wakeup.
|
|
<6>cleaning rbuf for sk=00694410
|
|
<6>sk->rspace = 4096, was 4096
|
|
<6>cleaning rbuf for sk=00694410
|
|
<6>sk->rspace = 4096, was 4096
|
|
<6>tcp_ack: seq a5d05de6 ack 13d04456
|
|
<6>Data wakeup.
|
|
<6>cleaning rbuf for sk=00694410
|
|
<6>sk->rspace = 4096, was 4096
|
|
<6>tcp_ack: seq a5d05de7 ack 13d04456
|
|
|
|
--
|
|
Karl Renaut
|
|
root@jaxnet.com
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.protocols.tcp-ip
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: 127.x.x.x (was Re: UDP report card)
|
|
Date: Mon, 14 Mar 94 01:11:13 GMT
|
|
|
|
In article <Mar.13.17.50.52.1994.1393@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
|
|
>ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
>
|
|
>>Linux USED TO handle 127.x.x.x right for all values of x.
|
|
>>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out
|
|
>>the default route.
|
|
>>This is bad, can we bring back the old behavior (thus not violating the RFC's
|
|
>>anymore like we are now)?
|
|
>
|
|
>I'm not convinced that it's right for 127.0.0.2 to be regarded as
|
|
>loopback. But if you want it, you can get it. It's all a matter of
|
|
>how you set up routing when you turn on loopback. I just enabled lo
|
|
>(which I normally don't have running) using
|
|
>
|
|
> ifconfig lo 127.0.0.1
|
|
> route -n add 127.0.0.0 dev lo
|
|
>
|
|
>Ping works equally well to 127.0.0.1 or 127.0.0.200.
|
|
|
|
Well the route thing works.
|
|
However, I think that all 127.x.x.x addresses should be loopback.
|
|
|
|
1: It does not break anybody's set up, unless they are violating RFC's
|
|
by using the 127 net for their own purposes (they deserve to lose, they
|
|
aren't interoperable)
|
|
2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.
|
|
|
|
RFC1122:
|
|
|
|
--- rfc excerpts follow:
|
|
|
|
3. INTERNET LAYER PROTOCOLS .................................... 27
|
|
3.1 INTRODUCTION ............................................ 27
|
|
3.2 PROTOCOL WALK-THROUGH .................................. 29
|
|
3.2.1 Internet Protocol -- IP ............................ 29
|
|
3.2.1.1 Version Number ............................... 29
|
|
3.2.1.2 Checksum ..................................... 29
|
|
3.2.1.3 Addressing ................................... 29
|
|
|
|
[...]
|
|
|
|
3.2.1.3 Addressing: RFC-791 Section 3.2
|
|
|
|
[...]
|
|
|
|
(g) { 127, <any> }
|
|
|
|
Internal host loopback address. Addresses of this form
|
|
MUST NOT appear outside a host.
|
|
|
|
--- end of RFC excerpts.
|
|
|
|
Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
|
|
comment? If my interpretation is correct, 127.x.x.x should always be
|
|
looped back.
|
|
|
|
Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
|
|
hold?
|
|
|
|
|
|
------------------------------
|
|
|
|
From: dboney@cs.ttu.edu (David G. Boney)
|
|
Subject: Real-Time Linux and a/d device drivers
|
|
Reply-To: dboney@cs.ttu.edu
|
|
Date: Mon, 14 Mar 94 01:13:22 GMT
|
|
|
|
|
|
--
|
|
Hi,
|
|
Are there any realtime extentions for Linux? Does any have a UN*X device driver
|
|
for a National Instruments AT-MIO-16 a/d board. Any type of unix would be OK. It would
|
|
give me a place to start.
|
|
|
|
Sincerely,
|
|
|
|
David G. Boney
|
|
|
|
American Heart Association Medical Student Research Fellow
|
|
Texas Tech School of Medicine
|
|
|
|
dboney@cs.ttu.edu Texas Tech University
|
|
Ph. 806-742-1191 Department of Computer Science
|
|
Lubbock, Tx. 79409 USA
|
|
|
|
------------------------------
|
|
|
|
From: ramos@engr.latech.edu (Alex Ramos)
|
|
Subject: Re: A truely non-debugging Kernel?
|
|
Date: 14 Mar 1994 05:56:47 GMT
|
|
|
|
Frank Lofaro (ftlofaro@unlv.edu), quoted out of context, wrote:
|
|
> Well what do you do then if the kernel suddenly goes bonkers one day,
|
|
> and clobbers you /usr partition or something awful like that?!
|
|
> Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
|
|
> you have a very intermittent problem, the debug stuff might make it
|
|
> possible to find out what it is, else you'll never know. You'd have to
|
|
> recompile with debugging after the fact and wait for it to happen again.
|
|
> That might be an uncomfortable wait for those with mission-critical or
|
|
> security related problems.
|
|
|
|
I couldn't care less if my machine has security problems, since I'm the
|
|
only user. And really, a clobbered /usr partition is no big deal
|
|
either, I trash entire disks every so often.
|
|
|
|
However, all the extra debugging junk *is* a problem, because I only
|
|
have 2 megs of RAM, on a 16-mhz 16-bit processor!
|
|
|
|
Of course other people think differently.. but that's exactly one of
|
|
the good uses for #ifdef!
|
|
|
|
#ifdef KDEBUG
|
|
if ( 2+2 != 4 ) { /* :-) */
|
|
panic("integer arithmetic failure");
|
|
}
|
|
#endif
|
|
|
|
|
|
--
|
|
Alex Ramos <ramos@engr.latech.edu> * This message is copyrighted material!
|
|
Louisiana Tech University BSEE/Sr * All rights reserved. No warranty, etc
|
|
|
|
------------------------------
|
|
|
|
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
|
|
Crossposted-To: comp.protocols.tcp-ip
|
|
Subject: Re: 127.x.x.x (was Re: UDP report card)
|
|
Date: 14 Mar 94 02:14:06 GMT
|
|
|
|
ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
>Well the route thing works.
|
|
>However, I think that all 127.x.x.x addresses should be loopback.
|
|
|
|
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
|
|
>comment? If my interpretation is correct, 127.x.x.x should always be
|
|
>looped back.
|
|
|
|
1) "the route thing" is probably the only solution you're going to get
|
|
at the moment. Where to send packets is by definition the
|
|
responsibility of the routing table. Under 0.99pl15 and later, the
|
|
kernel does not make routing entries. Your startup script is expected
|
|
to do so. That's not specific to 127. It's true for all networks. I
|
|
think the reason this worked in previous releases is the ifconfig
|
|
created routes automatically, and it doesn't do so now. After some
|
|
thought I believe I agree with Linus that enabling an interface
|
|
shouldn't create a route. That's the job of the route command. There
|
|
are different ways one might want to set up the route.
|
|
|
|
2) The RFC is clear that 127 addresses should never appear outside the
|
|
host. I don't believe it was intended to say that they have to be
|
|
implemented on the host. That is, one could simply drop all packets
|
|
to 127, and not receive any of them. I personally consider 127 to be
|
|
a class A network with exactly one host on it, 127.0.0.1. I believe
|
|
that any other 127 address should be considered "host unreachable".
|
|
But the point being made by the RFC's is: whatever you do with 127 on
|
|
your machine, no address involving it should show up outside your
|
|
machine. In the Linux context, the easiest way to do that is with
|
|
|
|
route add 127.0.0.0 dev lo
|
|
|
|
I think after release 1.0 we're going to tighten up on bogon
|
|
prevention. This includes handling all kinds of illegal addresses,
|
|
etc. I would argue that if the loopback interface is not enabled or
|
|
the route not set up, we should find a way to prevent 127 packets from
|
|
going out. Note that even under the old code, if you didn't ifconfig
|
|
the loopback, 127 would be sent out the default route. That's wrong.
|
|
One could argue that rc.local is part of the system as a whole, and
|
|
it's the responsibility of the people creating setup scripts to make
|
|
sure that the loopback interface is always turned on properly. I
|
|
guess I'd be willing to accept that, but it would make me feel
|
|
slightly better to know that 127 will never leave the machine.
|
|
|
|
By the way, the same problem occurs with incoming packets. If a
|
|
machine is misconfigured so that it sends to 127.0.0.1 on an Ethernet,
|
|
I believe we should not respond to an ARP response, and if a packet
|
|
addressed to 127.0.0.1 somehow comes from the outside, it should be
|
|
silently dropped.
|
|
|
|
------------------------------
|
|
|
|
|
|
** FOR YOUR REFERENCE **
|
|
|
|
The service address, to which questions about the list itself and requests
|
|
to be added to or deleted from it should be directed, is:
|
|
|
|
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|