Kernel Traffic Zack Brown
FS: XFS Andries Brouwer Bill Davidsen

Jean-pierre Cartal noticed that the 2.6-test behavior had changed relative to 2.4, in that suid root files don't loose their suid bit when they get overwritten by a normal user. He asked if this was intended, or a bug. Ian Hastie confirmed the bahavior, saying, it seems the bug is something to do with a directory listing cache somewhere. If you sync after copying over the file the suid bit is shown as having been cleared. Bill Davidsen asked what would happen if someone attempted to execute the program before the sync was done. Would it run with setuid powers?

At this point Andries Brouwer said that he'd already made a fix for this, and asked if it wasn't working. Ian replied that on his XFS filesystem, Andries' fix did not work. End Of Thread.

Hyperthreading Power Management: ACPI Jun Nakajima Jeff Garzik

Marcelo Tosatti pointed out:

Ive received a few complaints that HT, starting from 2.4.22, needs ACPI enabled. Users who had HT working now have to use ACPI and they didnt before.

We should have HT working AUTOMATICALLY without ACPI enabled and WITHOUT any special boot option, as before.

He asked Len Brown to take a look at it; and Jun Nakajima confirmed that Len was working on it. Len replied, CONFIG_ACPI_HT_ONLY "CPU Enumeration Only" is under the CONFIG_ACPI menu at the request of Red Hat, who wanted to be able to disable anything to do with ACPI with a single option (CONFIG_ACPI). HT depends on this part of ACPI b/c the logical HT processors are enumerated using the ACPI MADT LAPIC entries. A couple posts down the line he proposed:

what to do?

We could make 2.4.23 like 2.4.21 where ACPI code for HT is included in the kernel even when CONFIG_ACPI is not set.

Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI really does remove all ACPI code in the kernel; and when CONFIG_ACPI is set, CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables part needed for HT.

I'd prefer the later (doing nothing) because CONFIG_ACPI really should exclude all of ACPI. If we start including bits of ACPI without CONFIG_ACPI, where do we stop?

I'm not sure how to address "compatibility" and "regression" concepts in the face of changing config files. Make oldconfig will ask you about CONFIG_ACPI -- perhaps I should update the help text to emphasize that it is necessary for HT, and that if selected, CONFIG_ACPI_HT_ONLY is then available?

Is defconfig used? Does it define "compatibility"? If so, we could define CONFIG_ACPI && CONFIG_ACPI_HT_ONLY in defconfig to get the 2.4.21 behavior -- then could have our cake and eat it too.

I don't feel strongly about which way to go, but I will want to keep 2.4 and 2.6 as similar as possible in this area.

Marcelo affirmed that CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI. He asked Len to make it clear in the configuration that this dependency did not exist, and to move the CONFIG_ACPI_HT item out of the ACPI section. Jeff Garzik suggested that it might be confusing to see "ACPI" in the name of a configuration option that was outside of the ACPI section, and proposed "CONFIG_HYPERTHREAD" or "CONFIG_HT" as alternatives. But Len opposed the change, on the grounds that the current name accurately described the true situation. Jeff again said that "CONFIG_HT" would be much clearer to the reader; but Len insisted, The problem is that "!CONFIG_HT" is meaningless. It implies that you can have CONFIG_ACPI but still "config-out" HT, which you can't. Len stood firm, but said he did implement Marcelo's requirements; and the thread ended.

Version Control Virtual Memory Marcelo Tosatti Jeff Garzik Pau Aliagas

In the course of discussion, Andrea Arcangeli remarked that if Marcelo Tosatti used an open source tool instead of BitKeeper for development, it would be possible to modify the tool to solve a particular changelog feature that seemed desirable. Linus Torvalds replied:

Andrea - please just shut up.

Until you can point to anything even _remotely_ as good as BitKeeper, there's no point in just continually trying to start a flame-war.

I agree that Larry ends up being a jerk about it too, but I can well see that he reacts negatively to your totally unproductive comments.

BK has the email in the meta-data already, and a lot of tools to extract all the necessary data from mailboxes etc.

In other words, your argument is nonexistant, and your whole posting is pointless - except as flame-bait. And yes, Larry likely _will_ eat your bait, something I've berated him for in private emails several times.

So shut up or put up. Go off and write your own tool. In the meantime, stop complaining about people who wrote _their_ tools and selected a license that you wouldn't choose.

When you write some code of your own, you get to choose the license. And I haven't seen you make CVS usable - I've only seen you bitch, moan, and complain..

Andrea replied, if I would know that you will eventually get interested into anything not bitkeeper I would be glad to hack in this area (I can use some spare time too) to provide a service to the community. The main reason I will never use b*tkeeper is because I want to retain the freedom to do that, something that you and many others won't be able to do anymore. He suggested that CVSPS and Subversion might be adequate for kernel development. Linus replied:

Neither of those are anywhere close to bk.

In particular, they don't support any kind of distributed development. They aren't even trying to, I'm sad to say. And to me, distributed development is the only thing that matters.

And I realise it isn't to you. You don't much care about merging, you only have your tree you need to worry about.

And you know what? You shouldn't have to care. I'm not berating you for using CVS/SVN/whatever. I'm berating you for complaining when _others_ have come to the conclusion that CVS/SVN/whatever really doesn't cut it for them.

Use CVS and be happy. But don't complain to others that have needs that CVS simply can't fill.

In the same post, he added:

I don't care about source control software, so I'm not likely to start coding one any time soon (like "ever") - but if I did, I'd be totally _ashamed_ to push lower-quality stuff on users. I'd make excuses for it, and I'd 'fess up when they didn't work. And I'd try my best to make it better. Even if it took me a decade.

In contrast, what you're doing is saying "ignore the good stuff: use this crap, because I'm buddies with the people developing it. We aren't even trying to compete on technical terms, but we'll push our version on you because we've got religion, and this doesn't contain any cow-meat". That's bad - especially if others DON'T share the religion.

I'm ok with other people using NT. When it's better for them, that's their choice. I work hard to make sure that the Linux kernel is technically superior, and if I feel it isn't I want to fix it. Because I do _not_ want people using Linux for religious reasons. I want people to use Linux because it is _better_ for them, of because they truly believe that they can make it so (or at least have fun trying).

Take pride in what you do. But don't make that pride blind you to what is good technology, and what isn't. Don't get religion. It's a science.

At this point, Pau Aliagas suggested that arch would do everything Linus needed and more. But there was no discussion about this.

Close by, Larry McVoy asked Andrea to stop biting the hand that is held out to you. A couple posts later, Larry remarked that Andrea was not doing significant work in the kernel, and so did not deserve respect. Andrea pointed out that he had played a major role in the development of the Linux Virtual Memory subsystem, which he said was probably running on Larry's own systems. Larry said a Virtual Memory subsystem was child's play compared with his own accomplishments, particularly the VM subsystem he worked on for SunOS. At around this point Linus said:

Larry, I think you remember the good old days of SunOS, when 16MB of RAM was a lot, and people expected less of their hardware. In particular, interactive programs used to have a _tiny_ footprint. Often even under X.

Then we put Solaris, Motif and CDE on those suckers, and it was horrible.

Yeah, SunOS was nice. But I really think it's the access patterns that changed.

Elsewhere but close by, Linus said to Andrea, your lack of interest in BK does _not_ explain why you whine about it, and try to goad Larry, and just generally are nasty about it. He said that a person had the right to choose the license under which they released their own code, and that no one had the right to get mad about it. Elsewhere he reiterated that Andrea's comments were impolite and even offensive; but Roman Zippel came in with, You think this is impolite? I've been quiet lately in these flame wars, because I couldn't have staid that polite to an arrogant asshole, but I won't stay quiet when Larry can now insult other developers and gets away with it. If someone is whining around here, then it's only Larry. A lot of people are contributing to the kernel, but he is the only one constantly whining around that he should be treated special and makes silly threats. Can we please get cause and effect right here? Of course Larry is completely free to choose whatever license he wants, but advertising a stupid license in a free software environment will of course cause disagreement and complaints. There is _nothing_ anyone but Larry can do anything about it, but amazingly enough Larry manages to take every single complaint as personal insult and makes all of the bk flame wars worse than they already are.

Elsewhere, Eric W. Biederman said, There are subprojects that are currently using BK that you can't even get the code without BK. And the only reason they are using BK is they are attempting to following how Linux is managed. So having the Linux kernel development use BK does have some down sides. Linus replied, That's actually a pretty good point. I end up releasing "sparse" only as a BK archive, simply because I'm too lazy to care and there aren't enough people involved (and those that _are_ involved do actually end up re-exporting it as non-BK, but that doesn't invalidate your point). I don't know what the solution to it might be - but I don't think the reason they are using BK is that they are trying to emulate "the great kernel project". I know it wasn't for me - it's just that once you get used to BK, there's no way you'll ever go back to CVS willingly. Jeff Garzik affirmed that all his new projects used BitKeeper, because it was so much better than CVS. Linus also said, As Larry will tell you, the technical problems are bigger than you imagine. So a BK killer won't be coming any time soon, methinks.

Elsehwere, Eric remarked that the arch tool did not handle distributed repositories or repo-to-repo merges very well, and Miles Bader replied, Are you are kidding? Arch is _insanely_ good at handling both distributed repositories and merging -- those are if anything its greatest strengths. Everyday development of tla (the latest/greatest arch implementation) involves many people with their own repositories, merging back and forth. And Davide Libenzi added, I definitely agree. It's about a couple of months that I'm playing with it and I have to say that it works great with distributed development. It basically born with that as the very first design rule. It also look very stable AFAICS. And, the old collection of shell scripts (that I didn't like in the beginning) is shaping out toward C code. In three words, I like it. I cannot compare it to bk because I never used it (not because of the license, and not even for political/personal reasons, but because I haven't had any time to do it in the past), and I am sure it still lacks of some useful features when matched with bk, but the fundamentals are definitely there.

Software Suspend

Nigel Cunningham announced:

This is to announce that LinuxFund.org (http://www.linuxfund.org) have kindly agreed to support me while I work on Software Suspend full time for a while, beginning 1 October.

This development should lead to a faster completion of the 2.4 version, and a faster release of the port to 2.6. Lord willing, a test version of Software Suspend for the 2.6 kernel that has all the features of the 2.4 version will be available within a couple of weeks.

Several folks offered their congratulations.

Networking Power Management: ACPI Mans Rullgard

Mans Rullgard asked about VMWare under Linux 2.6, as the kernel modules would no longer compile with recent kernels. The vmmon module in particular gave big errors, and Mans could find nothing about it on google. Martin Zwickel and Petr Vandrovec said that the problems were probably addressed in 'vmware-any-any-update40'. Petr added, And except that this patch makes thing compilable, it also makes driver a bit friendlier to the MM subsystem, it allows you to use VMware on 4G/4G host, and it properly handles bridged networking on adapters using hardware (or pseudohardware...) Tx checksumming (although only for IPv4 due to features of dev_queue_xmit_nit). Jan Rychter added, For those who run VMware on notebooks with ACPI, another patch is necessary, otherwise ACPI C-states handling doesn't notice VMware and as a result the guest system is unbearably slow. Petr asked, If this patch is for vmmon, can you share it with VMware (or with me and I'll then share it with VMware) ? I cannot explain why ACPI does not notice that kernel is spending about 99% of time in the kernel, being very busy with hard work... Jan didn't reply on the list, but in his earlier post he'd also asked if VMWare rolled patches like this back into their own sources, for public release, and Petr said, Yes. Currently VMware's & mine code is identical except that mine vmmon supports all released products since VMware 2.0.0 through VMware express, GSX & so on up to the VMware 4.0.2, while VMware's code supports only product it is shipped with. And you need C++ (for templates which are used for generating code for different product versions) with mine code, while you get one unwind template instance from VMware.

FS: sysfs

Ingo Molnar announced:

in the recent boom of buffer-overflow bugs in various open-source packages i got lots of requests for exec-shield being ported to various popular kernel trees. Here's the latest update of exec-shield:

against vanilla 2.6.0-test5:

redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-G2

against vanilla 2.4.22:

redhat.com/~mingo/exec-shield/exec-shield-2.4.22-G2

against 2.4.22-ac + NPTL:

[ redhat.com/~mingo/nptl-patches/nptl-2.4.22-ac1-A2 ]

redhat.com/~mingo/exec-shield/exec-shield-2.4.22-ac1-nptl-G2

Changes in this exec-shield version:

  • more refined support for PIE binaries (Position Independent Executables
    • a feature of latest binutils)
  • complete randomization of the whole address space [except the static binary mappings for non-PIE binaries]. Randomized executable mappings, heap, data mappings, stack, env/argv/aux spaces. With PIE binaries there's not a single constant address left.
  • ability to turn off exec-shield without changing the binary. (try 'setarch i386 /bin/cat /proc/self/maps'.)
  • various compatibility features and fixes.
  • randomization can be turned off via /proc/sys/kernel/exec-shield-randomize.

valid /proc/sys/kernel/exec-shield levels are:

= 0 exec-shield disabled
= 1 exec-shield on PT_GNU_STACK executables [ie. binaries compiled with newest gcc]
= 2 (default) exec-shield on all executables

value 1 is recommended with glibc and gcc versions that support PT_GNU_STACK all across the spectrum. (Fedora Core test2 [released yesterday] includes all of this and all applications were recompiled to have valid PT_GNU_STACK settings.) On other systems the value of '2' is recommended, use setarch for those binaries that cannot take exec-shield [eg. Loki games].

Valdis Kletnieks was really happy to see this, saying, I'm using a fairly current Rawhide here (within last 2 weeks or so). Applied with 2 or 3 minor conflicts and a few fuzz/delta messages against -test5-mm4 (I have a refactored patch if anybody is interested). It booted OK, seems to be working well enough that e-mail and XFree (even with the evil binary NVidia driver) are functional. Ingo remarked, btw., i have a patch against Linus' latest, -bk12 too: redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-bk12-G2

Muli

Maciej Zenczykowski requested:

I'm wondering if there is any way to provide per process bitmasks of available/illegal syscalls. Obviously this should most likely be inherited through exec/fork.

For example specyfying that pid N should return -ENOSYS on all syscalls except read/write/exit.

The reason I'm asking is because I want to run totally untrusted statically linked binary code (automatically compiled from user submitted untrusted sources) which only needs read/write access to stdio which means it only requires syscalls read/write/exit + a few more for memory alloc/free (like brk) + a few more generated before main is called (execve and uname I believe).

Currently I'm running the code in a chroot'ed environment (to an empty dir) under a 'nobody' uid/gid with no open fd's except for std in/out/err with limits for mem, processor usage, open files, processes (to 1), etc. Obviously this still allows calling code like 'time', 'getuid', etc and the like. Modifying the compiler (or removing the headers) won't help since at worst I can code it in asm in the source or even in a plain byte table.

I have a working (very much a hack) patch which turns of all but 7 (or so) of the syscalls (via pseudo-bitmaps).

Basically my question is: has this been done before (if so where/when?), what would be considered 'the right' way to do this, would this be a feature to include in the main kernel source?

Joe McClain recommended Systrace. Chris Wright also said to Maciej, A simple LSM module can do this for you. It will have a little more overhead than denying at the syscall entry point, but it's certainly going to be more flexible. Muli Ben-Yehuda also replied to Maciej, saying, syscalltrack can do it, per executable / user / syscall parameters / whatever, but it's per syscall. Writing a perl script or C program to iterate over the supplied syscall list and write the allow/deny rules is pretty simple. Also, syscalltrack is meant for debugging, not security, so if you want something that's 100% tight you'd better go with one of the Linux security modules based on the LSM framework.

FS: CIFS FS: ramfs Networking Samba Alan Cox Jeremy Allison

For earlier discussions of this, see , and . This time, Andrew Miklas began the current thread with:

A few months ago, I wrote to the kernel list describing the relationship between Linksys (now business unit of Cisco Systems), their WRT54G 802.11g wireless home gateway, and Linux. At the time, we had recently discovered that the WRT54G was using a great deal of software made available under the GPL, but was not giving credit to the authors, or providing the source as required by the GPL.

After a bit of public pressure, Linksys posted their "GPL Code Center" [1], where they claim that "the GPL source code contained in this product is available for free download" [2]. Shortly after the code center was made available, a group of developers pointed out to Linksys that their source code, particularly their Linux kernel code, was incomplete.

Previously, it was thought that the WRT54G source releases had only neglected to include the source code for the various kernel modules used to run the ethernet and wireless interfaces. However, at this time, it is clear that the kernel proper of the WRT54G itself has had functionality added to it. This functionality is not present in the kernel code that Linksys has provided at their "GPL Code Center".

That is to say, there is code STATICALLY LINKED with the Linux kernel running this device that is not present in the source download. This code seems to be shared between the Broadcom ethernet and wireless chips. It appears to be primarily responsible for configuring the Sonics' SiliconBackplane and handling DMA transactions for both devices.

==========================================

The incompleteness of the kernel source can be demonstrated as follows:

Method 1
------------------------------------------

  1. Download the kernel source provided by Linksys from:

    http://www.linksys.com/support/opensourcecode/wrt54g/1.30.7/kernel-2.4.5.tgz
    MD5SUM: 51a8b64c3ab674350a8830f21ddec817

    (Note: at this time, the kernel source provided for firmware versions 1.30.1, 1.30.7, and 1.41.2 are identical, so it doesn't actually matter which one you download.)

  2. Untar the archive and run:
    make xconfig
  3. Notice it fails:
    drivers/net/Config.in: 5: unable to open drivers/net/hnd/Config.in
    make[1]: *** [kconfig.tk] Error 1
    make[1]: Leaving directory `/home/andrew/linux-kernel/linux/scripts'
    make: *** [xconfig] Error 2
  4. Run:
    make config
  5. When it asks:
    Network device support (CONFIG_NETDEVICES) [Y/n/?]
    Answer "Y"
  6. Notice it fails:
    scripts/Configure: line 5: drivers/net/hnd/Config.in: No such file or directory
    make: *** [config] Error 1
  7. As you can see, it is not possible to compile a kernel with the provided build utilities with networking support.

Method 2
------------------------------------------

  1. Download a copy of the firmware image for the 1.30.7 firmware from:
    ftp://ftp.linksys.com/pub/network/WRT54G_1.30.7_US_code.bin
    MD5SUM: cc39c85f4c9fd065543fa2fd0a14be29
  2. Extract the CramFS filesystem and kernel image:
    dd if=WRT54G_1.30.7_US_code.bin of=cramfs.image bs=786464 skip=1
    dd if=WRT54G_1.30.7_US_code.bin bs=60 skip=1 | zcat > kernel

  3. Mount the filesystem, and run "nm" against the wireless driver:
    (You'll need to have CramFS compiled in or available as a module.)
    mount cramfs.image /mnt/rom -o loop
    nm /mnt/rom/lib/modules/2.4.5/kernel/drivers/net/wl/wl.o > wl_syms.txt

    For convenience, a copy of the output of this command is available at:
    http://www.busybox.net/linksys/wl_syms.txt
    MD5SUM: 08cd2f02d91dd63a0d61a45154adedeb

  4. Notice that the driver wl.o makes several imports from the kernel that are not included in a stock 2.4.5 kernel. In particular, note that the symbols bcm_*, pkt*, dma_*, sb_*, osl_*, and srom_* are imported by the module, but not included in the kernel source.
  5. Verify that the symbols aren't provided by another module by running "nm" on them.

  6. Download a copy of ksyms_sorted.txt:
    http://www.busybox.net/linksys/ksyms_sorted.txt
    MD5SUM: a42b8d97176b95706480301f245bc52b

    This is a copy of the /proc/ksyms file from a running WRT54G (firmware 1.30.7). The entries have been sorted by address to make reading it a bit more convenient.

    The raw, unsorted output is also available:
    http://www.busybox.net/linksys/ksyms.txt
    MD5SUM: 90ce734d11a6a26205cb5d29f12541d9

Find the symbols that were missing from the kernel image:

80094f18        bcm_strtoul
800950a4        bcm_atoi
80095100        deadbeef
80095140        prhex
80095258        prpkt
800952bc        pktcopy
800953a4        pkttotlen
800953c4        bcm_ether_ntoa
80095420        bcm_ether_atoe
800954a4        bcm_parse_tlvs
800954f4        pktqinit
80095508        pktenq
8009554c        pktdeq
8009558c        getvar
8009563c        getintvar
80095674        bcm_mdelay
800956b4        crc8
800956f4        crc16
8009574c        crc32
800958c0        dma_attach
80095a64        dma_detach
80095ad0        dma_txreset
80095be0        dma_rxreset
80095c40        dma_txinit
80095ca4        dma_txenabled
80095ccc        dma_txsuspend
80095ce0        dma_txresume
80095cf8        dma_txsuspended
80095d28        dma_txstopped
80095d40        dma_rxstopped
80095d58        dma_fifoloopbackenable
80095d6c        dma_rxinit
80095dc4        dma_rxenable
80095ddc        dma_rxenabled
80095e04        dma_txfast
80095ff4        dma_tx
8009629c        dma_rx
80096380        dma_rxfill
800964e0        dma_txreclaim
80096530        dma_getnexttxp
80096604        dma_rxreclaim
80096648        dma_getnextrxp
800966cc        dma_dumptx
80096760        dma_dumprx
800967f4        dma_dump
80096824        dma_getvar
80096870        osl_pktget
80096934        osl_pktfree
80096a98        osl_pci_read_config
80096ad0        osl_pci_write_config
80096b00        osl_pcmcia_read_attr
80096b08        osl_pcmcia_write_attr
80096b10        osl_assert
80096bb8        sb_attach
80096c38        sb_kattach
80096f30        sb_coreid
80096f48        sb_coreidx
80097028        sb_corevendor
8009703c        sb_corerev
80097050        sb_coreflags
800970b8        sb_coreflagshi
80097120        sb_iscoreup
8009736c        sb_detach
80097504        sb_setcoreidx
8009761c        sb_setcore
80097660        sb_chip
80097668        sb_chiprev
80097670        sb_boardvendor
80097678        sb_boardtype
800979a0        sb_boardstyle
80097a48        sb_bus
80097a50        sb_corelist
80097a88        sb_coreregs
80097a90        sb_taclear
80097b04        sb_commit
80097b8c        sb_core_reset
80097d04        sb_core_tofixup
80097dc0        sb_core_disable
80097f34        sb_watchdog
80097f98        sb_pcmcia_init
8009803c        sb_pci_setup
80098198        sb_base
800981e0        sb_size
8009823c        sb_coreunit
800982b0        sb_clock_rate
80098548        sb_clock
800985f4        sb_gpiosetcore
80098614        sb_gpiocontrol
80098680        sb_gpioouten
800986e4        sb_gpioout
80098748        sb_gpioin
800987a8        sb_gpiointpolarity
8009880c        sb_gpiointmask
80098870        sb_dump
80098990        srom_var_init
80098a10        srom_read
80098b08        srom_write
80098d7c        srom_parsecis

8014ba80        bcm_ctype

You can also find the symbol names in the kernel by grepping through the output of "strings" on the kernel image produced in step two.

Note that the addresses at which these symbols are located are used by the kernel proper. Kernel modules get loaded to a different address range. Also note that these symbols are surrounded by other symbols included in a stock Linux kernel.

==========================================

The above analysis shows that the kernel source provided by Linksys cannot be compiled in a configuration that would be of use on the WRT54G. Even if it could, functions necessary for the networking subsystem would be missing, making the loading of the ethernet and wireless drivers impossible. Clearly, the kernel source that Linksys provided cannot be used to recreate the kernel that they are shipping with their product. Therefore, they have been, and still remain in violation of the GPL.

Until now, we have held off highlighting this fact in the hopes that Linksys would realize their omission and correct it. Unfortunately, after three releases of their firmware (1.30.1, 1.30.7, 1.41.2), and numerous notices from many individuals explaining this oversight, it seems that Linksys has no intention of correcting this problem.

The lack of complete source code for the kernel present on the WRT54G is hindering a number of very interesting development efforts. The SeattleWireless WRT54G group [3] is working toward creating completely new firmware images for the WRT54G. However, they are unable to create a kernel for this device, largely because any kernel they compile will be unable to load the modules necessary to support the ethernet and wireless devices. This limits the functionality that they can add to their project.

The Linux Broadcom 4301 project [4] is attempting to create a driver to support the Broadcom 43xx series of wireless devices on generic hardware. Their work would be greatly lessened if they could at least be sent the source code for the parts of the wireless driver implemented in the kernel proper.

It is also worth noting that this is not the only Linksys device that uses Linux and other software licensed under the GPL without adhering to the license. For example, the Samba team has expressed some concern over the use of Samba in the Linksys EFG80 network accessible storage device [5].

Also, the following products seem to be based on the same general design as the WRT54G, and therefore suffer from the same problem described above. However, at this time, no source for either device is available from the "GPL Code Center". - Linksys WRT55AG Dual-Band Wireless Router [6] - Linksys WAP54G Wireless-G Access Point [7]

Unfortunately, neither group knows how to proceed in obtaining this code. While Linksys has shown some interest in releasing the source for software licensed under the GPL, they have not responded to the issues outlined in this post.

If anyone wishes to contact Linksys concerning this matter, we'd recommend you try the following address: [opensource () linksys ! com]. However, since we have never received a response to messages directed at this box, you may want to CC any messages to [pr () linksys ! com] or perhaps [mailroom () linksys ! com] as well. With any luck, we will eventually sort out this issue.

The data contained in this post were produced by many individuals working on a variety of Linksys products. Therefore, while every effort has been made to ensure that the information contained in this post is accurate, it is entirely possible that we've made some errors. If that is the case, please let us know and we will correct the mistake.

Signatories:
(in alphabetical order)

Jeremy Allison
jra () samba ! org
Samba Co-Author

Erik Andersen
andersen () codepoet ! org
Busybox Maintainer

Kendall Blake
kendallb () eden ! rutgers ! edu
Linux Broadcom 4301 Driver Project

Jim Buzbee
Jim () Buzbee ! net
WRT54G Hacker

Alan Cox
alan () lxorguk ! ukuu ! org ! uk
Linux Kernel

Rob Flickenger
rob () oreillynet ! com
SeattleWireless WRT54G Project

Christopher R. Hertel
crh () samba ! org
Samba Team and jCIFS Team Member

Imre Kaloz
kaloz () dune ! hu

Andrew Miklas
public () mikl ! as
Linux Broadcom 4301 Driver Project

Brett Wooldridge
brettw () riseup ! com
Linux Broadcom 4301 Driver Project

===========================================

[1] Linksys GPL Code Center
http://www.linksys.com/support/gpl.asp

[2] WRT54G firmware download page
http://linksys.com/download/firmware.asp?fwid=178

[3] SeattleWireless
http://seattlewireless.net/index.cgi/LinksysWrt54g

[4] Linux Broadcom 4301 Driver Project
http://linux-bcom4301.sourceforge.net/

[5] Linksys EFG80 Network Attachable Storage Product Page
http://linksys.com/products/product.asp?prid=447&grid=

[6] WRT55AG Dual-Band Wireless A+G Broadband Router
http://linksys.com/products/product.asp?prid=537&grid=

[7] WAP54G Wireless-G Access Point
http://linksys.com/products/product.asp?prid=575&grid=
For some reason, there doesn't appear to be a link to the firmware from this page, but it can be downloaded from the following address:
ftp://ftp.linksys.com/pub/network/wap54g_1.08_fw.zip
MD5SUM: 26751b70480b3762eb382c7ccaace138

Rob Landley suggested that probably Linksys itself was unaware of the problem, or why would they create a GPL Code Center for incomplete code? He guessed that probably the technical guys who knew all the relevant details might have left the project or the company, leaving only management or an outsource company to deal with it. He suggested, Keep the pressure up, but be nice and give them some time to audit their codebase. Firmware development was probably outsourced to india or taiwan or something, and Linksys (nee Cisco) is quite possibly furious at whoever they outsourced this to for putting them in this position in the first place...

Erik Andersen replied:

Nope. It is absolute certainty they know about it. I had my lawyer contact them months ago, and the cisco Legal department was made aware of this and other problems, and responded that

"the Linksys technical folks are digging into your questions - all the the software in question is from Linksys' suppliers (Linksys doesn't have the source code to this software), so we have to work with these suppliers to address any concerns."

but that was July 15 and I have heard nothing substantive from them since that time.

He also said:

How much niceness do they need? I had my lawyer send the first of several letters (nice and polite) on 8 May... After several additional letters (increasingly less polite) my lawyer and I were finally contacted by Cisco on June 20. They stated at that time "We are in the process of determining what code is subject to the distribution obligation; once we have done so, all such code will be made available under the terms of the GPL."

On July 10 they informed us they were setting up their GPL Code Center. We informed them on that data that (at least) the WRT55AG, and WAP54G products also contain Linux and need to have the GPL'd sources published. We also informed the Cisco legal dept on July 10 that they have have not provided source code for 'libnetconf' (which staticly includes iptables/netfilter code), and since they have shippied zillions of these things, they are obligated to release source not just libnetconf, but also all applications linked with libnetconf.

They have not yet addressed that issue despite 2.5 months passing since their legal department was informed. When combined with the issue of the broken kernel they distribute, it is hard to argue they have acted in good faith at complying.

Rik van Riel replied:

I have no idea who their supplier is, but it's not unthinkable that the supplier is trying to take advantage of the situation by asking extraordinary amounts of money from Cisco and/or Linksys in order to give them the source code.

Hell, their contractor could even have removed the source code from their systems already ("mmm, the disk is full, lets remove some old projects").

Personally I'd like to treat Cisco and Linksys nicely for the time being, since the full extent of the nasty situation they're in could well be covered in an NDA with their contractor, making them unable to tell us the reasons for the way things are going.