Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our User-Mode WireGuard Year

fly.io

Post reply on HN
Print view View original

141–150 of 169 posts

Re: Our User-Mode WireGuard Year

#141

Post by efitz »

croon wrote: post #135
chrissnell wrote: post #97

Earlier quoted context omitted.

SLIP was a problem for us when I worked at an ISP in 1995. Cheapsakes would buy our barebones "shell access only" package and then run SLIP on our shell server. We eventually wrote a cron job to kill their processes when we found them. Sneaky ones just renamed the binary.

Man I miss the old internet when things were more playful and that was the extent of harm being done. Not that I condone cheapskates stealing your bandwidth. Maybe it's just rosy nostalgia.

Remember when security was pretty much just scanning floppies for viruses before you ran the program?

Re: Our User-Mode WireGuard Year

#142

Post by efitz »

TFA is surprisingly unapologetic about the Rube Goldberg SSH solution.

On the other hand fly.io looks really interesting, I want to try it out. The infrastructure described (other than the SSH hack) feels like how a modern cloud platform should be built.

Re: Our User-Mode WireGuard Year

#144

Post by the_biot »

mrkurt wrote: post #143
the_biot wrote: post #131

It's a little surreal to see all this cheering and adoration of fly.io, but they can't even keep their blog webserver up. It's not a great look for a cloud-related company.

Our blog webserver is fine. What kind of error did you see?

Times out, rarely gets the page out.

Re: Our User-Mode WireGuard Year

#145

Post by coder543 »

mastax wrote: post #139
MisterTea wrote: post #137

Earlier quoted context omitted.

> The processor seems to score less than an RPi4 on Geekbench. The apu2 is an embedded AMD quad core 1GHz SoC consuming 5W. It is not a powerful system by any means and not surprised rivaled by a >1GHz quad core Arm.

The AMD Jaguar cores came out in 2013. On the other hand, the Cortex A53 came out in 2012 so it's still a bit embarrassing for AMD. That was before the AMD renaissance, though.

The Raspberry Pi 4 uses a quad core cluster of Cortex A72 cores, not A53. A72 was released in 2016, but the Pi 4 also has them clocked to run at 1.5GHz. Either way, I don't think it's embarrassing for AMD's 2013 Jaguar to be beaten by cores that are 3 years newer and running at a 50% higher clock speed. I thought Jaguar was pretty cool at the time that it came out, but technology has continued to move swiftly since then.

Re: Our User-Mode WireGuard Year

#146

Post by mst »

dolmen wrote: post #134
mst wrote: post #123

Earlier quoted context omitted.

It's running its own TCP stack in userspace though so the hosting kernel's routing abilities aren't an issue. I am both impressed and horrified, and I mean that in the best possible way.

> I am both impressed and horrified, and I mean that in the best possible way. This sentence style sounded familiar in my head. Looking at the username. Oh, of course, that's him!

mstcat approves of this :D

(for those who don't know, http://trout.me.uk/mstcat.jpg )

Re: Our User-Mode WireGuard Year

#147

Post by mrkurt »

the_biot wrote: post #144
mrkurt wrote: post #143

Earlier quoted context omitted.

Our blog webserver is fine. What kind of error did you see?

Times out, rarely gets the page out.

Does debug.fly.dev work? Can you run `curl -v https://fly.io/blog/ -sS -o /dev/null -D-` and post what you see?

Re: Our User-Mode WireGuard Year

#148

Post by the_biot »

mrkurt wrote: post #147
the_biot wrote: post #144

Earlier quoted context omitted.

Times out, rarely gets the page out.

Does debug.fly.dev work? Can you run `curl -v https://fly.io/blog/ -sS -o /dev/null -D-` and post what you see?

debug times out as well. curl output:

   flake: curl -v https://fly.io/blog/ -sS -o /dev/null -D-
   *   Trying 2a09:8280:1::a:791...
   * TCP_NODELAY set
   * Connected to fly.io (2a09:8280:1::a:791) port 443 (#0)
   * ALPN, offering h2
   * ALPN, offering http/1.1
   * successfully set certificate verify locations:
   *   CAfile: /etc/ssl/certs/ca-certificates.crt
     CApath: /etc/ssl/certs
   } [5 bytes data]
   * TLSv1.3 (OUT), TLS handshake, Client hello (1):
   } [512 bytes data]
   * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fly.io:443 
   * stopped the pause stream!
   * Closing connection 0
   curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fly.io:443
Seems to work when forced to IPv4 though.

Re: Our User-Mode WireGuard Year

#149

Post by mrkurt »

the_biot wrote: post #148
mrkurt wrote: post #147

Earlier quoted context omitted.

Does debug.fly.dev work? Can you run `curl -v https://fly.io/blog/ -sS -o /dev/null -D-` and post what you see?

debug times out as well. curl output: flake: curl -v https://fly.io/blog/ -sS -o /dev/null -D- * Trying 2a09:8280:1::a:791... * TCP_NODELAY set * Connected to fly.io (2a09:8280:1::a:791) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs } [5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client…

Ok last thing, can you try `curl https://debug.fly.dev --ipv4` and tell me what the `Fly-Region` header says?

Thank you for helping with this!

Re: Our User-Mode WireGuard Year

#150

Post by anonymousisme »

chrissnell wrote: post #97
anonymousisme wrote: post #49

Back in the day (nearly 30 years ago) people would run a user-mode stack to obtain Internet connectivity via a (dial-up) Unix shell account. The program was "slirp" which was named after SLIP/CSLIP, but then upgraded to support PPP once that became a thing. https://en.wikipedia.org/wiki/Slirp

SLIP was a problem for us when I worked at an ISP in 1995. Cheapsakes would buy our barebones "shell access only" package and then run SLIP on our shell server. We eventually wrote a cron job to kill their processes when we found them. Sneaky ones just renamed the binary.

Heh. I used Netcom and they did not outright ban slirp, but they did have a script running that would renice (lower the priority) of user processes once they reached a certain total cpu time (two minutes). I discovered this feature shortly after they implemented it because my slirp network performance went down. Note that I am referring to cpu time and not run time. Most processes spend most of their time waiting for something, so accumulating two minutes of cpu time under slirp usually took several hours.

My solution was to write a program (I called checkcpu) that would spawn a process (slirp) and periodically check its total cpu usage. When it hit the threshold (110 seconds), it would spawn a child and suspend the parent (seamlessly passing the current run state to the child). It worked great and they either never noticed what I was doing, or they did not care. Over time, the number of suspended parent processes would rise, but it never became a problem.

Post reply on HN