As much as I love the Pi, itās shitty USB Ethernet controller is a real drag for projects like this. I hope they have a good watchdog in there that can boot the interface when it inevitably crashes. Itās not designed for heavy sustained loads.
For that matter, a hardware watchdog that reboots the Pi when it locks up (due to buggy USB Ethernet driver) would be a good thing too.
Interesting @jandrese thanks! Is the WiFi controller any better in your experience? Weāre still in the early stages with this overall and are by no means experts in this whole area. Would you recommend something other than a Pi?
Most of the hardware I used to like isnāt made anymore, and is slow by todayās standards anyway. WiFi has its own set of issues, especially since I think the Pi WiFi controllers Iāve seen sit off of the USB. The Pi is a bit limited because it doesnāt expose a PCI or PCIe type bus, just some GPIO, video, audio, and USB.
I think the BeagleBone uses a proper connection to the Ethernet, but I donāt have enough experience with it to say definitively if it is more stable than the Pi or no. Itās also $20 more expensive, which might be a dealbreaker. It does come with built-in flash memory however, so you donāt have to buy an SD card.
The Pi is pretty hard to beat on a power/price ratio, but you pay for it with some unfortunate design decisions. Also, the community support you get with the Pi is better just because there are so many more users.
Crontab
1 1 * * * root shutdown -r
?? Total hack and doesnāt solve the root problem, but for a really cheap device it could allow for a modicum of consistency. That is if that p2p session can be auto renegotiated with a new peer.
I once encountered a mode when even the hardware reset signal did not reboot the pi.
A good solution I made as a part of a bigger in-house project is controlling power to Pi with a P-FET transistor, controlled by an ATmega (or so) microcontroller, connected to the Pi via UART (or even I2C or SPI if you need said UART). It runs a timer, reset by messages from Pi. If the timer is 40 seconds to timeout, it tells Pi that it is about to power down; if it is still alive, it can do a clean shutdown in that time. Then, power down, few seconds off, power up. There can be more than one watchdog, and it can be zeroed from cron (once per minute or two or so) and/or remotely via e.g. a remote HTTP request. That covers most of the scenarios when something goes wrong. (Avoid a continuously running daemon. Sometimes on small embedded systems kerbel gets into a pinch and keeps running existing processes but refuses spawning new ones. Make these things a part of the watchdog zeroing routine, so if they fail, restart happens.)
(Edit: you actually donāt need a full-blown microcontroller. A rudimentary version of the same can be done with a pair of 555 chips, communicating via GPIOs - one for keepalives, one for the upcoming-reboot message. Be sure to feed the keepalive pulse through a capacitor, so if it gets stuck at the āOKā value its lack would still get through.)
I also have a thought, though not tested, how to repair a damaged SD card. Make an adapter with 74HCsomething (or a little CPLD), switching between two cards - one to the Pi, one to a card reader on its USB port. The main card is the one from which the Raspi runs, the second one is a service one that gets automatically switched in if booting from the main one fails (a job of the watchdog microcontroller). (And then either do an automated reimage of the main card, or send a message to the sysadmin who can do it manually, remotely.)
SD cards use SPI protocol, just a few wires, all of them unidirectional. I saw some vaguely similar hack on hackaday.com some time ago. 1-to-2 digital multiplexers/selectors with all the A/B selector inputs wired together could do the job. Another option is using something like 74HC244 or 74HC245 (8x bus driver), wire them in a way that one set connects main card to raspi and service one to reader, the other vice versa, and tristate the outputs of either of them as needed.
That is a great idea, and you learn something new (this time about pi) every day. I hope @adamfisk comes back, I am curious how lantern will handle āinconsistentā nodes. If it is resources that can be streamed via a dht that would be fine for error correction. But interactive services like say ssh would really require more like a Tor circuit.
A more complex version can use a tcpdump-like daemon sitting on the eth0 interface and listening. (Can be done even with tcpdump itself, running from bash and listening to something low-traffic but always-there, e.g. ARPs on the LAN. And, if the read is blocking (tcpdump | while read x; doā¦), touch a file each time the packet is detected, and have another thing running from cron that checks the fileās timestamp (and if the check daemon is running and restart it if necessary). If the file grows older than a limit, reboot.
Yet another possibility is pinging a target; if the targets do not respond for too long, reboot.
This does not catch the (rare but they happen) full-scale freezes, though. Only the dead eth0.
If the downtimes happen once per several days per node in average, it should work for pretty much anything.
Yeah, the downside is you need another board with an interface that can run tcp dump. Are you familiar with any cheap ones that can? Iāve always thought about building a cheap little ARP mitm device that could be hidden in say a flower pot to sell to pentesters. It would be fun 
You actually donāt. If the raspi itself is alive inside, and only the ethernet interface dies and not the whole system, you detect the absence of signal on the eth0 āfrom withinā.
If the thing dies entirely, a conventional watchdog I described above will do a better job anyway.
I thought about a similar device, a MITM firewall, that would in real time monitor packet headers, and act as a firewall; if something tries to access nonwhitelisted port from a nonwhitelisted IP, corrupt the rest of the packet so its CRC fails and it gets rejected.
Forging a reset is a little cleaner, then you donāt have to deal with retries.
Anyway, Iām excited to see how this little guy works. Guess I should just check the kick starter
Then you have to inject a whole packet, instead of just a block of zeroes or some random crap, and you have to handle both Rx and Tx pairs. The simpler solution does not care how many retries come, not even the TCP/SYN gets through.
The lantern thing is a freaking cool idea, and if one wants an objective lesson in how little nerd cred one really has: start reading about the RasPi. Pi fans are a whole 'nother level but, as has been said, they are so helpful and so interested in helping others with their Pi projects.
Also http://www.themagpi.com/ is a great resource for finding out what things people are doing with their RasPi.
PS: How would this tool differ from something like TOR and if the answer is ānot muchā Iād ask whether itās worth reinventing the wheel or whether it would be better to incorporate TOR and add more nodes to an existing privacy-oriented network.
TOR has two big strikes against it.
- It is well known so oppressive regimes will block it. Of course if this project is successful it will have the same problem.
- Itās a US Government project, and that makes some people nervous.
This topic was automatically closed after 5 days. New replies are no longer allowed.
