UDP Broadcasting And The Brave New World Of IPv6

After recently working our way through UDP broadcasting and network subnetting all in the comfort zone of IPv4, it’s time to address the elephant in the room, the one wearing a bright neon ‘IPv6’ sign. Although it’s still very much a rumor at this point, supposedly IPv6 is slated to replace the venerable IPv4 protocol. Rather than just being IPv4-but-with-more-addresses, its designers took the opportunity to basically completely redesign the protocol for the futuristic world of the late 90s and the early 2000s.

Joking aside, IPv6 having been introduced in 1995 and still struggling to meaningfully displace IPv4 does invite some worries about just how easy it is to switch between these two fundamental internet protocols. Say if we wanted to join the future of the 2000s and adapt our software to speak IPv6 instead of IPv4, what would change about the aforementioned aspects of IPv4 UDP broadcasting and IPv4 subnetting?

Speaking as an ignorant developer who mostly knows IPv6 from those weird and hard to remember network addresses, as well as many broken router implementations, I’m not entirely convinced that I’m going to like what I’ll see.

Continue reading “UDP Broadcasting And The Brave New World Of IPv6” →

UDP Broadcasting And The Joys Of IPv4 Subnetting

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Continue reading “UDP Broadcasting And The Joys Of IPv4 Subnetting” →

A laptop communicating with the drone via an Arduino

Reverse-Engineering The Holy Stone H120D Drone

There are plenty of drones (and other gadgets) you can buy online that use proprietary control protocols. Of course, reverse-engineering one of these protocols is a hacker community classic. Today, [Zac Turner] shows us how this GPS drone can be autonomously controlled by a simple Arduino program or Python script.

What started as [Zac] sniffing some UDP packets quickly evolved into him decompiling the Android app to figure out what’s going on inside. He talks about how the launch command needs accurate GPS, how there’s several hidden features not used by the Android app, et cetera. And it’s not like it’s just another Linux SoC in there, either. No, there’s a proper Real-Time Operating System (RTOS) running, with a shell and a telnet interface. The list of small curiosities goes on.

After he finished reverse-engineering the protocol, he built some Python scripts, through which you can see the camera feed and control the drone remotely. He also went on to make an Arduino program that can do the latter using an Arduino Nano 33 IoT.

QUIC! Jump To User Space!

Everyone knows that Weird Al lampooned computers in a famous parody song (It’s All About the Pentiums). But if you want more hardcore (including more hardcore language, so if you are offended by rap music-style explicit lyrics, maybe don’t look this up), you probably want “Kill Dash 9” by Monzy. There’s a line in that song about “You thought the seven-layer model referred to a burrito.” In fact, it refers to how networking applications operate, and it is so ingrained that you don’t even hear about it much these days. But as [Codemia] points out, QUIC aims to disrupt the model, and for good reason.

Historically, your application (at layer 7) interacts with the network through other layers like the presentation layer and session layer. At layer 4, though, there is the transport layer where two names come into play: TCP and UDP. Generally, UDP is useful where you want to send data and you don’t expect the system to do much. Data might show up at its destination. Or not. Or it might show up multiple times. It might show up in the wrong order. TCP solves all that, but you have little control over how it does that.

When things are congested, there are different strategies TCP can use, but changing them can be difficult. That’s where QUIC comes in. It is like a user-space TCP layer built over a UDP transport. There are a lot of advantages to that, and if you want to know more, or even just want a good overview of network congestion control mitigations, check the post out.

If you want to know more about congestion control, catch a wave.

Simon Says With An RP2040

The team of [Michael] and [Chimdi] from Cornell’s Designing with Microcontrollers (ECE 4760) Fall 2023 session designed a version of Simon Says on an RP2040 which they call Pico Says. It uses UDP packets over WiFi to communicate between the players, and supports VGA graphics for output. Each player’s hardware consists of a Pico W module plus a control panel containing the four LEDs and buttons ( red, green, yellow, and blue ) plus send and reset buttons.

For purposes of this lab, the modules were build on a solderless breadboard and used perfboard for the control panels. They weren’t entirely happy with their choice of UDP because they experienced frequent datagram dropouts in the noisy environment of the microcontroller lab. They also planned to implement sound effects, but ran out of time after spending too much time on the WiFi implementation, and had to drop that feature. In the end, however, they wrapped up their project and demonstrated a working game. We can only speculate whether this bonus lesson in resource management was intended by [Dr. Hunter Adams] or not.

Two ECE 4760 course references are highlighted in the write-up that helped them jump-start the project: the UDP and VGA examples for the Pico. These are good links to put in your RP2020 toolbox for future projects, in addition to the ECE 4760 course home page itself. We’ve covered several of these projects recently, as well as the curriculum switch from the Microchip PIC32MX-based Microstick II to the RP2040 last Spring.

Continue reading “Simon Says With An RP2040” →

Ethersweep: An Easy-To-Deploy Ethernet Connected Stepper Controller

[Neumi] over on Hackaday.IO wanted a simple-to-use way to drive stepper motors, which could be quickly deployed in a wide variety of applications yet to be determined. The solution is named Ethersweep, and is a small PCB stack that sits on the rear of the common NEMA17-format stepper motor. The only physical connectivity, beside the motor, are ethernet and a power supply via the user friendly XT30 connector. The system can be closed loop, with both an end-stop input as well as an on-board AMS AS5600 magnetic rotary encoder (which senses the rotating magnetic field on the rear side of the motor assembly – clever!) giving the necessary feedback. Leveraging the Trinamic TMC2208 stepper motor driver gives Ethersweep silky smooth and quiet motor control, which could be very important for some applications. A rear-facing OLED display shows some useful debug information as well as the all important IP address that was assigned to the unit.

Control is performed with the ubiquitous ATMega328 microcontroller, with the Arduino software stack deployed, making uploading firmware a breeze. To that end, a USB port is also provided, hooked up to the uC with the cheap CP2102 USB bridge chip as per most Arduino-like designs. The thing that makes this build a little unusual is the ethernet port. The hardware side of things is taken care of with the Wiznet W5500 ethernet chip, which implements the MAC and PHY in a single device, needing only a few passives and a magjack to operate. The chip also handles the whole TCP/IP stack internally, so only needs an external SPI interface to talk to the host device.

Continue reading “Ethersweep: An Easy-To-Deploy Ethernet Connected Stepper Controller” →

The Pi Pico board on top of a white box with an Ethernet jack, with a sensor module plugged onto the Pico's pin headers. A black MicroUSB and a green Ethernet cable are connected to this device.

An Elegant Ethernet Library For Your Next RP2040 Project

A few days ago we covered a project that brought Ethernet connectivity to the Raspberry Pi Pico using little more than some twisted pair and a RJ-45 connector. It was a neat trick, but not exactly ready for widespread adoption. Looking to improve on things a bit, [tvlad1234] has taken that project’s code and rewritten it into a friendly library you can use with any RP2040 board.

In case you missed it, the initial demo did 10BASE-T transmission by bit-banging with the PIO, and was able to send UDP messages to devices on the wired LAN. It was an impressive accomplishment, but its code didn’t make it easy to build your project around it. This new library makes UDP messaging as easy as a printf, offloading all non-PIO-managed Ethernet signal work onto the RP2040’s second CPU core. The library even generates a random MAC address out of your flash chip’s serial number!

As a demonstration of the new library, [tvlad1234] has put together a simple Ethernet-connected temperature monitor using the BMP085 or BMP180 sensor connect over I2C. If you feel like you could use an Ethernet transmit-only sensor in your life, browsing the source code would be a great start.