Table Of Contents
|1.||11�Mar�2000�-�24�Mar�2000||(491 posts)||Possibly Unfixable, Longtime Denial Of Service Attack|
|2.||15�Mar�2000�-�23�Mar�2000||(3 posts)||Running Really Old Kernels|
|3.||16�Mar�2000�-�24�Mar�2000||(6 posts)||Advanced Power Management In 2.4|
|4.||17�Mar�2000�-�21�Mar�2000||(15 posts)||Change In bogomips Calculation|
|5.||18�Mar�2000�-�21�Mar�2000||(5 posts)||MAKEDEV Requires 'devfs' In Recent Kernels|
|6.||19�Mar�2000�-�22�Mar�2000||(5 posts)||Xircom Network Card Problems|
|7.||19�Mar�2000�-�21�Mar�2000||(4 posts)||Opening Files By Inode|
|8.||20�Mar�2000�-�21�Mar�2000||(13 posts)||Booting Large Drives|
|9.||20�Mar�2000�-�21�Mar�2000||(4 posts)||'#include' Cleanup In Tulip Files|
|10.||20�Mar�2000�-�21�Mar�2000||(5 posts)||Loading A New Kernel From A Running Linux System|
|11.||21�Mar�2000�-�24�Mar�2000||(27 posts)||Video CD Under Linux|
|12.||21�Mar�2000�-�22�Mar�2000||(4 posts)||Porting From 2.0 To 2.2|
|13.||21�Mar�2000�-�23�Mar�2000||(7 posts)||Status Of SC300 PCMCIA Driver|
|14.||21�Mar�2000�-�22�Mar�2000||(4 posts)||Status Of NFSv3|
|15.||22�Mar�2000�-�24�Mar�2000||(10 posts)||iproute2 And netfilter HOWTO|
|16.||22�Mar�2000�-�23�Mar�2000||(6 posts)||Creative DVD-RAM RAM1216S Drive Difficulties|
|17.||24�Mar�2000�-�25�Mar�2000||(10 posts)||Using Broken RAM Chips Under Linux|
|18.||25�Mar�2000||(8 posts)||Source Routing|
Mailing List Stats For This Week
We looked at 1397 posts in 5890K.
There were 441 different contributors. 205 posted more than once. 174 posted last week too.
The top posters of the week were:
1. Possibly Unfixable, Longtime Denial Of Service Attack
11�Mar�2000�-�24�Mar�2000 (491 posts) Archive Link: "Some questions about linux kernel."
Topics: OOM Killer, USB
People: Carlos Morgado,�Rik van Riel,�Victor Khimenko,�Peter Zaitsev
This was the second longest thread ever covered in Kernel Traffic, the first being covered in Issue�#40, Section�#2� (3�Oct�1999:�Big Devfs Discussion) .
Peter Zaitsev found that a simple program that just kept allocating 4K chunks of memory until swap was used up, would reduce the system to an unusable state, and would eventually kill off important processes. He added that on Solaris, this same program would just get an out of memory error eventually, and not unduly inconvenience any other processes at all. Carlos Morgado explained what was happening, "Basicly all the swaped out runnable processes will die when they page fault. since we're oom basicly all processes are more or less swaped out. as consequence, at least syslogd dies. if you're lucky and the offending process dies too meanwhile nothing else bad will happen." And Rik van Riel, also in a response to Peter, sounded a warning note of the discussion to come:
It is trivial to solve this problem in a satisfactory way for 99% of the situations. There has never been a 100% solution however and the last three times I sent such code to linux-kernel a (small) flamewar started.
If Linus indicates he's willing to accept something like my 2.2 oom killer patch into 2.3, I'll code something up.
Victor Khimenko also replied to Peter with a similar tune:
Ok. This discussion is serveral YEARS old. So do not hold you breath. There were lots and lots of discussion about this and fewdifferent patches are floating around for ages (in 2.2.15pre some OOM patches was tried; perhaps 2.2.15 will include one of them). But ALL patches are designed to help in case of run-away process and NOT protect against malicious user.
P.S. Of course if you'll be able to cook up patch and solve this outstanding problem still not solved after few years of exercises by Linux's memory wizards you are welcome. Just don't think it's so easy :-(
Still in the first day of the discussion, Rik replied:
On the contrary, putting together a solution to this problem is easy. The problem has been that people don't understand the issues involved and start a flamewar as soon as a patch (re)surfaces.
Also, making a solution that everybody agrees with seems to be impossible in this situation :)
There followed a really long discussion, in which some folks made suggestions, others told them they should go read a book, and various problems were elucidated.
2. Running Really Old Kernels
15�Mar�2000�-�23�Mar�2000 (3 posts) Archive Link: "Linux 0.0.1 kernel compile"
People: Paul Gortmaker
Hector Facundo Arena was trying to get linux 0.0.1 going as a school project, but was getting compiler errors. Actually the assembler would not recognize the '-c' option. Paul Gortmaker replied, "Unless you really have your heart stuck on v0.0.1 then I'd suggest going to v1.0.9. It is still super small (tarball fits on a floppy with space to spare!) which should make it appealing for school research and a while back I hacked on v1.0.9 so that it would build (and run!) on a more current linux system (like gcc-2.7.2 and libc5, which was current at the time). You should be able to find it on linux ftp archives (look for linux-lite)."
3. Advanced Power Management In 2.4
16�Mar�2000�-�24�Mar�2000 (6 posts) Archive Link: "Re: APM suspend problems with kernel 2.3.51"
Topics: Power Management: ACPI
People: Andrew Pam,�Alan Cox
Andrew Pam noticed that Alan Cox's Task List for 2.4 did not include the fact that APM suspend no longer worked on the Sony VAIO PCG-505TR with recent kernels. He urged, "If APM suspend is broken, then since ACPI suspend isn't expected for a while yet I would be completely unable to suspend my laptop with a 2.4 kernel - which would prevent me from using the 2.4 kernel series until it is fixed." Alan pointed out that ACPI would usually be off by default, and asked if suspend would work on that machine, with ACPI off, and APM on. Andrew replied that no, it would not work, and he'd received email from someone else with the same problem. Another person replied to Alan, saying that on his X505SX, suspend, standby, and hibernate all worked fine. Andrew replied that he was unable to reliably reproduce the problem, but he had received more emails from people experiencing the same thing. End of thread.
4. Change In bogomips Calculation
17�Mar�2000�-�21�Mar�2000 (15 posts) Archive Link: "bogo-bogomips"
People: Andrew Morton,�Horst von Brand,�Alan Cox,�Pavel Machek
Andrew Morton reported that his bogomips were calculated at twice their normal value under 2.3.99-pre1; he replied to himself, "I see now that if the CPU has a timestamp counter the loops_per_sec is in fact cpu cycles per sec and is hence higher. Is this a plot to make people think 2.4 is faster?" Horst von Brand replied, "Oops, you found out... now we'll have to kill you." And Alan Cox also replied to Andrew, "2.2.15pre also does it. Its required for some of the upcoming processors." Elsewhere, he clarified, "Its -BOGO- mips. Its a bogus meaningless indication of process speed. We've changed the way we measure it for delay loops to use the TSC on chips that support RDTSC." Pavel Machek posted a patch, and objected to the previous situation, "But it is still broken. Let laptop boot in maximum powersaving mode (low bateries will do the trick on my toshiba), then plug AC in. Suddenly, all your udelay() loops take only HALF of expected time; that's problem. I've got a code which detects such events, warns, and recalibrates." There was no reply.
5. MAKEDEV Requires 'devfs' In Recent Kernels
18�Mar�2000�-�21�Mar�2000 (5 posts) Archive Link: "MAKEDEV & 2.3.99-pre"
Topics: FS: devfs
People: Alan Cox,�Theodore Y. Ts'o,�Nick Holloway
Someone reported that under 2.3.99, 'MAKEDEV' would return "major_pty/m%d=2: No such file or directory" errors. Nick Holloway (former 'MAKEDEV' maintainer) explained that 'MAKEDEV' read '/proc/devices/index.html', which in turn looked like this:
He pointed out that this would be meaningful if 'devfs' were installed, and that '/proc/devices/index.html' had had this format since 'devfs' had been included in 2.3.46; Alan Cox replied, "That change is right - but only if devfs is included. If devfs is not present the old names should be reported by /proc/devices IMHO." And Theodore Y. Ts'o volunteered, "I was tempted to do this for the serial driver, but was concerned people (especially Linus) might not accept the extra #ifdef's. I'd be happy to fix this for all of the tty devices if folks think it's a good idea."
6. Xircom Network Card Problems
19�Mar�2000�-�22�Mar�2000 (5 posts) Archive Link: "[pre5-2.3.99-pre1] PCMCIA problems."
People: Jeff Garzik,�Anders Peter Fugmann
Anders Peter Fugmann reported that his Xircom 10/100 Mbit PCMCIA model rbe-100 network card wouldn't work on his Compaq Armada M700 notebook, since 2.3.37; Jeff Garzik replied, "The Xircom Tulip lookalikes currently have known problems due to the death of tulip_cb. A fix should appear this weekend, but it not present at the moment..." A little while later, he posted a patch (http://gtf.org/garzik/kernel/files/xircom-cb-188.8.131.52.3.patch.gz) and added, "You can now use the xircom_tulip_cb driver in kernel 2.3.99-pre3-pre3 or later, provided you have this patch. (this patch has been sent to Linus, so it should appear in the next kernel release...)" Anders replied that the patch had already been included in pre3-6, and worked.
7. Opening Files By Inode
19�Mar�2000�-�21�Mar�2000 (4 posts) Archive Link: "Open by inode (was Re: your mail)"
Topics: FS: NFS, FS: ext2
People: Jamie Lokier,�Horst von Brand,�Donald Becker,�Theodore Y. Ts'o
Donald Becker quoted Jamie Lokier as saying, "I wrote and posted an open-by-inode extension to ext2 about a year ago. You simply open <fs>/.inode/<number>. But nobody was interested, so I guess there isn't much demand after all." In the same quoted text, Horst von Brand replied to Jamie, "Open by inode allows to completely bypass placing files in non-x directories, thus breaking security big time."
In reply to this, Donald mentioned in his post to linux-kernel, that a module existed to allow opening inodes by their inode-number; but he warned:
I mention our implementation only as a point of interest. This is *not* a general purpose mechanism. There is no reason to provide this as a kernel feature.
Most filesystems get *really nervous* when you access an inconsistent inode, and some even become unhappy if you merely reference a inode with a zero count. We only use it with devices that are marked unwritable, preferably with a hardware mechanism or loopback mounted.
Needless to say, any mechanism that so readily cause kernel corruption is available only to 'root', so the file security issue never even needs to be considered.
My patch is for ext2 only. It adds a new ext2 attribute meaning "this is an open-by-inode directory". So you create .inode in a filesystem, chattr it, and then .inode/<number> refers to a specific inode in that filesystem.
Being ext2-specific, the patch ensures the correct behaviour when you try opening a non-existent inode: the entry in .inode doesn't exist. A little care is needed to avoid negative dentries here.
Because this works, it is safe to use on writable filesystems. Access through .inode is determined by the permissions on that directory as usual, and of course access to the files and directories themselves is determined by their permission as usual too.
It seems to work very well, but I don't have a use for it so I've never given it a thorough test.
My patch is better than Donald Becker's for another reason: you can use it over NFS ;-)
Theodore Y. Ts'o replied:
Linus hates the ability to do this, despite the calls from some application programs to be able to be able to do iopen(). I've sometimes been tempted to do something like this, but I suspect Linus and/or Al Viro would burn an image of me in effigy. :-)
Note that the ability to set the "open-by-inode" attribute had better be allowed only by root, since being able to open by inode can completely bypass filesystem hierarchy security. (Consider a publically readable file located in a mode 700 directory. It wouldn't be accessible because of the mode 700 directory, but someone who could open-by-inode would be able to gain access to it.)
Jamie agreed that only root should be allowed to set the "open-by-inode" attribute, and had the last word, with, "Well, it's not really any business of the VFS or the kernel. It's just part of the filesystem's namespace. So the ext2 maintainer should be making these decisions not Linus or Al Viro ;-)"
8. Booting Large Drives
20�Mar�2000�-�21�Mar�2000 (13 posts) Archive Link: "Booting to >8GB..."
People: Werner Almesberger,�Chris Wedgwood
Daniel J Blueman was having trouble booting Linux on his greater-than-8-gig harddisk. He knew that 'lilo' version 12 would not support this, and asked what would. Several people suggested the 'grub' bootloader, but Patrick J. Kobly reported that he had dealt with the problem several times and learned that 'grub' would definitely not work. But Chris Wedgwood said that 'grub' seemed to support large drives as of February. There was no reply to that, but Michel Catudal said that he seemed to recall a newer version of 'lilo' that would handle large drives, although he hadn't checked it out. Werner Almesberger confirmed this, and gave a pointer to John Coffman's 'lilo' version 21-3 (ftp://icaftp.epfl.ch/pub/people/almesber/lilo/lilo-22dev0.tar.gz) .
9. '#include' Cleanup In Tulip Files
20�Mar�2000�-�21�Mar�2000 (4 posts) Archive Link: "[PATCH] tulip hosed in pre3-3"
People: Paul Laufer,�Jeff Garzik,�Michael Harnois
Michael Harnois posted a one-line patch to 'drivers/net/tulip/tulip.h', to include 'asm/io.h'. Jeff Garzik thanked him, and Paul Laufer added, "If you do this, you might as well remove the '#include�<asm/io.h>' from files that '#include�"tulip.h"'. Unless there is a good reason to not do so?" he posted a patch, and Jeff replied, "looks good to me, applied locally... will test tomorrow along with a few other things."
10. Loading A New Kernel From A Running Linux System
20�Mar�2000�-�21�Mar�2000 (5 posts) Archive Link: "Re: Linux loading Linux"
People: Erik Arjan Hendriks,�Alan Cox,�Ronald G. Minnich
Erik Arjan Hendriks wrote a module that would load and start a new Linux kernel from a running Linux 2.2.x system. He gave a link to code and documentation (http://www.scyld.com/software/monte.html) , and added, "A limitation right now is that it doesn't handle reboots of SMP boxes. That seems pretty hairy. Any comments on the code and/or suggestions about what to do with SMP would be greatly appreciated." Alan Cox replied, "The problem with the SMP case is you need to spin the other processors (you might find the MP1.4 bios writers info very useful since it basically tells you what is expected). You'd have to find somewhere to hide a small piece of code across the reboot (eg in the low 4K or EBDA). The bios is the low 1K from memory so putting it at the end of the 4K we preserve ought to work." Ronald G. Minnich said he wanted to talk to anyone working on that. Elsewhere, Erik said to someone else that he had previously done no work at all on the SMP case, but planned on checking out the MP1.4 bios writers info, now that Alan had pointed it out.
11. Video CD Under Linux
21�Mar�2000�-�24�Mar�2000 (27 posts) Archive Link: "Video CD under Linux"
People: Jens Axboe,�Steffen Kern,�Brian Litzinger,�Per Lundberg,�Seth M LaForge
Per Lundberg reported that the VCD format seemed to be unsupported under Linux. He asked why this was so. A lot of people replied, saying that it most definitely was supported, and Jens Axboe put it, "It's not unsupported, it's just not supported through the regular block device interface." Everyone named software players for VCDs; and Quang Nguy gave pointers to some links (as Seth M LaForge points out, these links are for DVDs, not VCDs. But they're interesting anyway, so here they are -- Ed: [06 Apr 2000 00:00:00 -0800]:
Steffen Kern added, "the more important question (for me) is, how to write video cds? i have mpeg1 video files and want to burn one....tried to burn one file directly as a XA2 track using cdrecord..the result were a lots of data overrun detected messages from the kernel... is there anyone who successfully burned a video cd and can tell me how?" Brian Litzinger replied:
I know how and have done it. Sadly I paid $350 for the knowledge and signed an NDA.
One of the confusions that people run into when dealing with VideoCDs is that there are two TOCs (Table of Contents) tables on a VideoCD. One is for use by computationally advantaged mechanisms, such as computers, the other is for computational disadvantaged mechanisms such as VideoCD players.
The former is a file system by any reasonable definition.
He offered this advice:
There is a book called the 'Green Book'. It has all the answers in it. You can buy it from the Phillips/Sony consortium that owns the technology, and from that you shouldn't have any troubles making VideoCDs. You might be more interested in the newer Super VCD standard.
Just use Google and look for 'VideoCD Green Book'. There are other books, such as the 'White Book' which would probably be helpful too.
Most of the VideoCD player software I have seen are what I would call rippers. They basically know how to find the mostly MPEG 1 compliant video stream on the VideoCD and suck it off, skipping the TOCs all together.
12. Porting From 2.0 To 2.2
21�Mar�2000�-�22�Mar�2000 (4 posts) Archive Link: "current->timeout"
People: Richard Gooch,�Augusto Cesar Radtke
Paul Burkacki asked about porting a character driver from 2.0 to 2.2, and Augusto Cesar Radtke gave a pointer to Richard Gooch's Porting To 2.2 (http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html) page. Ed Taranto (also porting a driver) said this was a great page, but he wanted more detailed information about specific changes relating to his driver. There was no reply to this, but elsewhere, someone suggested porting to 2.4 instead, since it was almost out the door.
13. Status Of SC300 PCMCIA Driver
21�Mar�2000�-�23�Mar�2000 (7 posts) Archive Link: "[patch] AMD SC400 support, kernel 2.3.99"
People: Jeff Garzik,�David Hinds
In the course of discussion, Jeff Garzik asked, "If we are adding ELAN support to the kernel, has anyone tested David Hinds' SC300 PCMCIA driver?" David replied:
I've just been sitting on that, because after I wrote it, no one (including the people who paid me to write it!) seemed interested in using it. And the company that paid me for it never got around to sending me the prototype hardware, so it is completely untested.
If someone wants to look at it / test it / port it to 2.3, I'll send it to them. But I don't really want to spend more time on it if there is no evidence that it will ever be used.
14. Status Of NFSv3
21�Mar�2000�-�22�Mar�2000 (4 posts) Archive Link: "linux nfsv3 client?"
Topics: FS: NFS
People: Neil Brown
Myles Uyema asked if the stable series supported NFSv3 as a client. Neil Brown gave a status report:
Yep. It is in hand. You can get patches for 2.2.14 for both nfs client and nfs server at
Hopefully this will all go into an early 2.2.16-pre release.
The server stuff is all in 2.3.99pre3. The client stuff is being merged in now.
He added, "Trond" [Myklebust] "is the guy who has been doing the NFS client improvements, including NFSv3."
15. iproute2 And netfilter HOWTO
22�Mar�2000�-�24�Mar�2000 (10 posts) Archive Link: "HOWTO"
Topics: Ottawa Linux Symposium
People: Bert Hubert,�Paul Rusty Russell,�Marc Mutz,�Gregory Maxwell,�Rusty Russell,�Erik Andersen
Bert Hubert announced his intention to write an iproute2 & netfilter HOWTO, and asked if any similar projects existed. Marc Mutz recommended asking the Linux HOWTO Maintainer; Erik Andersen replied to Bert, and gave a pointer to Linux 2.2 (Mostly Networking) (http://snafu.freedom.org/linux2.2/) . Someone else replied to Bert with a pointer to IP Quality Of Service On Linux (http://www.davin.ottawa.on.ca/ols/) , a tutorial given by Jamal Hadi Salim at the 1999 Ottawa Linux Symposium; and Bert replied, "This is really good stuff. Hard to find with a search engine however because all the text is in images. Thanks." Paul Rusty Russell replied to Bert's original post:
Netfilter HOWTO has been obsoleted by a clean division between:
A 2.4 Routing HOWTO would complete the set. My preference would be for a HOWTO which doesn't assume anything beyond the (elementry) stuff in the Networking Concepts HOWTO.
Not an easy task though: this HOWTO could easily run to 10k lines and still not be complete.
Bert gave a pointer to what he had done so far (http://www.ds9a.nl/2.4Routing/) , and elsewhere, reported on his progress:
Work is progressing well. Some people have mailed that they are willing to help. Gregory Maxwell has offered to send his work so far and told me that he has lots of real world examples, which suits me just fine :-)
The idea currently is to refer to Rustys netfilter HOWTOs as an introduction, and then explain how the 'mark' ability can be used to guide iproute2 and tc to route & shape your traffic, which is then described.
I'm currently studying CBQ so I can give a very short introduction on it. The main point of the HOWTO however is 'hands-on'.
16. Creative DVD-RAM RAM1216S Drive Difficulties
22�Mar�2000�-�23�Mar�2000 (6 posts) Archive Link: "Using a Creative DVD-RAM RAM1216S drive under Linux kernel 2.2"
Topics: Disks: SCSI, FS: ReiserFS, FS: ext2
People: Charles C. H. Jui,�Adam Heath
Charles C. H. Jui posted a patch and reported:
After a lot of struggle and lack of useful information from Creative Labs North America, I have stumbled onto the secret of running the CREATIVE DVD-RAM RAM1216S drive under Linux kernel 2.2.
In thoery, a patch exists for Linux kernel 2.2.1-2.2.12 for the CREATIVE DVD-RAM drive, and support is built into kernels 2.2.13 and 2.2.14. Please see, for example, http://www.bitwizard.nl/dvd/.
Alas, when I try either patching an older kernel or running the new ones, the drive would be properly recognized, but when I attempt to write to it, it would start "clicking" and then hang the SCSI bus.
In looking more closely at what people reported on the web, this patch (and the support in the latest kernel) are for the Creative DVD-RAM RAM1220S. Whereas what I have is a RAM1216S. I called up Creative and theyn drew a complete blank. The Technical Support folks have no information on the 1216S at all--they in fact claim the drive is not marketed in North America.
Looking closely at the physical appearance of the drive, I decided the 1216S must have come from a different OEM source than the 1220S. The 1220S is an OEM from Panasonic/Matsushita. I looked at other drives and discovered that the front and back panels of the drive are similar to the Toshiba SD-W1101 and SD-W1111 DVD-RAM drives. The fact that both drives shipped with a metal pin to force the cartridge to eject was the smoking gun.
I t turns out that Reed Meyer of Yale Astronomy had determined that the SD-W1101 drive had a special problem. It does not recgnize 6-byte SCSI commands. Please see, for example, http://www.uwsg.iu.edu/hypermail/linux/kernel/9908.3/0738.html, for a copy of the original posting.
The fix is therefore to revert back to 10-byte SCSI commands. Reed Meyer had posted two patches. One was a patch to recognize the drive as a removable disk (which the previously mentioned patches and the new kernels already addresse), and a second was the patch for sd.c. Both of these patches are for 2.2.11.
I attach below the patch for sd.c under kernel 2.2.14, which is the current stable kernel. This patch did the trick. I did still have to follow the instructions that a block size of 2048 (-b 2048) is needed for both "fdisk" and "mke2fs".
I have since attempted to call both Creative and Toshiba North America to inquire about a firmware upgrade (I really don't like messing with sd.c). Creative again has no information about the drive, even though it hastheir name on it. Toshiba simply said that they do not support OEM'ed products-talk to Creative.
Daniel J Blueman gave a link to CD-R, CD-RW, DVD-ROM and DVD-RW firmware (http://perso.club-internet.fr/farzeno/firmware/) . Adam Heath also replied to Charles, confirming that the drive had always been a problem for him. But Trying Charles' patch actually made things worse for him. Before the patch, he couldn't write to the drive at all under 2.2.14; and could only make ext2 or reiserfs filesystems under 2.2.15pre15, but couldn't write any files. But 2.2.15pre15 with the patch applied, caused 'mkfs.ext2' to try to write beyond the end of the device.
17. Using Broken RAM Chips Under Linux
24�Mar�2000�-�25�Mar�2000 (10 posts) Archive Link: "Patch: BadRAM put to use"
People: Rick van Rein,�Val Henson,�Bert Hubert,�Richard Gooch
Rick van Rein announced a patch (his first kernel patch) to allow the use of damaged RAM chips. He gave a pointer to the patch (http://home.zonnet.nl/vanrein/badram/) , and described:
My computer currently runs smoothly with two DIMMs that were considered dead, just because they suffered from static discharge. A RAM checker told me what sections of the RAMs were indeed dead, and all the rest could be exploited.
I can use 61 MB out of 64 MB, which is a great result, and good for trees. My main concern regarding trees is not reuse of RAM that suffered from static electricity, but to be able to use RAM in spite of manufacturing errors; a very large portion of RAMs (95% of the production?) must now be discarded of due to such errors. Trees don't like that. Neither do I.
Richard Gooch took exception to his use of the term trees, and Val Henson replied, "If you accept the (somewhat goofy) use of "trees" to mean "the environment in general," it makes sense. I recently read a book on microchip manufacture and visited the Intel plant near Albuquerque. In short, chip manufacture is "resource-intensive." I recommend learning the basics of microchip manufacture to any curious computer person."
Regarding the actual patch, Bert Hubert pointed out, "It may interest you to know that the venerable ZX Spectrum (Possibly known als a 'Timex' to US viewers) already employed this technique for all of its 16384 bytes of RAM. Sir Clive bought chips with single errors, and only used the ones where the error was in lower part of the chip (I believe). He then modified the Spectrum to only use the upper part."
Someone replied privately to Rick, asking about performance measurements with and without his patch. Rick quoted the post and replied that he didn't notice any difference in normal use, but that formal testing would be difficult because, without the patch, he couldn't use his broken RAM chips, and didn't have identical broken and unbroken chips to compare against each other. Also, he pointed out that the quantity of RAM would be different for the broken and unbroken chips, which would affect the results as well. He didn't discuss benchmarks done with or without the patch on a system with only healthy RAM chips.
18. Source Routing
25�Mar�2000 (8 posts) Archive Link: "Source Routing"
People: Brad Whitehead,�Michael H. Warfield
Brad Whitehead asked about source routing in Linux. He described his situation, "I have two available routes out to the internet. The branch occurs after several hops. eg. Packets travel the same route for hops 1, 2 and 3, but then can be routed either through router 4 or 5. I dont have permission (access) to change the routing tables on any of these routers. I would like to be able to choose between router 4 or 5 on-the-fly. eg. if router 4 goes down, then I would like to be able to switch the route to use router 5." He added that if this was not yet possible, he'd volunteer to code up a general solution that all could use. Michael H. Warfield replied at length:
Source routing has been in the kernel for a long long time. There use to be configuration option to suppress or prohibit source routing (since it is a security hole) but that option disappeared many revs back. I just glanced at net/ipv4/ipoptions.c and the code for IPOPT_SSRR (strict source routing) and IPOPT_LSRR (loose source routing) are still there. I don't know how they are enabled and disabled at this time. I would guess maybe a proc or sysctl interface much like forwarding became.
That being said... The chances of you getting source routing to work over a significant path in the net are extremely slim. You say you don't have control over the routers which determine which route to take. Chance are very good that one or more routers along that path are going to prohibit source routing. Many routers, concentrators, and terminal servers are now dropping all source routed packets as their default (or possibly only) configuration. Manufactures and ISPs have come to recognize the security risk present in unrestrained source routing and have stopped supporting it. You may get source routing to work in Linux only to discover that you still can't get it to work on the net.
The reason I know about this is that I'm the Senior Researcher and Fellow at Internet Security Systems on the X-Force. One test that we have in one of our products is a test for source routing bypassing a firewall (clue alert - guess where the security hole is). I've had source routing working in a test lab to demonstrate the test, both positive and negative. This was many kernel revs back, but I was able to use a "source route enabled" version of telnet on Linux to validate when we had source routing enabled on another Linux box and when we had it disabled. Linux is one of the few system, at the time, that made it relatively easy to enable it and disable it.
In the lab is one thing. I have yet to ever see it work past an outside ISP. Everything, and I do mean absolutely everything, in the path from your source to your finally destination must permit source routing options. If even one router or one dialing server blocks it, it won't work at all. Even if they are not specifically called out as a host on the loose source route, they can still block the packet with the source route option, and many already do.
He went on, "what it sounds like is that you want to set up a source routing table in the kernel to source route packets even if the app has not set the source route option on the socket. This would be a bad thing. Even if you could get it to work, what would you do if the application DID set the source route option. This has always been left up to the application to enable and specify on a socket by socket basis." And concluded, "Look elsewhere for your solution."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.