Badger Badge

Years ago for for EMF 2022 I got some badger badged for me and Phine as a surprise and promptly forgot to take them with me. After 38c3 (for which much writing is waiting to leave my head) it was really obvious to me that things are easier for strangers if they get a clue about who you are.

As I will be at FOSDEM this year I thought I'd try and set up the badger with a contact card to make things easier while I run the project/foundation table.

The badger has a 296x128 eink panel and an Micropython "OS" that hosts some examples. The badger has an onboard RP2040 microcontroller which can control the display, read buttons and do stuff. It has an ebook reader and an image view. If I want my own content for the badge I just need to upload an image to /images on the badge and open it.

Uploading an Image

As I use FreeBSD and have an allergy to installing software I didn't want to install a python IDE to copy a file.

I thought this would be easy to do, it wasn't.

The badge has documentation for beginners, but I found it really difficult to actually find facts. I've done a fair amount of stuff with micropython on various microcontrollers so I was able to skip using their recommended GUI tools and use sensible things.

The RP2040 is flashed by powering it up with RST held, it then appears as a FAT mass storage device. Micropython firmwares either host their own mass storage and don't require the RST hold or can offer a file system via serial. The badger is one of the second.

The easiest way I have found to upload files to micropython devices is to use ampy from Adafruit. This season it is packaged as py311-adafruit-ampy 

# pkg install py311-adafruit-ampy

If you plug the badge in and look at dmesg you should (but might not) see it connect as a serial device. 

ugen1.12: <MicroPython Board in FS mode> at usbus1
umodem0 on uhub0
umodem0: <MicroPython Board in FS mode, class 239/2, rev 2.00/1.00, addr 14> on usbus1
umodem0: data interface 1, has no CM over data, has no break

umodem0 is ttyU0 and cuaU0 depending on what you are doing. I uploaded my image with the put command: 

$ sudo ampy --port /dev/cuaU0 put badge.jpg /images/badge.jpg

and got this awful thing:

time to look at making the image better

Creating an Image

To make my FreeBSD badge I grabbed the Official FreeBSD Project assests from the Foundations website, dropped them into Inkscape and added some text using Roboto Sans the projects body text font. I then exported this to a non-progressive jpeg.

The output from Inkscape has some stray pixels, but badger has also applied dithering to the first image. This was a great opportunity to try the grafx2 bitmap editor so I pulled the exported JPEG into that. For what ever reason Inkscape had exported the black for the logo as very dark grey (12, 21, 23) and so the badger had done its best.

I edited the image to just be black and white saved it to BMP and then used convert to turn it into a 1 bit per pixel jpg. 

$ convert badger-badge.bmp -depth 1 badger-badge.jpg
$ identify badger-badge.jpg 
badger-badge.jpg JPEG 296x128 296x128+0+0 8-bit Grayscale Gray 256c 10553B 0.000u 0:00.000

After a firmware reset (below) I then through the image onto the badger and I'm happy enough for now.

Firmware Reset

The BadgerOS doesn't want to run after I have loaded my image, but that is easy enough to fix. Hold boot/usr on the back of the badge then press RST and it will come up as a USB mass storage device then copy the .uf2 from Pimoroni's Github and unmount and you will have updated the badge and recovered it to a running state to try a second image. 

$ sudo mount_msdosfs /dev/da3s1 ~/mnt
$ cp ~/Downloads/pimoroni-badger2040-v0.0.5-micropython-with-badger-os.uf2 ~/mnt/
$ sudo umount ~/mnt

FreeBSD Network Status Week 03 2025

Happy New Year and welcome back to FreeBSD Network Status Reports. I hope you had a great time over the Winter Pause (if you did pause) and are ready for another great year of improvements to FreeBSD.

I have opted to do a mega report, there have been 705 commits to FreeBSD main since my last update so we should get going before any more sneak in.

Goings on

BSD Devroom at FOSDEM 2024

The Devroom program is available here . I am speaking about writing these reports and staffing the Project/Foundation table the rest of the time. I could do with help covering the table (which must always be staffed) for the weekend. If you want to help send me an email (thj@freebsd.org)

Transport

In RACK and BBR there have been a bunch of tidy up changes simplifying code.

I think the other TCP changes fall under maintenance and general code quality. The "don't send beyond advertised window" change is an indicator of how complex TCP is to work on.

Network Stack

Better MTU selection when using ipsec.

Changes in VNET, more socket sysctl parameters are virtualised and there have been some fixes.

Several commits to netlink.

Netdev

Some fixes to mlx5 in SRIOV.

An update for the Cisco Virtual Interface Card driver to better handle MTU changes.

Wireless

adrian@ has been working on rtwn and it is growing into the WiFi device with the best support. IF you have supported USB hardware and want to try higher rates then testing CURRENT now would be appreciated.

Changes in net80211 and LinuxKPI to support HT and VHT rates. We are getting closer to the Linux KPI drivers having reasonably modern throughputs.

I think from the rtwn stuff some longer standing issues in ath were fixed.

gavin@ has started poking on the Broadcom NICs you might see in old MacBooks.

Firewalls

Much has happened in PF in the last month. OpenBSD's NAT rewrite support has been partially imported, with accommodation for FreeBSD's existing rule syntax. SCTP support has been expanded and is growing towards TCP support in PF.

There have been test, documentation support and bug fixes to help the NAT write and SCTP handling.

User Tooling

A fix in ping for minimum packet for ping sweeps and better error messages.

Other stuff

This is kind of a WiFi change, but it is important for how FreeBSD deals with firmware. Historically firmware was loaded as a kernel module and then requested by a driver, getting a opaque blob to send to the device. For CVS(?) it has to be uuencoded, which wasn't a real problem for a long time. From 15 firmware can just be loaded from disk as a blob, this frees up drivers a bit certainly making development easier, but it makes it more difficult for things like loader to load kernel modules and know that firmware will be there. Expect some churn. while thinks improve.

Please Send Feedback

There was a lot of stuff in the last month, but I decided to trim out most of the picked commits rather than make a lot of "small improvement" comments on huge series of changes. It is good to see the number of changes that pf gets every week and occasional bursts in other areas.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Remote WiFi packet analysis with Wireshark

Sometimes you need to get packets from somewhere awkward, but you want to be able to stream them and do live analysis. Rather than dump to a file and ship that around Wireshark supports a bunch of modes to get remote captures, they are detailed on the Pipes Wireshark Wiki Page .

I want to be able to get Air packets (WIFI!) from OpenWRT, but think about them on my FreeBSD desktop.

I bought the OpenWRT One router for just this sort of thing. A well supported, modern hardware platform that also supports the OpenWRT project with money - who could resist.

OpenWRT Setup

The OpenWRT One router ships as a home router, with a 'secured' wan port and WiFi bridged with Ethernet on a LAN port, WiFi is disabled out the box. I'm pretty happy for the router to hang our on my network with the wan port facing my internal network and the LAN port for testing devices.

For my setup I needed to enable control on the wan port in the firewall and add rules for my PCAP server. Then I needed to configure monitor mode on the WiFi interfaces.

After a first set up, where I was made to configure a password I was locked out. A quick reset (hold the front button while powering on) returned me to some soft of factor default with the lUCI web interface uninstalled.A

That actually suits me fine - now I have to configure stuff on the command line I won't get confused by buttons.

I added rules to the WAN interface to allow SSH in and TCP connections to port 19000 by adding the following to /etc/config/firewall : 

# allow ssh on wan port
config rule
    option name     Allow-ssh-wan
    option src      wan
    option dest_port    22
    option proto        tcp
    option target       ACCEPT

# allow serving pcap from netcat on wan port
config rule
    option name     Allow-pcap-wan
    option src      wan
    option dest_port    19000
    option proto        tcp
    option target       ACCEPT

And then reloaded firewall configuration by running 

root@OpenWrt:~# /etc/init.d/firewall reload

I tested this works by ssh'ing in on the wan interface.

I then set up WiFi by editing /etc/config/wireless and changing the mode of default_radio0 to 'monitor' and changing 'disabled' to '0': 

config wifi-device 'radio0'
    option type 'mac80211'
    option path 'platform/soc/18000000.wifi'
    option band '2g'
    option channel '6'
    option htmode 'HE20'
    option num_global_macaddr '7'
    option disabled '0'

config wifi-iface 'default_radio0'
    option device 'radio0'
    option network 'lan'
    option mode 'monitor'
#   option ssid 'OpenWrt'
#   option encryption 'none'

Running 

root@OpenWrt:~# /etc/init.d/wireless restart

gave me a new interface in ifconfig: 

phy0-mon0 Link encap:UNSPEC  HWaddr XX-XX-XX-XX-XX-XX-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8064610 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2521292141 (2.3 GiB)  TX bytes:0 (0.0 B)

pcaping

The easiest way to remotely get packets into Wireshark ssh'ing to somewhere an pulling stuff back over the socket, Wireshark has a builtin method for this via the sshdump extcap. Not all platforms package up all the Wireshark tools, FreeBSD is missing a lot of these and my capture target OpenWrt doesn't seem to have any.

I really don't want to build my own FreeBSD packages and I refuse to build my own OpenWrt ones.

After some long thoughts looking over the Wireshark capture modes I figured that I could feed packets from tcpdump into netcat and then let Wireshark pull them over the network.

From OpenWRT you need to install, netcat and tcpdump: 

root@OpenWrt:~# apk add netcat tcpdump

With remote hosts being able to connect to the listener with the firewall rule (above) i could now run tcpdump and feed traffic into netcat: 

root@OpenWrt:~# tcpdump -i phy0-mon0 --immediate-mode -U -w - | nc -l -p 19000

Wireshark can now connect to my remote host (192.168.4.34 as an example): 

wireshark -k -i TCP@192.168.1.34:19000

OpenWrt netcat is jarringly different to FreeBSD (from openbsd) netcat, once I figured that out I was in business and started getting packets from the air from OpenWrt.

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

The universe has conspired and I have had to leave the house.

The universe has conspired and I have had to leave the house or my 2024 travel development setup.

The last month or so my office at home has been getting very cold and I have been pushing off my Wife's comments of "work in the warm bit" with the response that "I need the cables from my laptop to the computer to do development". Having been made to leave the house this excuse is going to fall apart and I will have to stop pretending I'm some rugedd person out in the wilds.

To continue hacking on wifi I needed to make my setup portable, the Morefine M6 (the worst best computer) , is incredibly small and quite perfect for this.

Here is my full development setup:

The setup is composed of:

  • Framework 13 with a 12th Generation Intel Processor and just not enough storage
  • Morefine M6 N200 Intel mini pc
  • GL.inet Beryl AX travel router
  • Anker Prime Charger Power Supply
  • Openterface KVM
  • A random anker USB-C hub with ethernet
  • A random no name USB-C hub with ethernet, PD pass through and a detachable cable with hates my monitor at home
  • 2015 rad1o badge (its basically a hackrf)
  • A pencil case full of cables
  • The nice silicone Ethernet cables that came with my EEROs, but were too short to use.

Framework 13

The Framework 13 has been my main development machine since I joined The FreeBSD Foundation last year. It runs FreeBSD well and the processor does this amazing thing where it can build FreeBSD in the same time as my testbed build machines. Battery life sucks, WiFi is available, but there is no suspend.

I now mostly use it docked and I have a wonderful user experience of it as a computer that does what I want. Using the framework as a laptop again has been really nice. They have done a good job with these things.

I have been trying to streamline development as much as I can. Right now I do everything on my laptop and I have a script that handles deploying a kernel or userspace binaries, rebooting and running tests. The M6 fits into this as well as other hardware does.

Morefine M6

The linked blog post has more about the M6, the key part is that it has become my main development target for the last few months. Some kernel hackers are happy to work in the same VM they test on, but I like there to be a lot of separation between the computer I type into and the computer that kernel panics constantly. Maybe they write fewer kernel panics.

From sheer luck the M6 has the right WiFi I need to work and it has done a great job as a hypervisor running a single VM. Only very occasionally have I upset the wifi card enough to require a full host power cycle.

The downside of the M6 is the fan. I won't be able to use it in the quiet carriage of the ICE, but I'm now starting to target the WiFi in the framework for further testing so the timing of things worked out well.

GL.INET Beryl AX

For WiFi development I needed a test router as a target. I have been using USB WiFi dongles, but as rates go up there are a few downsides. FreeBSD support is good, but not great, generally they are limited on the bands they can support and they don't act as an independent test target.

When debugging things it is good to be able to rule out FreeBSDisms and the Gl.Inet was heavily discounted for Jeff's birthday party.

It is just OpenWRT with an extra UI layer, the extra UI can be turned off which I think will happen soon as I need a more useful machine for development than most people need for exceeding device limits on hotel WiFi.

The main thing for the GL.iNet so far is that it is a reasonably representative access point and it seems to be. Once we start pushing into ac and ax speeds it'll be great to have a good reference device.

Anker Prime Charger

All of these things need power and the idea of taking 5 USB-C power bricks with me on the road is quite upsetting. At my desk so far I have been using the Pine64 PinePower, but there are reports of it killing attached devices, the lcd screen makes audio output unusable with my laptop and there are occasional bugs.

The Prime Charger is a 250W power supply, it can spread this over a number of devices with 2 ports being high power, 2 lower power and 2 USB-A ports. I have wanted to replace the Pine Power for a while and a brand name GAN device with 4 USB-C ports and 2 USB-A ports was very tempting. Discounts for Geoff's birthday sealed the deal.

I am seriously underwhelmed.

The Morefine M6 is a 12V 3A USB-C device, which while not in spec, isn't too rare. The GL.inet is a 5V 3A device. My framework laptop will charge at whatever.

What I need from this power supply for travel is 3 consistent ports that will be on when they should be.

The Prime is completely unwilling to offer 12V to the M6. I was sure from reading the tiny spec block on the Geogs-books.com webpage that it could offer 12V 3A, but it turns out that is only offered on the USB-A ports and it is picky.

The supply offers multiple power zones which are shared across ports. This is super confusing and the UI is frankly terrible. The Pine Power just has 4 separate supplies.

I want to host computers from this supply, but it won't give me 12V so the M6 is on a different power brick (the one that came with the OpenWRT ONE - a toy for next year). While working I charged my headphones, lightning on USB2. When I unplugged the headphones my laptop got a full power cycle and reconnect. A terrifying thought it I were doing something useful on a computer running from the supply.

Other things

The Openterface (worst product name) arrived just before leaving and I threw it in my bag in case I needed to figure out what is going on with the M6. The KVM side requires software that depends on KDE Plasma 6 which isn't packaged yet on FreeBSD. The video part of the KVM is just a MACRO SILICON HDMI capture device which I have (and got for a tenner). This works without the KVM software so I took a keyboard with me to handle the host control part if needed.

I have a large collection of cables, I'm leaning towards taking silicone cables now and have USB-C and Ethernet ones. They are nice to hold and the flexibility makes them much less annoying to use on a desk with a lot of stuff. They don't pick things up as easily as PVC copper cables do.

I have a pencil case for most cables that I got in a street market in Berlin last summer. It was a nice find.

For my winter pause project I wanted to do something with radios. I chickened out travelling with the Flipper Zero, it is too expensive to risk being stolen by a security guard in an airport. Instead I took the rad1o badge with its battery removed. I'm going to write more about that project if it gets anywhere. If it gets going to be serious type 3 fun.

For power I have a Shargeek 140, its nice enough and a good form factor. It looks really cool. The final interesting thing I took with me (and isn't pictured) is a half frame 35mm camera. This will get a write up once I get the first films back. No point talking about it if it doesn't work.

sdrpp network audio playback

I guess my winter pause project involves some software defined radio and it has been a long time since I've tried this. I borrowed the rad1o badge from a friend and have done some work to get it working as a hackrf . Thankfully hackrf ships a firmware for the rad1o badge and it is just an update to get it in sync with libhackrf, though you do lose the portapak features.

In the intervening 8 or so years there are a lot more and more user friendly tools available and I thought I would try out sdr++ (sdrpp in many places because the plus sign causes trouble with software. I'm not sure my blog engine can handle it either...).

sdrpp gives easy access to a frequency and waterfall view of the spectrum, supports many software defined radios and is able to demodulate various audio modes.

The first "check" with any sdr is to demod broadcast fm, that is "listen to the radio". Broadcast fm is a target of choice because it is put out with a ton of power, there are many stations and it requires an antenna as complex as a piece of wire (any length!).

I quickly found that the sinks menu of sdrpp only offered network audio. I think there is something up with the FreeBSD port or portaudio. I couldn't figure out how to debug this and debugging this isn't my project!

Instead I tried the network output, but other than "its pcm" in a github issue I couldn't find any information on what I needed.

Eventually I got to this: 

nc -kul 127.0.0.1 7355 | sox -traw -r48000 -b16 -e signed-integer - -d

start up netcat on localhost and the port in the sdrpp ui (7355 for me). Pipe the audio to sox at 48000 (or whatever you configure) and treat it as raw signed-integer input.

This let me demod audio and scroll around the band. It might be sdrpp or it might be the part of Germany I'm in right now, but all stations were playing the same audio, different strengths and clarities, but the same audio.

Figuring out that is a different problem.

next