Many people have their home network setup with a dynamic dns service in order to remote access their files, printers, or Pi based security camera systems. Many people also suffer from less than stellar internet connectivity and find themselves unable to access their home system due to a stalled signal.
netBOOT is an Arduino based device that automatically resets your modem for you, when you are unable to. Core of the system is a standard issue ATMEGA328p based Arduino board combined with a W5100 Ethernet module, and a relay module. The software on the Arduino periodically pings a list of IP addresses and listens for a response. If none is found within 3 tries the relay module, which is connected inline with the DC power of your modem, is clicked open for 10 seconds and then returned closed. Once your modem has rebooted and re-synced everything should be good to go.
We don’t remember seeing this feature in the list of specs for Google’s new OnHub. The ability to reset bad connections seems like a feature that should be built into future-thinking routers, right?
We’re still not too sure if the Amazon Dash button is a brilliant marketing and advertising ploy, or is just downright stupid. But what we do know, is for $5, it’s a lot of hackable tech that could be used for more… useful purposes. The big A sells these dash buttons for one purpose — you push the button and whichever product is assigned to it shows up on your doorstep in a few days. [Ted Benson] wanted them to do more than that so he turned a few dash buttons into a way of tracking his baby’s health!
Apparently, data acquisition of your baby’s wake-up times and poops is useful to identify health patterns. [Ted] tried using some phone apps to keep track of this stuff, but found it would be a lot easier if there was just a big button on the wall or something… which is where he got the idea to make use of the Amazon Dash button.
It’s actually really simple to do. Buy the dash button, do the setup with Amazon… but don’t do the final step: selecting the product you want to order. If you don’t select anything, you won’t order anything…
Continue reading “Hacking the Amazon Dash Button to Record Whatever You Want”
[Voltagex] was fed up with BSODs on his Windows machine due to a buggy PL2303 USB/serial device driver. The Linux PL2303 driver worked just fine, though. A weakling would simply reboot into Linux. Instead, [Voltagex] went for the obvious workaround: create a tiny Linux distro in a virtual machine, route the USB device over to the VM where the drivers work, and then Netcat the result back to Windows.
OK, not really obvious, but a cool hack. Using Buildroot, a Linux system cross-compilation tool, he got the size of the VM down to a 32Mb memory footprint which runs comfortably on even a small laptop. And everything you need to replicate the VM is posted up on Github.
Is this a ridiculous workaround? Yes indeed. But when you’ve got a string of tools like that, or you just want an excuse to learn them, why not? And who can pass up a novel use for Netcat?
There’s a big problem with the Internet of Things. Everything’s just fine if your Things are happy to sit around your living room all day, where the WiFi gets four bars. But what does your poor Thing do when it wants to go out and get a coffee and it runs into a for-pay hotspot?
[Yakamo]’s solution is for your Thing to do the same thing you would: tunnel your data through DNS requests. It’s by no means a new idea, but the combination of DNS tunneling and IoT devices stands to be as great as peanut butter and chocolate.
DNS tunneling, in short, relies on you setting up your own DNS server with a dedicated subdomain and software that will handle generic data instead of information about IP addresses. You, or your Thing, send data encoded in “domain names” for it to look up, and the server passes data back to you in the response.
DNS tunneling is relatively slow because all data must be shoe-horned into “domain names” that can’t be too long. But it’s just right for your Thing to send its data reports back home while it’s out on its adventure.
Oh yeah. DNS tunneling may violate the terms and conditions of whatever hotspot is being accessed. Your Thing may want to consult its lawyer before trying this out in the world.
Normal WiFi is not what you want to send video from your quadcopter back to the first-person-view (FPV) goggles strapped on your head, because it’s designed for 100% correct, two-way transmission of data between just two radios. Transmission of analog video signals, on the other hand, is lossy, one-way, and one-to-many, which is why the longer-range FPV flights all tend to use old-school analog video transmission.
When you’re near the edge of your radios’ range, you care much more about getting any image in a timely fashion than about getting the entire video sequence correctly after a delay. While WiFi is retransmitting packets and your video is buffering, your quadcopter is crashing, and you don’t need every video frame to be perfect in order to get an idea of how to save it. And finally, it’s just a lot easier to optimize both ends of a one-way transmission system than it is to build antennas that must receive and transmit symmetrically.
And that’s why [Befinitiv] wrote wifibroadcast: to give his WiFi FPV video system some of the virtues of analog broadcast.
Continue reading “Wifibroadcast Makes WiFi FPV Video More Like Analog”
Ethernet has been around since the mid-70s, but if you think it was always Cat5 and 10BaseT, you’d be sorely mistaken. The first ethernet was built with coaxial cable, vampire taps, AUI adapters, and a whole bunch of other network hardware that will make wizened networking veterans cringe. [Matt] had heard about these weird physical layers back when he started building networks in 1997, but he had never seen one. Now it’s an ancient and forgotten footnote in the history of computer networking. Is it possible to build a Thicknet in this modern era? It turns out, yes, it’s possible. It’s not easy, though.
The network [Matt] is building is a true 10Base5, or Thicknet, network. The backbone of this network is a coaxial cable 9.5mm in diameter. [Matt] discovered that while the common belief that Thicknet used RG-8/U cable. This appears to be incorrect, as the connectors for this cable – vampire taps that pierced the insulation and shield of the cable – are designed for cable manufactured by Belden, part number 9880.
[Matt] assembled the cable, vampire taps, AUI cables, and even found a few ISA NICs that would still work with a reasonably modern computer. He even went so far as to build a USB Ethernet adapter with an AUI interface. This impossibly retro device uses a standard USB to 10BaseT Ethernet adapter, with a chip designed to convert 10BaseT to AUI hacked onto a circuit board. That in itself is an incredible piece of engineering, with a handful of power supplies to get the correct 2.5, 3.3, 5, and 12 Volts to the right places.
As far as exercises in computing history go, [Matt] is at the top of his game. In the process of building it, he also figured out why no one uses Thicknet anymore; once it’s in place, you can’t change it, the cable is big, bulky, and the connectors are terrible. Still, it’s an amazing example of how far we’ve come.
[Alessandro] is an unlucky VoIP PBX administrator that frequently has to deal with very, very dumb network policies. Often times, he’ll have to change something on his setup which requires him to go out to his client’s location, or ask a client to use Teamviewer so the appropriate change can be made from behind a firewall.
This isn’t the solution to the problem. It will, however, fix the problem. To get around these firewalls, [Alessandro] is using the voice channels he already has access to for changing configurations on his VoIP boxes.
The implementation of this uses the AX.25 amateur radio modules that can be found in just about every Linux distro. This, and an Alsa loopback device, allows [Alessandro] to access a terminal over a voice-only network. Is it a hackey kludge? Yep. Is it just a little bit dumb? So are the network policies that don’t allow [Alessandro] to do his job.
This build isn’t too dissimilar than a bunch of modems from the old BBS days, albeit with vastly more powerful software. [Alessandro] says you’re only going to get about 38400bps out of this setup, but it beats begging for help for remote access.