Linksys WRT54G: Part 2

Linksys WRT54G: Part 2

[Andrew Miklas]

Hi,


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

Re: Linksys WRT54G: Part 2

[Erik Andersen]

On Sun Sep 28, 2003 at 07:14:24PM -0400, Andrew Miklas wrote:
> 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".

In addition, every program that links against libnetconf also
needs to have source released, as the libnetconf source is
apparently just parts ripped out from iptables....

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linksys WRT54G: Part 2

[Rob Landley]

On Sunday 28 September 2003 18:14, Andrew Miklas wrote:

> 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".

It's probable that Linksys itself didn't know this.  (They wouldn't go to the 
trouble of creating a GPL Code Center to post knowingly incomplete code.)

At every proprietary softare company I've ever worked for, and this sort of 
knowledge was limited to one or two individual engineers, who often left the 
project when it shipped.  The support guys often don't know diddly, and 
management is seldom even aware how much there IS to know.

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...

> 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].

And there will be more in the future.  Proprietary software companies aren't 
used to having _access_ to code without the obigations for using it already 
having been discharged.  (Usually up-front cash payments, although sometimes 
it's a percentage of revenues, and sometimes it's bartering for other code or 
bundling deals or whatever.)

And even though many of them then go on and violate that license six ways from 
sunday afterwards (by simply not caring in the rush to ship), they're not 
used to being called on it afterwards.  Open source doesn't just do 
distributed development and debugging better than the proprietary guys, we do 
distributed license auditing. :)

Query: should this kind of thing have its own mailing list?  There are a 
number of organizations that might want to pool their resources on these 
issues (off the top of my head, OSI, Linux International, and OSDL spring to 
mind.  The FSF would also be a logical candidate, if logic applied to the 
FSF, but the absence of ftp.gnu.org/pub/decss strongly implies it doesn't.)

> 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.

Most likely, management hasn't budgeted the man hours to audit the rest of 
their codebase yet.  I'd guess they just want to do the minimum amount of 
work to make the problem go away, and probably thought they already had...

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

There's an Alanis Morisette song about Active Server Pages devoted to GPL 
code...

Rob

Re: Linksys WRT54G: Part 2

[John Bradford]

Quote from Andrew Miklas <public@mikl.as>:

> 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.

Can't the copyright holders use the DMCA in this case?

John.

Re: Linksys WRT54G: Part 2

[root]

> 
> On Sunday 28 September 2003 18:14, Andrew Miklas wrote:
> 
> > 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
<snip>
> Query: should this kind of thing have its own mailing list?  There are a 
> number of organizations that might want to pool their resources on these 
> issues (off the top of my head, OSI, Linux International, and OSDL spring to 

I (along with quite a few others I suspect) read linux-kernel for 
(amongst other things) interesting things about linux.
Announcements of ports to new machines seem to be entirely on-topic,
even if it's by a third party that found linux in their toaster.
I don't see a functional difference between "I intend to port linux to my
toaster, can people help", and "I want to get source for the linux running
on my toaster, can people help".

I have purchased a WRT54G on the basis that it (through the efforts of
the seattlewireless group and many others) contains a running linux 
enviroment that can be customised to an extent that lets me do lots of
things that would otherwise be impossible without a much more expensive
device.

I intend to write to linksys and inform them of this, along with the 
saying that I'll buy more if I can get full enough source to compile
kernels and make firmware.

Re: Linksys WRT54G: Part 2

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Mon, 29 Sep 2003 09:08:58 BST, John Bradford <john@grabjohn.com>  said:
> Can't the copyright holders use the DMCA in this case?

Hmm.. anti-circumvention?  I don't see any joy there. 17 USC 1201 doesn't apply.

And I doubt a corporate FTP server qualifies for the ISP 'safe harbor' exemption
except possibly for a 'people/*' subtree where engineers are known to put stuff
without formal corporate review.  You'd have to make a *big* reach to make
17 USC 512 apply here - and I'm not convinced that sending a 512 takedown
order is the right way to send the message we want sent.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linksys WRT54G: Part 2

[Erik Andersen]

On Mon Sep 29, 2003 at 01:03:16AM -0500, Rob Landley wrote:
> It's probable that Linksys itself didn't know this.  (They wouldn't go to the 
> trouble of creating a GPL Code Center to post knowingly incomplete code.)

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.

> At every proprietary softare company I've ever worked for, and this sort of 
> knowledge was limited to one or two individual engineers, who often left the 
> project when it shipped.  The support guys often don't know diddly, and 
> management is seldom even aware how much there IS to know.
> 
> 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...

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.

> And there will be more in the future.  Proprietary software companies aren't 
> used to having _access_ to code without the obigations for using it already 
> having been discharged.  (Usually up-front cash payments, although sometimes 
> it's a percentage of revenues, and sometimes it's bartering for other code or 
> bundling deals or whatever.)
> 
> And even though many of them then go on and violate that license six ways from 
> sunday afterwards (by simply not caring in the rush to ship), they're not 
> used to being called on it afterwards.  Open source doesn't just do 
> distributed development and debugging better than the proprietary guys, we do 
> distributed license auditing. :)

Yes I know.  My dad (a lawyer) tries to help me with handling
these.  But it takes time and effort, and GPL violating products
are being released faster than I can mail letters.... 

> Query: should this kind of thing have its own mailing list?  There are a 
> number of organizations that might want to pool their resources on these 
> issues (off the top of my head, OSI, Linux International, and OSDL spring to 
> mind.  The FSF would also be a logical candidate, if logic applied to the 
> FSF, but the absence of ftp.gnu.org/pub/decss strongly implies it doesn't.)

Regarding Linksys, Bradley Kuhn of the FSF has worked with a
number of the Linksys violatees, starting in the middle of June.
We had a few conference calls and whatnot.  But I've not heard
from them since early July -- I expect other more pressing
concerns have taken precedence.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linksys WRT54G: Part 2

[Rik van Riel]

On Mon, 29 Sep 2003, Erik Andersen wrote:

>     "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.

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.

Hmmm, guess I _should_ mail the FSF as one of the
copyright holders, just so I'm in the group and can
argue for a friendly approach ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Linksys WRT54G: Part 2

[Pau Aliagas]

On Mon, 29 Sep 2003, Rik van Riel wrote:

> On Mon, 29 Sep 2003, Erik Andersen wrote:
> 
> >     "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.

> Hmmm, guess I _should_ mail the FSF as one of the
> copyright holders, just so I'm in the group and can
> argue for a friendly approach ;)

Buffalo (buffalotech.com) have also a bunch of products, MIPS based
wireless routers and bridges, running Linux. I could not find the driver
of the wireless cards -based on Broadcom 4306 chips- in the kernel bundle
they distribute in their website:

http://www.buffalotech.com/wireless/support/faq/index.php)
http://www.buffalotech.com/wireless/support/faq/GPL_linux_source.zip

Maybe I oversaw them.

Nor they provide drivers for the wireless cardbus. I wrote them 
about it but received no answer.

Pau