Cisco ESS 3300 round 3 of N

Fri Feb 9 00:43:56 UTC 2024

This kernel-only source candidate contains two packages, kernel-17.03.06.zip and kernel-modules-17.03.06.zip - for ease of reference, here are the contents of the How-To-Compile-The-Kernel.txt file from the first package (which was the first file we ran across in looking for a human-readable file to begin with):

1. Install Ubuntu
	https://ubuntu.com/tutorials/install-ubuntu-desktop?#1-overview

2. Install an cross compiler and tools
	sudo apt-get install build-essential gcc-aarch64-linux-gnu

3. Copy config file to source directory
	cat defconfig > .config

4. Build kernel
	make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-

5. Install kernel
	sudo ARCH=mips make CROSS_COMPILE=aarch64-linux-gnu- install

An astute reader may notice some issues, particularly with the last step.  This is indeed where we ran into problems.  In particular, when we tried to run the "Install kernel" step (after completing the other steps), we were greeted with the following:

*
* Restart config...
*
*
* Machine selection
*
System type
  1. Generic board-agnostic MIPS kernel (MIPS_GENERIC) (NEW)
  2. Alchemy processor based machines (MIPS_ALCHEMY) (NEW)
[...]

It appears that the kernel configuration tool recognized that the ARCH we built with ("arm64"), and the ARCH we were trying to install with ("mips"), were very different, and therefore it attempted to rebuild everything with the new ARCH value ("mips"), but it needed to ask us for a bunch of configuration settings first, since there were MIPS-specific options not specified by Cisco's configuration file.

We decided that, even if we picked some default options here, it was unlikely to result in a kernel executable that would run on the Cisco ESS 3300, so we aborted this step and tried to fix the "Install kernel" step instead.

In particular, we ran this command instead:

$ sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- install

This step did complete with a return value of 0, but with a lot of warnings, and other concerning output, such as the following:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.0-15-generic
Found initrd image: /boot/initrd.img-6.5.0-15-generic
Found linux image: /boot/vmlinuz-6.2.0-26-generic
Found initrd image: /boot/initrd.img-6.2.0-26-generic
Found linux image: /boot/vmlinuz-4.14.240
Found initrd image: /boot/initrd.img-4.14.240

So it appeared to have installed the just-built kernel (which was a version 4.14.240 kernel) onto the system I was building on, not onto the Cisco ESS 3300.  Now this is a problem for a number of reasons, most notably that, even with the attempted fix above, Cisco's source candidate still does not contain "the scripts used to control compilation and installation of the executable" since, after going through all the provided scripts, this kernel had still not been installed onto the Cisco ESS 3300.  Also, having this kernel installed onto the system I was building on meant that it might not boot anymore, since this kernel was intended for an entirely different architecture ("arm64") than the one I was building on ("x86_64").

But I tried restarting anyway to see if somehow it might do something with this kernel.  However, it did not, instead opting to automatically use one of the compatible kernels instead.  Namely, "uname -a" showed the following after a reboot:

Linux [hostname] 6.5.0-15-generic #15~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 12 18:54:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Now Cisco did provide a second file as part of this source candidate (kernel-modules-17.03.06.zip).  So we looked for a file that might contain some "scripts used to control compilation and installation of the executable" and discovered How-To-Build-Kernel-Modules.txt in the root directory, which contained the following:

1. Change directories

	cd kernel-modules/modules

2. Build Modules

	make ARCH=arm64 -C <kernel source directory> CROSS_COMPILE=aarch64-linux-gnu- M=$PWD

So we tried these steps, replacing "<kernel source directory>" with "$HOME/kernel-17.03.06" (we checked /usr/src for the 4.14.240 kernel source, but it wasn't there despite the "make install" step above - in any case, Cisco should be explicit about which "kernel source directory" they mean), but the "make" step failed with the following:

  CC [M]  .../kernel-modules-17.03.06/kernel-modules/modules/lfts/lfts_intf.o
In file included from .../kernel-modules-17.03.06/kernel-modules/modules/punt_inject_api/netlink_punt_inject_api.h:23,
                 from .../kernel-modules-17.03.06/kernel-modules/modules/lfts/lfts_intf.c:66:
.../kernel-modules-17.03.06/kernel-modules/modules/punt_inject_api/transport_punt_inject_api.h:23:10: fatal error: binos/in_ext.h: No such file or directory
   23 | #include "binos/in_ext.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:330: .../kernel-modules-17.03.06/kernel-modules/modules/lfts/lfts_intf.o] Error 1
make[1]: *** [scripts/Makefile.build:588: .../kernel-modules-17.03.06/kernel-modules/modules/lfts] Error 2
make: *** [Makefile:1552: _module_/.../kernel-modules-17.03.06/kernel-modules/modules] Error 2
make: Leaving directory '.../kernel-17.03.06'

The return code of this "make" step was 2, confirming that an error had occurred.  This seems like some sort of problem with the include paths for this compilation step, since "binos/in_ext.h" does exist in one directory that we found, but apparently the compilation scripts did not properly indicate that, so the compiler couldn't find it.  Cisco needs to fix this in order for the compilation to complete.

We chose not to try and edit the include paths ourselves since, given our experience with the other package, it was unlikely that the "make" step would allow us to make practical use of the results anyway (that is, to install modified versions of these modules onto the Cisco ESS 3300 so we could use our changes on the device they were intended for).

Because the How-To-Build-Kernel-Modules.txt file ended with this "make" step, and contained no further information about how one might install the result onto the device (i.e. it did not contain "the scripts used to control compilation and installation of the executable"), we decided to wait for Cisco to respond to our report so all of the necessary problems could be corrected by the device manufacturer instead of us having to guess what "the scripts" (which Cisco already has, since Cisco used them to install Linux onto the device themselves) might be.

To view this candidate and download the source candidate and firmware image, visit:
https://sfconservancy.org/usethesource/candidate/cisco-ess-3300-round-3-of-n/

--
Denver Gingerich
(Via https://sfconservancy.org/usethesource/)