Scratch Link connection for hardware extensions should work without Internet access

[cwillisf]

Expected Behavior

If Scratch Link is running, hardware extensions like the micro:bit, LEGO WeDo 2.0, etc., should work whether or not the computer is connected to the Internet.

Actual Behavior

Connecting to Scratch Link requires an Internet connection: specifically, we need DNS to resolve the device-manager.scratch.mit.edu name to an IP.

Proposal

Scratch Desktop is a different security environment for the Scratch editor, and in particular it can probably be configured to connect to Scratch Link over plain ws:// instead of wss://. In that scenario we wouldn't need to validate the name on a digital certificate, so we wouldn't need to connect using a DNS name: we could just connect to ws://127.0.0.1:<port>/ and avoid the need for DNS altogether.

This would require Scratch Link to expose a regular ws:// port in addition to its current wss:// port but that should be easy.

[Timurinyo]

Is it possible to fix this before 24th of May? We have an Olympiad in robotics in Ukraine for more than 200 kids using Scratch 3.0 to program their WeDo 2.0 robots. Parents are going to use WiFi hotspots on their phones to let kids connect to robots, but that seems to become a disaster.

[towerofnix]

^ Ping @thisandagain!

@Timurinyo you may be best contacting the ST through Contact Us and sharing the ticket number with thisandagain through Scratch. I'm not entirely sure that the ST reads every comment immediately, and... well, it'd need to be seen quite immediately, since the 24th of May is just four days away.

(Seeing as that's the case, you probably shouldn't count on it anyway -- not only would fixing it take considerable* and immediate time/effort, it'd need to be published to the Scratch website or Scratch Desktop, unless you happen to be 1) able to build the editor with the fix yourself and 2) distribute it to all the target devices at your event.)

(* though I don't know how considerable since I have no idea what sort of code resolving this issue would take!)

[thisandagain]

@Timurinyo Unfortunately this is a fairly complex issue that will take quite a bit of time to resolve and will not be done in time for your event.

My apologies, but I hope we can help make this better in the future!

[Timurinyo]

Maybe you can suggest some temporary fix? For example some little snippet that will resolve the name instead of DNS?

[cwillisf]

@Timurinyo for this to work correctly, device-manager.scratch.mit.edu must resolve to an IPv4 loopback address. Depending on your operating system you may be able to adjust a hosts file to make this happen, but doing so is not officially supported by the Scratch Team. Modify your hosts file at your own risk!

[Timurinyo]

@cwillisf It worked. Thanks for being so helpful!

[y05s]

Hi this is my first post of GitHub.
I'm @y05s from scratch3.0 thread, discussing about "scratch link never work on my local network".
https://scratch.mit.edu/discuss/topic/354657/?page=1#post-3597312
I've just solved my issue above, and this Github thread was much useful for me. I have to say thank you so much!!!

To prevent security risk, latest DNS masquerade service is rejecting to map to private ip-addresses, such as 192.168.*.* ,127.0.0.1 . The DNS record of device-manager.scratch.mit.edu to 127.0.0.1 matches to this restriction. Please refer following discussion for your more understanding:
https://news.ycombinator.com/item?id=12408918

At least a school local network has this secure router configuration, it can be found in scratch3.0 thread, and similar sites would be increasing.
Please consider/plan to discontinue using this DNS record.
Thank you.