curl + HTTPS doesn't seems to work

[kenorb]

I'm testing the following commands which doesn't work at demo site:

curl ifconfig.me

Basically it couldn't resolve the host.

Is there any solution to that?

Seems the network support works partially.

I'm using Chrome 45 on OS X.

[s-macke]

You have found a strange problem. I tried "curl ifconfig.me" on three different Linux servers and the response was not reliable and always slow. Sometimes the service answered, sometimes not. Sometimes it took 20 seconds or more. So my guess is, that it is not directly related to jor1k. try "curl -v ifconfig.me" to check the debug output. I had success with jor1k in around 50% of tries to get the external IP. Maybe there is another similar service you can try.

The proxy jor1k uses is hosted in USA on a server from DigitalOcean

[s-macke]

Can you try ifconfig.co ?

[kenorb]

Thanks for reply.

Yes, ifconfig.co seems to work.

What about something like:

curl -v https://api.github.com/orgs/StackExchange/repos

I was reading here (#65) that SSL support is enabled.

I'm asking, as I wanted to do some experiment as sandboxing for the purpose of this challenge, just for fun.

And I've found this emulator fairly advanced (in terms of networking support) from that list.

[kenorb]

Ok, I've re-tested it and it actually worked this time. Seems DNS sometimes fails to resolve.

curl: (6) Couln't resolve host 'api.github.com'

But most of the time it doesn't work for some reason.

[s-macke]

Yes it works also for me.

The networking support should be complete. There is no limitation except limited speed and that the connection to the outside world runs through a NAT. With this network configuration It is not possible to run a jor1k instance as a server.

[bsapwindows]

Maybe you could try run jor1kgui.ethernet.OpenSocket() in Chrome console. It worked for me. Every jor1k instance will get only 900 of lease time (in seconds I assume), I think that's what caused this, which gave me the idea to host my own relay.

[s-macke]

Hmm, is this a problem? Maybe you want to ask @benjamincburns to change the lease time on the server.

[bsapwindows]

@s-macke Well, I'm just suggesting that if anyone has problems like curl couldn't resolve host, it maybe because you have been opening the jor1k page for too long. And running jor1kgui.ethernet.OpenSocket() in console will bring back network support without refreshing the page.

I think that's also the reason that sometimes people say the relay is down while you say it's on. Because you test the network right after you created a jor1k instance. If you waited for a few more minutes, you might be able to reproduce the error.

I wasn't even sure it's causing this because technically it should renew the dhcp lease automatically. I thought the lease time is by design, and current networking solution has demonstrated enough how jor1k with network support works, so I didn't ask Ben to modify it, and I bypassed the limit by setting up my own relay. And yes, I modified the lease time on my relay, the network seems to work even after 2 hours I created a instance. Sorry for my poor English, hope there's no misinformation.

[benjamincburns]

The lease time shouldn't need to be changed. Likewise, you shouldn't need to run jor1kgui.ethernet.OpenSocket() yourself.

The websocket code automatically reconnects when the connection drops - usually due to sitting idle for too long. This reconnect behaviour is transparent to the virtual machine, and to dnsmasq. That is, it doesn't prompt a new DHCP lease request, and it shouldn't need to. It's essentially the same as disconnecting some switch between your virtual machine and the DHCP server (dnsmasq). There's no way for dnsmasq to be aware of it, and since it's a lower network layer concern, there's no need for it to be aware of it.

I use a /16 subnet with a fairly low DHCP lease time because I want to make sure that there are always IP addresses available to lease, even when we see big spikes of traffic to the jor1k demo server. If you leave your browser open for long enough, the DHCP client (I forget which one is on the VM image) should auto renew the lease. Provided you don't close your browser or change your MAC address, you shouldn't lose your lease, even if the websocket connection drops a few times here and there.

[benjamincburns]

Back to the specific issue at hand...

@kenorb - in #65, I added SSL support to the websocket which tunnels ethernet frames between the emulator running in the browser and my virtual switch (benjamincburns/websockproxy). This means that the tunnel which carries your ethernet frames is now encrypted. It does not have any bearing on SSL support within the VM itself.

With respect to ifconfig.me - it appears to not support https. When I run curl https://ifconfig.me I get curl: (7) Failed to connect to ifconfig.me port 443: Host is unreachable. Likewise, when I run curl https://www.ifconfig.me I get curl: (7) Failed to connect to www.ifconfig.me port 443: Host is unreachable

It's not a DNS issue, as per the command nslookup ifconfig.me, it resolves to 153.121.72.211 and 153.121.72.212.

ping -c3 ifconfig.me works, so the host is alive.

curl https://www.google.com/ spits out the source of the google homepage, so SSL support is enabled in curl and the default root certificate authority certs are installed properly into the rootfs.

Finally, when I run curl http://ifconfig.me, I get the public IP of the relay 104.131.203.111.

[benjamincburns]

Closing this issue as not reproducible.

@s-macke please feel free to override.

[bsapwindows]

Hi @benjamincburns! Thanks for the clarification. In fact I agree with you. But I'm still experiencing this issue, it's reproducible from here. I'll attach a screenshot. I used date +%M to generate timestamps. As you can see, google.com was resolvable at first, 12 minutes later, it became unresolvable. I'm sure there is something going on. I just don't know what it is.

By the way, may I ask which browser are you using?

[benjamincburns]

I test with latest Chrome and Firefox. I'll have a look at the websocket reconnect behaviour and make sure it's still operating properly.

[benjamincburns]

In Chrome 45.0.2454.85 running on Ubuntu 15.05, the Websocket reconnect behaviour works, and after 15 minutes of idle time I can still curl https://www.google.com/.

Reconnect behaviour can be seen working by opening the JS console and looking for the text Websocket closed. Reopening. If connections fail three times, we stop trying. If connection succeeds, we reset the retry counter to zero.

[benjamincburns]

Both tests also successful in Firefox 40.0.3.

[bsapwindows]

I just tested. Chrome 45.0.2454.101 on Windows works. So does Firefox 40.0.3. Even IE 11 works too. But NOT Chrome 37.0.2062.124, which I've been using (because there are issues like font rendering and tab openning in many versions after that). This still can not explain why changing the lease time on my relay fixed the problem though. No idea what else I did caused this.

Anyway, sorry for wasting your time guys.

[benjamincburns]

No worries, John. I wouldn't have answered if I viewed it as a waste of time. :-)