I wouldn't expect emergency rooms and 911 to stop working either, but here we are, so until someone says otherwise, I'm assuming some ATCs went down too.
I imagine the flight planning software they use was affected (so their ability to coordinate with other airport's ATC), but not their radio systems or aircraft radar (nearly all radar systems I've worked with are run on Linux, and are hardened to the Nth degree). Been out of the game for 12 years though, so things have likely changed.
The Tenerife disaster (second-deadliest aviation incident in history, after 9/11) was ultimately caused by chaotic conditions due to too many airplanes having to be diverted and land at an alternate airport that wasn't equipped to handle them comfortably.
I'd argue that Tenerife was due to taking off (in bad weather), not landing. But of course, a bunch of planes landing at the same airport without ATC sounds quite dangerous.
There were a lot of contributing causes, but it wouldn't have happened if not for the fact that Tenerife North airport was massively overcrowded due to Gran Canaria airport being suddenly closed (for unrelated reasons) and flights forced to divert.
The issue wasn't with landing specifically; I'm just using it as a general example of issues caused by havoc situations in aviation.
Pilots know where there are other places to land, e.g. there are a lot of military strips and private airfields where some craft can land, depending on size.
I always said if you want to create real chaos, don't write malware. Get on the inside of a security product like this, and push out a bad update, and you can take most of the world down.
I'm the 'inventor' (seems a bit of a weird term) of the Spectranet, a similar device for the Sinclair ZX Spectrum, although it's wired ethernet rather than wireless (when I designed the device, there weren't simple-to-interface devices like the ESP32 readily available, however, the Wiznet W5100 chip for wired ethernet was, and is a perfect match for an 8-bit system).
It would be possible to write malware for a Spectrum using this device but I don't think anyone ever has - needless to say, a Sinclair Spectrum isn't a secure computing platform. It would certainly be possible to write a worm.
Back when I was a teenager, we had an econet network of BBC Micros/BBC Masters and Acorn Archimedes at our school, and I did indeed try to write a worm for that platform (essentially, attaching itself to a user's !Boot script - essentially adding some 6502 code to the start of it to allow the program to spread itself to other !Boot scripts - the BBC micro allowed you to attach 'hooks' to its system calls, so as long as the user didn't overwrite the memory where your program was or do FX 200,2 followed by Ctrl-Break (a precaution I always took before logging on :-)) you could keep a small program memory resident. Especially in a Master 128.
I gave up because I realised the teacher who ran the computer lab had started taking quite a close interest in the code I was writing, and I wasn't entirely confident that he didn't know 6502 asm (one day I forgot to PROT my system, and I noticed a slow down while running the assembler, the slow down a sure sign someone was using VIEW to view my screen. So I ran PROT, which disabled that, and within 30 seconds the guy was in the room and looking over my shoulder! He knew that I knew, and he knew that I knew that he knew what was going on) Afraid of being caught and banned, I abandoned the project. (For the avoidance of doubt, the 'malware' in question was a bit like the idea of the Morris worm, simply to spread itself but with no payload).
However something similar could be done on other 8 bit systems. The "mal" part of the malware would be extremely limited - with such a small amount of RAM, no multitasking and no memory protection, anything you load into memory isn't going to last long once a user loads a real program.
The real target of any malware would be things like the TNFS (network filesystem) daemon, as to be able to run on vintage hardware it's got to be written in plain C and there could be bugs, and the filesystem protocol being very simple and unencrypted is not secure (nor is it designed to be, the preface on the README for tnfs does tell users they are mad if they try to store any data they want to keep private). The other target I guess in the case of ESP32 based devices is the ESP32 itself, but that's not really malware targeting the vintage system.
