Companion App - Ports?

317 views
Skip to first unread message
Assigned to jeffrey....@gmail.com by steve....@gmail.com

James Webber

unread,
Sep 27, 2019, 5:36:02 AM9/27/19
to MIT App Inventor Forum
Hi there,

I'm using the companion app on our school computers, and have had to open firewall ports to allow the traffic from our WiFi network to our school PCs.  I can't seem to work out what ports are used though - it seems to be a random UDP port every time the companion app connects.  Do I really need to open up every port between UDP ports 50000 - 64000 to get the companion app working? Or is there a way of forcing the companion app to connect to the school computer with a specific port, each time?

Thanks on any info.

James

James Webber

unread,
Sep 27, 2019, 5:42:39 AM9/27/19
to MIT App Inventor Forum
For clarity, these are the last source/destination ports for the connection between the wireless device and the local computer:

47770-53064
52642-61364
40612-51728
59784-57337
37381-55594

This doesn't seem to match with the "unblock port 8001" in the documentation.

Thanks!

SteveJG

unread,
Sep 27, 2019, 8:05:00 AM9/27/19
to MIT App Inventor Forum
The key ports that need to be unblocked are 8001 and 8004 James.  This article explains School IT/Network Admins: Information specific to school networks (also helpful for conferences and hotel situations)   This says   

the network must allow access to ai2.appinventor.mit.edu, rendezvous.appinventor.mit.edu, turn.appinventor.mit.edu (port 3478), and HTTP access from the student's computer to the phone or tablet on port 8001. So I expect you need to unblock only port 3478. Try that.


Regards,

Steve


    



James Webber

unread,
Sep 27, 2019, 8:26:27 AM9/27/19
to MIT App Inventor Forum
Thanks Steve. Unblocking that port for TCP and UDP does nothing. It's still trying to access a destination port in the 50000-68000 range, and it's a random one on every connection. Unblock the whole range for UDP, and AI2 Companion works perfectly - but obviously that's not a great solution!

Can anyone shed any more light?

SteveJG

unread,
Sep 27, 2019, 8:38:17 AM9/27/19
to MIT App Inventor Forum
Someone from MIT will comment.   You might clarify this statement "It's still trying to access a destination port in the 50000-68000 range,"; what is trying to access what?  Thanks.  Knowing specifically what you tried might help MIT to better determine what might be happening with your WIFI.


 In the mean while, to get the students working you might use a USB solution for live development http://appinventor.mit.edu/explore/ai2/setup-device-usb  This method would allow students to develop while the blocked port issue is sorted out.   It might work      

James Webber

unread,
Sep 27, 2019, 9:13:11 AM9/27/19
to MIT App Inventor Forum
Thanks Steve,
I thought I was clear in the first reply, but the detail is that the ONLY packets of data being transferred between the wireless device (phone) and school computer are on a random port each time AI2 connects. We use smoothwall as our firewall, and so I can see in the firewall logs by searching for any packet that is coming into the network to the destination IP of my school computer from the source IP of the wireless network. I do this in realtime, and as the documentation states there is a connection made within our network after the handshaking process on the MIT side - I've definitely narrowed it down to this problem.

There is no need for us to use the USB solution - I've unblocked the port range for now.

I look forward to receiving a reply from MIT who may be able to help diagnosing it.

TimAI2

unread,
Sep 27, 2019, 9:14:39 AM9/27/19
to MIT App Inventor Forum
Smoothwall is a wonderful thing......  ;)

Chris Ward

unread,
Sep 27, 2019, 10:02:27 AM9/27/19
to MIT App Inventor Forum
Hello James

I think you should contact Smoothwall Support, they are going to know a lot more about their fire wall than MIT :)  The MIT document lays down the requirements to work with App Inventor, so the Smoothwall guys should know what is right and what is wrong with your set up.

James Webber

unread,
Sep 27, 2019, 10:08:21 AM9/27/19
to MIT App Inventor Forum
This isn't a smoothwall problem? I'm just using it to view where the issue lies - the logs clearly show a random destination port being given each time I do the connection (so it tries 30 or so requests on that port). I reset the connection in AI2, click AI2 companion again, scan the barcode on my phone - and the smoothwall shows the connection is now a different port.

I'm failing to see how Smoothwall Support could help with that? It's clearly that the connection is being opened on a random (high) port - the smoothwall wouldn't be rerouting the UDP packets from a set port to a random one itself, which is why I'm thinking the AI2 companion is either set to send it on a random UDP port, each time.

James

jeffrey.schiller

unread,
Sep 27, 2019, 3:34:13 PM9/27/19
to MIT App Inventor Forum
OK. Let me explain what is going on.

There are two modes for the browser to connect to the Companion. The older mode, now labeled “Legacy Mode” requires port 8001 between the PC and the device. (and port 80 access to rendezvous.appinventor.mit.edu).

The default mode, aka non-Legacy mode, uses a newer technology called WebRTC. WebRTC uses UDP and indeed chooses a random port in a large range. Unfortunately we have no control over this. On the phone side the ports are chosen by a WebRTC library that we are loath to modify. And on the browser side, the ports are chosen by the browser where we have no control whatsoever.

For now if you do not want to unblock the UDP ports in question, then you can use legacy mode which only uses TCP over port 8001. HOWEVER at some point we will deprecate legacy mode, though we do not have a schedule established yet.

We will need to deprecate legacy mode in order to support serving MIT App Inventor over https. If you look at your browser’s location bar you will see we are using just http, which the browser vendors are labeling “insecure” (because it is...). However if we serve MIT App Inventor over https, then the *browsers* will not let legacy mode work. This is why we are moving to the WebRTC solution.

-Jeff

ABG

unread,
Sep 27, 2019, 3:56:45 PM9/27/19
to MIT App Inventor Forum
A documentation update and a FAQ entry are required here.

has no mention of UDP ports fro WebRTC, nor does the Companion
I nominate JIS for that.

Can some one remind me of the FAQ update link?
(I am on my secondary laptop)

ABG

Chris Ward

unread,
Sep 27, 2019, 4:11:23 PM9/27/19
to MIT App Inventor Forum
Private email to you ABG

ABG

unread,
Sep 27, 2019, 4:22:26 PM9/27/19
to MIT App Inventor Forum
(added to Companion and Emulator section of FAQ)
ABG

James Webber

unread,
Sep 29, 2019, 6:38:27 AM9/29/19
to MIT App Inventor Forum
Hi Jeff,

Thank you so much for your explanation, which makes total sense given what our logs were showing. A small plea from schools that deprecating the legacy mode would definitely cause a headache, given the port range that would need unblocking between our wireless VLAN and main computers - I can see many network managers baulking at the idea of unblocking traffic to 15,000 ports to any traffic.  Is there definitely no better solution from your end, or could this be a consideration before Legacy mode is deprecated?  Happy to use 8001 and legacy mode, at present with our smoothwall. 

Thanks so much again for your reply.

James
Reply all
Reply to author
Forward
0 new messages