we should install.  It would be ideal to find

\href{http://librecmc.org/librecmc/wiki?name=Tp+MR3020}{instructions similar

  to these} in the README itself.  However, application of the reasonableness

standard indicates compliance, since a knowledgeable user was able to

determine the proper course of action.

\section{U-Boot Compilation}

%FIXME: link to u-boot reflash, maybe put it in log-output dir?

The investigator then turned his attention to the file,

``u-boot\verb0_0reflash'' instructions.  These instructions explained how to

build and install the bootloader for the device.

The investigator followed the instructions for compiling U-Boot, and found

them quite straight-forward.  The investigator discovered two minor

annoyances, however, while building U-Boot:

\begin{itemize}

 \item The variable \verb0$U-BOOT_SRC0 was used as a placeholder for the name

   of the extracted source directory.  This was easy to surmise and was not a

   compliance issue (per the reasonableness standard), but explicitly stating

   that at the top of the instructions would be helpful.

\label{thinkpenguin-glibc-214-issue}

\item Toolchain binaries were included and used by default by the build

  process.  These binaries were not the appropriate ones for the

  investigator's host system, and the build failed with the following error:

\lstset{tabsize=2}

\begin{lstlisting}

mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6:

   version `GLIBC`_2.14' not found

     (required by mips-librecmc-linux-uclibc-gcc.bin)

\end{lstlisting}

   (The

\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-build_fail.log}{complete

  log output from the failure} is too lengthy to include herein.)

   This issue is an annoyance, not a compliance problem.  It was clear from

   context that these binaries were simply for a different architecture, and

   the investigator simply removed ``toolchain/bin'' and used a symlink to

   utilize the toolchain already built earlier (during the compilation

   discussed in \S~\ref{thinkpenguin-main-build}):

\lstset{tabsize=2}

\begin{lstlisting}

  $ ln -s \

  ../../staging_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin \

  toolchain/bin

\end{lstlisting}

   After this change, the U-Boot build completed successfully.

\end{itemize}

The

\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-finish_build.log}{full

  log of the build} is not included herein due its size (approximately 3.8K

of text).  After that, the investigator found a new U-Boot image in the

``bin'' directory.

\section{Root Filesystem and Kernel Installation}

The investigator next tested installation of the firmware.  In particular,

the investigator connected the TPE-NWIFIROUTER to a local network, and

visited \url{http://192.168.10.1/}, logged in, and chose the option sequence:

``System $\Rightarrow$ Backup / Flash Firmware''.

From there, the investigator chose the ``Flash new firmware image'' section

and selected the

``librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin'' image from

the ``bin/ar71xx'' directory.  The investigator chose the ``v8'' image upon

verifying the physical router read ``v8.2'' on its bottom.  The investigator

chose the ``sysupgrade'' version of the image because this was clearly a

system upgrade (as a firmware already came preinstalled on the

TPE-NWIFIROUTER).

Upon clicking ``Flash image\ldots'', the web interface prompted the

investigator to confirm the MD5 hash of the image to flash.  The investigator

did so, and then clicked ``Proceed'' to flash the image.  The process took

about one minute, at which point the web page refreshed to the login screen.

Upon logging in, the investigator was able to confirm in ``Kernel Log''

section of the interface that the newly built copy of Linux had indeed been

installed.

The investigator confirmed that a new version of ``busybox'' had also been

installed by using SSH to connect to the router and ran the command

``busybox'', which showed the newly-compiled version (via its date of

compilation).

%FIXME: dg: can you get me  a screen shot for the Kernel Log above, and paste

%in the output of running busybox ?

%% \section{U-Boot Installation}

%% The U-Boot installation process is substantially more complicated than the

%% firmware update.  The investigator purchased the optional a serial cable

%% along with the TPE-NWIFIROUTER, in order to complete the U-Boot installation

%% per the instructions in'' -boot\verb0_0reflash''.

%% However, we were

%% only able to read data from the serial port; we were unable to interrupt the

%% boot process or access the U-Boot console to complete the U-Boot re-flash.  Here

%% are the steps we tried:

%% * We found the serial cable included was a USB serial adapter that had a male

%%   USB type A connector on one end and 4 female jumper wires at the other end.

%%   These female jumper wires were red, black, white, and green.

%% * The instructions did not specify how to connect these wires, but we were able

%%   to determine this in part using the "v8.4" image (close to our "v8.2" router)

%%   at \url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} .  Aside from

%%   power and ground (red and black), we did have to guess which of the wires was

%%   RX and TX.  By experimentation we found that green was RX and white was TX.

%%   When we tried the other way, we received no data to our serial console at boot

%%   time.

%% * We did have to use the included jumper pin gender changer with the USB serial

%%   adapter, which we put through the holes on the router's mainboard and then

%%   connected to the USB serial adapter.  The fit was fairly loose so it would be

%%   nice if future router versions included a tighter gender changer or (ideally)

%%   had the jumper pins soldered onto the board to begin with (so no gender

%%   changer would be required).

%% * We used 115200 8N1 as our serial console settings (with no hardware or

%%   software flow control).  This was tested with both the minicom and screen

%%   commands.  We found that if we connected all 4 wires on the USB serial adapter

%%   that the router would start without additional power and our console would

%%   receive the startup messages.  We could replicate the same behavior by

%%   omitting the power cable from the USB serial adapter (red wire) and connecting

%%   the main power adapter to the router instead.

%% * While we did see the U-Boot and kernel boot logs in our serial console, we

%%   were unable to interrupt the boot process as u-boot\verb0_0reflash indicated we

%%   should.  We suspect this is a misconfiguration of our serial console, but it's

%%   unclear exactly how it is misconfigured, as we were able to receive data fine

%%   (we just couldn't send data to the router).

%% * As a result, we were unable to complete the U-Boot installation test.  We did

%%   appreciate that installation instructions were included, though these

%%   instructions should be updated to include more specifics about connecting the

%%   serial cable.  Since ThinkPenguin does have the option to ship a serial

%%   adapter with the router, it would be helpful if instructions specific to that

%%   adapter were included, as the wiring configuration one should use was unclear.

%% * Additionally, instructions for removing the router's case should be included.

%%   We found that the two screws that needed removal to open the case were hidden

%%   underneath rubber feet on the case.  Indicating which feet need removal to

%%   unscrew the case would be helpful.  The instructions should also note that the

%%   case needs to be carefully separated once the screws are removed; it

%%   effectively snaps apart, but care must be taken to avoid breaking the plastic

%%   fasteners that keep the case together after the screws are removed.

\section{Firmware Comparison}

To ensure the CCS did indeed correspond to the firmware original

installed on the TPE-NWIFIROUTER, the investigator compared the built

firmware image with the filesystem originally found on the device itself.

The comparison steps were as follows:

\begin{enumerate}

\item Extract the filesystem from the image we built by running

  \href{https://gitorious.org/copyleft-org/gpl-compliance-scripts/source/master:find-firmware.pl}{find-firmware.pl}

  on ``bin/ar71xx/librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin''

  and then running

  \href{http://www.binaryanalysis.org/en/content/show/download}{bat-extratools}'

  ``squashfs4.2/squashfs-tools/bat-unsquashfs42'' on the resulting

  morx0.squash, using the filesystem in the new squashfs-root directory for

  comparison.

\item Login to the router's web interface (at \url{http://192.168.10.1/ }) from a computer that is

  connected to the router.

\item Set a password using the provided link at the top (since the router's

  UI warns that no password is set and asks the user to change it).

\item Login to the router via SSH, using the root user with the

  aforementioned password.

\item Compare representative directory listings and binaries to ensure the set of

  included files (on the router) is similar to those found in the firmware image

  we created (whose contents are now in the local squashfs-root directory).  In

  particular, we did the following comparisons:

  \begin{enumerate}

  \item List the /bin folder (``ls -l /bin'') and confirm the list of files is the same

    and that the file sizes are similar.

  \item Check the ``strings'' output of ``/bin/busybox'' to confirm it is similar in both

   places (similar number of lines and content of lines).  (One cannot directly

   compare the binaries because the slight compilation variations will cause

   some bits to be different.)

 \item Do the above two steps for ``/lib/modules'', ``/usr/bin'', and other directories with