This repository has been archived by the owner. It is now read-only.

Package nexmon: broadcom firmware patches to fix broadpwn and enable monitor mode #592

Open
Pneumaticat opened this Issue Sep 17, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@Pneumaticat
Contributor

Pneumaticat commented Sep 17, 2017

As mentioned in #513.

Repository is here.

Build instructions are only for Ubuntu/Raspberry Pi, and appear to require some 32-bit libraries that Alpine does not package.

I can think of three options, none of which are particularly fun:

  1. Package and maintain the required 32-bit libraries.
  2. Build firmware binaries and package them as blobs. (Not ideal for transparency.)
  3. Create ubuntu buildroot with docker and build them that way? ;) Just kidding, probably.

There's also the question of, if successfully packaged, do we ship all firmwares as one package, or split it into, e.g. nexmon_bcm4339, etc.? It seems like each chipset also has multiple patch sets -- bcm4339 has an anti_broadpwn patchset and the main nexmon patch.

Does anyone have any other ideas on how to package them?

EDIT: Also, as @ollieparanoid mentioned, we definitely have to disable statistics collection when building.

@Pneumaticat Pneumaticat changed the title from Package nexmon -- Broadcom firmware patches to fix broadpwn and enable monitor mode to Package nexmon: broadcom firmware patches to fix broadpwn and enable monitor mode Sep 17, 2017

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Sep 18, 2017

Member

From looking at the source: When using Nexmon as described in their README.md, you would use a few programs/libraries, that are not built from source, but contained as binaries in the git repository. That's where the 32bit library dependencies come from.

So to package it properly, we would build everything, that we don't already have, from source and use our own cross-compiler.

Here are my recommended first steps:

  • Set up a VM where you use it as expected by the developers, so it's easier to understand how the build system works
  • Disable the statistics reporting
  • Build the firmware files we want (at least one)
  • Figure out all dependencies, that we need to build the firmware files (there is a lot in the buildtools folder, e.g. the cross-compiler and the nexmon-gcc-plugin)

One we have that, I would recommend further brainstorming on how to do the actual packaging of the dependencies and firmware files, and how to handle the cross-compiling (see also: build internals).

I'm really excited about this topic \o/

Member

ollieparanoid commented Sep 18, 2017

From looking at the source: When using Nexmon as described in their README.md, you would use a few programs/libraries, that are not built from source, but contained as binaries in the git repository. That's where the 32bit library dependencies come from.

So to package it properly, we would build everything, that we don't already have, from source and use our own cross-compiler.

Here are my recommended first steps:

  • Set up a VM where you use it as expected by the developers, so it's easier to understand how the build system works
  • Disable the statistics reporting
  • Build the firmware files we want (at least one)
  • Figure out all dependencies, that we need to build the firmware files (there is a lot in the buildtools folder, e.g. the cross-compiler and the nexmon-gcc-plugin)

One we have that, I would recommend further brainstorming on how to do the actual packaging of the dependencies and firmware files, and how to handle the cross-compiling (see also: build internals).

I'm really excited about this topic \o/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.