[Benjojo] got interested in where the magic number of 1,500 bytes came from, and shared some background on just how and why it seems to have come to be. In a nutshell, the maximum transmission unit (MTU) limits the maximum amount of data that can be transmitted in a single network-layer transaction, but 1,500 is kind of a strange number in binary. For the average Internet user, this under the hood stuff doesn’t really affect one’s ability to send data, but it has an impact from a network management point of view. Just where did this number come from, and why does it matter?
[Benjojo] looks at a year’s worth of data from a major Internet traffic exchange and shows, with the help of several graphs, that being stuck with a 1,500 byte MTU upper limit has real impact on modern network efficiency and bandwidth usage, because bandwidth spent on packet headers adds up rapidly when roughly 20% of all packets are topping out the 1,500 byte limit. Naturally, solutions exist to improve this situation, but elegant and effective solutions to the Internet’s legacy problems tend to require instant buy-in and cooperation from everyone at once, meaning they end up going in the general direction of nowhere.
So where did 1,500 bytes come from? It appears that it is a legacy value originally derived from a combination of hardware limits and a need to choose a value that would play well on shared network segments, without causing too much transmission latency when busy and not bringing too much header overhead. But the picture is not entirely complete, and [Benjojo] asks that if you have any additional knowledge or insight about the 1,500 bytes decision, please share it because manuals, mailing list archives, and other context from that time is either disappearing fast or already entirely gone.
Knowledge fading from record and memory is absolutely a thing that happens, but occasionally things get saved instead of vanishing into the shadows. That’s how we got IGNITION! An Informal History of Liquid Rocket Propellants, which contains knowledge and history that would otherwise have simply disappeared.
There’s something thrilling about decoding an unknown communications protocol. You start with a few clues, poke at the problem with some simple tools, and eventually work your way up to that first breakthrough that lets you crack the code. It can be frustrating, but when you eventually win, it can be very rewarding.
It seems that [Jason] learned this while decoding the wireless conversation between his mass-market quad and its controller. The quad in question, a Yuneec Q500, is one of those mid-range, ready-to-fly drones that’s targeted at those looking to get in the air easily and take some cool pictures. Unsure how the drone and controller were talking, [Jason] popped the covers and found a Zigbee chipset within. With the help of a $14 Zigbee USB dongle and some packet sniffing software from TI, [Jason] was able to see packets flowing, but decoding them was laborious. Luckily, the sniffer app can be set up to stream packets to another device, so [Jason] wrote a program to receive and display packets. He used that to completely characterize each controller input and the data coming back from the drone. It’s a long and strange toolchain, but the upshot is that he’s now able to create KML in real time and track the drone on Google Earth as it flies. The video below shows the build and a few backyard test flights.
Congratulations to [Jason] for breaking the protocol and opening up drones like this for other hackers. If you’re interested in learning more about Zigbee sniffing, you can actually hack a few smarthome gadgets into useful sniffers.
Continue reading “Drone Gives Up Its Wireless Secrets To Zigbee Sniffer”
Everyone’s favorite packet sniffing tool, Wireshark, has been around for almost two decades now. It’s one of the most popular network analysis tools available, partially due to it being free and open source. Its popularity guaranteed that it would eventually be paired with the ESP32/8266, the rising star of the wireless hardware world, and [spacehuhn] has finally brought these two tools together to sniff WiFi packets.
The library that [spacehuhn] created uses the ESP chip to save Pcap files (the default Wireshark filetype) onto an SD card or send the data over a serial connection. The program runs once every 30 seconds, creating a new Pcap file each time. There are many example scripts for the various hardware you might be using, and since this is written for the ESP platform it’s also Arduino compatible. [spacehuhn] has written this as a proof-of-concept, so there are some rough edges still, but this looks very promising as a network analysis tool.
[spacehuhn] is no stranger to wireless networks, either. His YouTube channel is full of interesting videos of him exploring various exploits and testing other pieces of hardware. He’s also been featured here before for using an ESP8266 as a WiFi jammer.
Continue reading “ESP To Wireshark”
[Diego Spinola] wrote in to tell us about a node communication system he’s been working on called HsNet. The aim is to build a system of nodes that can be made up of small and inexpensive microcontrollers. The problem is that the least expensive controllers often don’t have a hardware UART. HsNet implements the RS485 protocol using a software UART along with a slim and sleek addressing scheme.
The first module developed, seen in the image above and video after the break, is a single channel pulse-width-modulation node using a PIC 12F683. It can be sent commands in the payload of the HsNet packet format. The PWM modules accept three different commands; one is a desired PWM value, another is a delay between steps for the PWM, and the last toggles a blink function.
He has also developed an analog sensor module and an Arduino-based TCP/IC gateway module. Now that the packet communications have been established, it will be rather simple to add nodes based on that groundwork. [Diego] brought these components together to build an interactive wall which can also be seen after the break.
Continue reading “HsNet: Node Communications For Feature-limited Microcontrollers”
Wireshark, a tool recognized universally as being one of the best network analyzers available, has long been used by legitimate network professionals as well as a shadier crowd (and everywhere in between). While useful for analyzing both wired and Wi-Fi traffic, monitoring 802.15.4 protocols (such as Zigbee) have not been a common use in the past. [Akiba] of FreakLabs has brought us a solution which works around the normal limitations of Wireshark’s libpcap base, which does not accept simple serial input from most homebrew setups that use FTDI or Arduinos to connect to Zigbee devices. Using named pipes and a few custom scripts, [Akiba] has been able to coax Wireshark into accepting input from one of FreakLabs Freakduino boards.
While there are certainly professional wireless analyzing tools out there that connect directly into Wireshark, we at Hackaday love showing off anyone who takes the difficult, cheap, out of the way method of doing things over the neat, expensive, commercial method any day.
Charter Communications has announced that it will no longer be attempting to target advertising based on user actions. The original strategy would have involved inspecting the contents of every packet sent or received by the customer. This usage pattern is associated with a specific IP and relevant ads are displayed on sites using NebuAd when that IP visits. NebuAd doesn’t directly share the IP, but we’ve seen in the past, even with obfuscation, a user’s search patterns alone have been known to give away their identity. The majority of all internet traffic is plaintext, but endusers have an expectation of privacy. User backlash is what eventually caused Charter to back down, but that doesn’t mean companies like NebuAd are going to be any less common.