I ordered a handful of the cheapest nodemcu boards I could find from ebay. A couple of weeks later I got a nodemcu 'like' board from a company callsed AI-THINKER . The boards following instructions written on the back of them:

1. Install CH340G driver.
2. Use 9600bps baud rate.
3. Connect to WiFi.

I tried playing with two of the boards, powering them up and searching for wifi networks showed a network with a name like:

AI-THINKER_238810
AI-THINKER_23A9BF

Connecting to the wifi was fine, but I didn't really know what they expected me to do. nmap'ing the device has no results and an hour googling didn't really show up anything. Connecting over serial resulted in some noise then nothing.

I was going to flash micropython anyway, so lets do that.

Flash micropython

Connecting to the nodemcu board over serial spits out some gibberish no matter the baud rate I pick.

$ sudo cu -l /dev/ttyU1 -s 76800
Connected
Sd3²ì{£P:ýCê
ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 1856, room 16 
tail 0
chksum 0x63
load 0x3ffe8000, len 776, room 8 
tail 0
chksum 0x02
load 0x3ffe8310, len 552, room 8 
tail 0
chksum 0x79
csum 0x79

2nd boot version : 1.5
  SPI Speed      : 40MHz
  SPI Mode       : DIO
  SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 @ 1000

êñ+Pr-r+§(r

SD«¢hJëÙ-$xùÊkPx\)§k ¢ÀjtNü

Some time with a scope reveals the board is starting up at one rate then switching to another. The rate switch means the esptool is unable to do automatic baud rate detection.

With that we can flash the boards:

erase the flash
esptool.py --port /dev/tty.wchusbserial1420 erase_flash

flash the image
esptool.py --port /dev/tty.wchusbserial1420 --baud 76800 write_flash --flash_size=8m 0 esp8266-2016-05-03-v1.8.bin

reset the board

cu -l /dev/tty.wchusbserial1420 -s 115200
MicroPython v1.8.2 on 2016-08-05; ESP Module with ESP8266
Type "help()" for more information.
>>>

I read this excellent post by Simone Margaritelli on hacking a network connected coffee machine. Simone reverse engineered the Android app that controls the coffee machine and wrote a command line tool for getting the machine going.

Simone took a completely different angle to solving the problem than I would. Being a network person I would have gone straight to tcpdump, grabbed some traces from the app/coffee machine and worked from that.

Instead Simone used a tool to dump a disassembly of the Android apk. I haven't done that before, I don't think it would be my first thought when I had to take something apart. From this post I think I might give it a shot on the local bus app.

The coffee machine looks awesome, you might not want an internet connected coffee machine, but I think it is an awesome idea. Coffee is a great reward for solving a problem, the machine could automate teaching people how to reverse network protocols.

Reading: Little Brother

The tortoise needs an improved heating setup, now have a 'night time' buld that just puts out heat. Before I change anything I want to have numbers so I can try and quantify the change.

I knocked up a micropython script and ran it on a nodemcu board with a couple of dht11's. It looks like this:

def temperatureclient(sensors,addr="255.255.255.255"):
    print("       sending to: {} {} every {} seconds"
        .format(addr , PORT, DELAY))

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    while True:
        pkt = takereading(sensors)
        sock.sendto(pkt, (addr, PORT))

        time.sleep(DELAY)

def takereading(sensors):
    readings = []
    for sensor in sensors:
        sensor.measure()

        reading = {}

        reading["sensor"] = str(sensor.pin)
        reading["pin"] = str(sensor.pin)
        reading["temp"] = sensor.temperature()
        reading["humditiy"] = sensor.humidity()

        readings.append(reading)
        print(reading)
    return json.dumps(readings)

It doesn't have to live for long, just a day or two.

The always on machine on my network doesn't seem to have anything useful installed and without internet at home that wasn't going to be a simple fix. Instead I used tcpdump to capture the json packets.

Tcpdump works really well in this situation, the micopython board doesn't have a RTC, but the pcap from tcpdump will have acurate timestamps for each field. I did something like:

$ tcpdump -w tempreadings.pcap udp and port 6969

Later I can process this out with a shell script or scapy or something.

It is Sunday, so that makes seven days of writing .

Reading: Butter from my Feed Reader

My Cold Brew Recipe requires:

• 128g of Coarse ground coffee (I guess 125g is okay, if you aren't cool)
• 1L Vessel (I use a nalgene)
• 1L of potable water
• Fridge
• v60
• Jug

Method:

• Put the ground coffee in the vessel.
• Fill the vessel with cold water
• Place vessel in fridge

I use tap water because I live in a place with excellent drhinking water. If that isn't the case for you, you will have to figure something else out. Make sure the ground is well soaked, it will swell. I give it a good shake then add a little more water to make sure the nalgene is good and full.

After about a day take the nalgene out of the fridge.

• Pour the coffee/concentrate blend into the jug.
• Clean the nalgene.
• using the v60 filter the concentrate back into the nalgene.

I normally end up with about 700ml of concentrated coffee. I mix it with boiling water to drink, about 120ml of concentrate to 200ml.

Reading: Little Brother

To win this bet I have with Ed I need a WiFi adapter that can do 80211n in the 5GHz band. There aren't a lot of these around and n in 2.4GHz band makes it hard to find adapters with the right support.

I got pair of AC600 generic adapters on ebay for about a tenner, a quick look showed promising Linux support. This indicated I could use one for the bet without too much hassle.

I got a second so I could work on a wireless driver for FreeBSD, what else am I to do with my time?

The adapter is a MediaTek MT7610U device, there is a whole load of information about it on Wikidevi and there are a family of forks of the vendor code on github.

Wikidevi says the MT7610U is similar to the RT28xx series , which are supported by run in FreeBSD. I started last night by taking the run driver, getting it to build as a module, then turning everything off apart from probe, attach and detach.

This is the first time I have tried to port a driver, to help I collated everything I could find written about doing it.

There is straight up FreeBSD stuff:

• http://adrianchadd.blogspot.co.uk/2015/09/porting-wifi-driver-from-openbsd-ar9170.html
• https://people.freebsd.org/~jmg/drivers
• https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/

There are load of little posts where people have ported drivers from FreeBSD to somewhere else:

• https://wiki.smartos.org/display/DOC/Porting+Network+Device+Drivers+from+FreeBSD
• http://cnds.eecs.jacobs-university.de/archive/bsc-2011-pvaibhav.pdf
• https://www.dan.me.uk/blog/2010/01/25/ndis-wifi-drivers-in-freebsd-project-evil/
• http://www.netbsd.org/docs/kernel/porting-freebsd-net.html
• http://stackoverflow.com/questions/32156173/porting-pcie-driver-from-linux-to-freebsd

And there are a load of articles about building wifi drivers for android, these are worth read, but they are worth pointing out:

• http://blog.linuxconsulting.ro/2010/04/porting-wifi-drivers-to-android.html
• https://community.nxp.com/docs/DOC-93603
• https://befinitiv.wordpress.com/2015/04/18/porting-wifibroadcast-to-android/

Reading: Little Brother

I had an argument with some Germans about the pronunciation of WiFi, apparently it is WeeFii using the sounds of wireless and fidelity. They also pronounced HiFi incorrectly, English is a strange language.