Updates

[stryngs]

I have found your repo very useful as it made the Nexmon stuff, simple. As such, I want to give back and contribute.

What I did here was attempt to make it to where you can git pull this repo onto a RPI, and then run install.sh, versus the directions listed on:
https://whitedome.com.au/re4son/re4son-kernel/

I've done quite a bit of changes, so I'll list them out by type:

I've gone through install.sh and changed it to where it runs locally on the box, versus using apt to reach out to the Internet for the various .debs it might need. In this way, it is now a 100% offline installer.

I moved every .deb over to the folder repo, and sub-foldered accordingly. The subfolder externals consists of the .debs that make this an offline install capable repo. Please feel free by all means to make sure the hashes align and such for security purposes.

There is a subfolder of repo called wifi. This is where the bread and butter of my changes are. In that folder, you will find nexmon_1.0_all.deb. What this does is take your directions as listed in /usr/local/src/re4son-kernel_4*/nexmon/nexmon.txt, and it wraps them up into two nice shell scripts called injectionON and injectionOFF accordingly. In order to account for which modules are currently loaded, it will drop a PID file in /usr/local/src/nexmon/PID. In this way, even after a reboot, you can easily adjust back to a managed mode wifi state.

With regards to the nexmon .deb, what I didn't have on hand was the RPI zero, and thus, I couldnt grab a copy of the stock brcmfmac43430-sdio.bin for ARMEL. As such, this .deb, even though it will install properly for ARMEL, it won't run correct. it's not ready for Public consumption until the stock bin for ARMEL is added to it.

Lastly, one of the trickier things I tried to get around was nexutil. Using it within the script itself lead to unexpected results. I'm sure it was the fact I was trying so desperately to get it to work, and perhaps with some patience it can be tweaked. Anyways as it stands now in LN #42 of injectionON, you'll see:
echo " $modules_patch/nexutil -m2"
The user must paste and enter the resultant output for monitor mode to actually kick off.

Okay. Letting you absorb this. Look forward to your response.

[Re4son]

Hi stryngs,

Awesome work, thanks for helping out.
Looks much neater now. Let me have a look at the nexmon issue before I merge it. It's going to take a while though because I am off on a romantic holiday for a few weeks.
I'll get back to you when I'm back in the country, ok?

Many thanks,
Re4son

[stryngs]

@Re4son Enjoy that holiday. If you could tell me in the meantime how to get ahold of the armel version of brcmfmac43430-sdio.bin, I will go ahead and repackage accordingly.

As well, I'll do some testing and see if I can't figure out what is up with nexmon's nexutil not being happy when it's called by a shell script.

[steev]

@stryngs @Re4son there isn't such a thing as an "armel" version of the firmware - the firmware itself is actually built for arm-none-eabi (notice the cross compiler that is used) - the same firmware that is built for armhf for the rpi3b would work just fine for the rpi0w, so when creating that deb, you'd want to set the architecture to any since it works across all architectures (or would, if x86/amd64 also used the broadcom chipset somewhere)

[Re4son]

Forgot about this request, sorry guys.
The entire setup has changed a lot, with the nexmon drivers being compiled in the kernel tree, native compilations, etc.
Not sure if the entire pull-request is still applicable.

@steev: How about the following approach:

• I'll add a nexmon-firmware.deb definition to the "RPi-Distro-firmware" repo
• I've already started work on a much neater menu driven tft setup tool (kalipi-tft-config), I could package that up too
• We'll move the debs into an apt repository and install them from there

What do you think?

[steev]

@Re4son following debian naming, it would probably be best to name it firmware-nexmon, and we would probably need to add a divergence from firmware-brcm80211's brcm43430-sdio.bin and brcm43455-sdio.bin in order to not have it throw errors all over the place (we'd also likely need to redo the firmware-brcm80211 package so that it does the same, since it would simply attempt to create the files as well, and attempt to overwrite them, and error if a user attempts to install firmware-brcm80211 after installing firmware-nexmon.

And having everything as a deb would be amazing, and is what the end goal should be. There are actually a few places that offer apt hosting, though if we can get the debs to Debian-ish standards, I can always put them into git.kali.org and we would have them in the Kali repositories without having to find additional hosting.

[Re4son]

@steev - I much appreciate your input. Those errors when ovewriting the firmware are probable too much to deal with for now, how about I'll rename the existing packages first and we'll get them into the repo and take it from there?

[threeway]

Si, that would work too. We could do firmware-brcm80211-nexmon and have a

Replaces: firmware-brcm80211

In the control file so it would replace it, just make sure we put the originals as well as the rpi originals in there. In case you didn’t notice, the rpi firmware are roughly 120K larger than the upstream provided ones.