>
VOID DNS responses that are blocked by a lot of networksFor ages I've been meaning to [figure out how to] report this to the iodine dev, but I actually set up iodine specifically to get a working network while I knew I'd briefly be visiting a hospital.
I discovered to my amusement that the (public!) hospital's IT infra is really, really good; I was trying to SSH directly on top of the iodine tunnel, and while the first few DNS requests associated with the connection setup would work and I'd get as far as getting a shell prompt, but everything would rapidly screech to a halt and jam up pretty much instantly after that; maybe I'd get a single character typed, then it would completely die. I figured I was looking at a remarkably well-put-together leaky-bucket implementation.
So I tried hacking usleep()s into likely-looking spots in the code, but that didn't seem to slow it down enough. iodine is a rather interesting program internally, and a quick overview while distractedly sitting in a waiting area wasn't entirely sufficient to figure out why I didn't seem to be slowing it down enough to be a problem.
Before this "production" test, I previously verified that iodine was working by running the client on an AWS box. IIRC, ping ran over the link for quite some time (less than an hour; many minutes) without a single hitch.
On another note, I found that iodine seemed utterly incapable of setting up a correctly-configured tunnel on my Arch (receiving/server) box; I always had to ifconfig the tunnel (I forget exactly) to make it work. Problem with that was, my ifconfig-ing only routed one specific IP address, iodine wanted to give connections their own discrete IPs, and old sessions that locked up would take a while to time out. So I made a gigantic hack-script that would repeatedly kill iodine over and over every 1.5 minutes if it didn't see an authenicated SSH login. Would be nice for everything to just work properly...