ATC on VATSIM

[Vincent Games 1142767]

Is there a way I can ATC on VATSIM if I have a Mac?

[Wade Williams 877539]

Currently only by running Windows and VRC through Boocamp (or VMWare, though there's some tricks involved in that and it's not really recommended).

 

There is at least one Mac radar client in development however.

[Jordan Krushen 1135174]

Sorry for the late reply, but I use VRC and TeamSpeak in a Parallels VM on Snow Leopard with dual monitors. I don't have to reboot to control and it works really well for me, and the VM is only set to use 256MB of memory. Clicking on URLs opens them on the Mac side in Safari, which I like.

 

Let me know if you (or anyone else) need any help getting it set up. There are a couple of things to be aware of, such as making sure you have 'Optimize modifier keys for games' checked, so that holding CTRL down works as a PTT button in TeamSpeak.

 

I tried using VMware Fusion as well, but Parallels works much better for me.

 

J.

[Tony Koch]

I am running a MacBookPro 10.5.8 with VMware Fusion 3.0.2 running XP with more or less success for VRC and Teamspeak. The only wrinkle is a receive transmit timeout after 5 or 6 minutes of not having pressed the push-to-talk button. Pilots cannot reach me by voice. Text works. I use the VRC timer to remind me to press to talk for a second and that resets the invisible timeout counter. VMWare tech support was unable to find a solution. Don't know if it's a Mac or VMware issue. That is the only flaw so far after 8 or 9 months on Vatsim.

[Jordan Krushen 1135174]

I am running a MacBookPro 10.5.8 with VMware Fusion 3.0.2 running XP with more or less success for VRC and Teamspeak. The only wrinkle is a receive transmit timeout after 5 or 6 minutes of not having pressed the push-to-talk button. Pilots cannot reach me by voice. Text works. I use the VRC timer to remind me to press to talk for a second and that resets the invisible timeout counter. VMWare tech support was unable to find a solution. Don't know if it's a Mac or VMware issue. That is the only flaw so far after 8 or 9 months on Vatsim.

 

I know how to fix that. Voice is coming in via UDP, port 3290. Because of how NAT works, after a timeout, it doesn't know where to send inbound packets. You need to set up a port forward, on every device from your router through to your VMware NAT settings, that forwards port 3290 UDP to your virtual machine.

 

In my case, I'm running Parallels in bridged mode, so I don't have to configure Parallels to forward anything as the VM gets an IP from my local network, but I have to forward port 3290 on my router to the IP that my VM gets. If you're running your VM behind a VMware NAT connection, you'll need to forward the port from your router to your VM host's IP, then configure a forward in VMware to your guest's IP.

 

That should do the trick.

 

J.

[Wade Williams 877539]

I am running a MacBookPro 10.5.8 with VMware Fusion 3.0.2 running XP with more or less success for VRC and Teamspeak. The only wrinkle is a receive transmit timeout after 5 or 6 minutes of not having pressed the push-to-talk button. Pilots cannot reach me by voice. Text works. I use the VRC timer to remind me to press to talk for a second and that resets the invisible timeout counter. VMWare tech support was unable to find a solution. Don't know if it's a Mac or VMware issue. That is the only flaw so far after 8 or 9 months on Vatsim.

 

It's a UDP timeout problem.

 

You need to edit /Library/Application Support/VMware Fusion/vmnet8/nat.conf and set timeout = 60 to timeout = 0 and then restart the machine. Note that you need to do this every time you update VMware since VMware will overwrite this file.

[Jordan Krushen 1135174]

You need to edit /Library/Application Support/VMware Fusion/vmnet8/nat.conf and set timeout = 60 to timeout = 0 and then restart the machine. Note that you need to do this every time you update VMware since VMware will overwrite this file.

 

Port forwarding settings should survive VMware updates, and address the problem more directly. They can also be managed in the GUI, without having to mess with the config files.

 

Timeouts exist for a reason While giving VMware an infinite timeout will work, it's not exactly the ideal way to fix the problem.

 

It's not really a VMware problem at all – it can happen to anyone behind NAT. I had the same problem running under Parallels, but the fix was to forward the port properly.

 

J.

[Tony Koch]

I should have mentioned that setting the UDP timeout to 0 has not solved the problem. I will explore the port forwarding idea, though. Thanks....Tony

[Wade Williams 877539]

Timeouts exist for a reason While giving VMware an infinite timeout will work, it's not exactly the ideal way to fix the problem.

 

Jordan,

 

I'm aware that timeouts exist for a reason.

 

The issue is, that unless VMware is in bridged mode, it won't be receiving voice on 3290. It will receive voice on a random high port. That doesn't seem to cause problems for most NAT routers, but it does for VMware's.

 

If you do operate in bridged mode, with most routers port forwarding 3290 for air-to-ground voice is not necessary. However, for ground-to-ground communications such as an override or more commonly trying to "Monitor" a controller, the port does usually need to be forwarded.

[Jordan Krushen 1135174]

However, VRC doesn't use port 3920 for air-to-ground voice. It only uses it for ground-to-gound voice (i.e. controller overrides/monitoring).

 

For air-to-ground voice, VRC sends a packet from a random high port to UDP port 3784 on the voice server, thus opening a path through the firewall / NAT device. Most devices seem to have no problem keeping that UDP connection open. However, VMware's NAT will not. After 60 seconds of no transmissions, it will start dropping the traffic.

 

As to why opening port 3920 worked for you, I can't say. It shouldn't have (except for ground-to-ground traffic).

Not sure where you're getting that info, but my packet sniffer disagrees with you. VRC sends a UDP datagram from port 3290 to remote port 3783 to initiate the voice connection, at which point all voice datagrams are received on local UDP port 3290 from remote port 3783. This is as an observer listening to another controller; I'll double-check that it's the same ports when I'm controlling tomorrow.

 

[Edit - just checked, and when controlling and checking Primary, VRC connects 3290 -> 3782. Still the same source port. Nobody online at the moment to confirm receiving voice datagrams, but after initiating the connection this way, one would [Mod - Happy Thoughts]ume the datagrams will be sent back to me on port 3290. It seems to want to transmit voice to 3782, and receive from 3783.]

 

In my particular case, I detected timeouts while listening to other controllers' frequencies in VRC by checking RX and HDST. I could listen to a controller (or ATIS, didn't matter, any incoming voice channel) for a few minutes before it would simply cut out. Unchecking/rechecking the HDST box would of course kick the connection, and it would work for another few minutes before dying again.

 

After initiating the connection from 3290 -> 3783, the local host will receive voice traffic on that port until NAT times out the table due to lack of outbound datagrams. Nailing up the port forward ensures that, even in the absence of outbound traffic (read: not hitting PTT in a while or receiving only as an OBS), datagrams that arrive at any point in the future will still arrive to port 3290 which VRC has open.

 

VRC is not using a random ethereal port outbound (it's always using port 3290), and it makes its connection to (and receives datagrams from) remote port 3783, not 3784.

 

I can't speak for any other versions of VRC or its behaviour on other operating systems, but this is the network traffic on mine. I'm running VRC 1.2.1 on XP SP3 under Parallels 5.0.9344 (bridged networking) on top of Mac OS 10.6.3. My edge / NAT device in question is a Time Capsule, where I have the port forwarded.

 

I did previously have my Parallels guest behind Parallels' NAT, and in that case also required a second port forward from host to guest, on top of router to host. The NAT from Parallels was IMO doing the right thing (just like the Time Capsule, and apparently VMware) by killing the routing table entry after a dearth of outbound traffic, thus requiring a port forward for spontaneously arriving inbound traffic without corresponding outbound traffic. I'm not a fan of multiple NAT, so I switched it to bridged mode, but I don't see how VRC would know or care (and then change its behaviour somehow) whether the VM is bridged or behind NAT.

 

Perhaps the docomeentation is simply wrong? VMware gets an awful lot of use in the networking world, so I'm disinclined to believe the problem is due to a fault in their NAT code, but I wouldn't rule it out entirely.

[Wade Williams 877539]

Jordan,

 

You'll see above I rewrote my post after trying it in bridged mode too. Indeed, in bridged mode, voice is delivered on 3290. However, most routers will work without having to have the port forwarded. (Though if you don't forward the port, ground-to-ground/monitor won't work)

 

Really either solution should work:

1) Operate in bridged mode and forward 3290 if necessary

2) Operate in NAT mode and remove the UDP timeout. (As you say, if you want to receive ground-to-ground communications, a double-port forward would likely be necessary)

[Jordan Krushen 1135174]

Jordan,

 

You'll see above I rewrote my post after trying it in bridged mode too. Indeed, in bridged mode, voice is delivered on 3290. However, most routers will work without having to have the port forwarded. (Though if you don't forward the port, ground-to-ground/monitor won't work)

 

Really either solution should work:

1) Operate in bridged mode and forward 3290 if necessary

2) Operate in NAT mode and remove the UDP timeout. (As you say, if you want to receive ground-to-ground communications, a double-port forward would likely be necessary)

 

Right, it took me a while to sample the traffic and get my post together, sorry.

 

I still don't see how VRC (or the server) knows or cares that it's in bridged mode or not, and would change the port. Technically, my machine is still behind NAT, the NAT device just happens to be another machine, thus the single port forward. It's bridged at the VM level, but VRC and the guest OS have no idea that that's even the case. It's behaving just as if the VM were a PC on the local network, from Windows' (and the server's) perspective. VRC should still open a connection from 3290, the server should still respond to 3290. If it is behind VMware's NAT, a UDP timeout modification still shouldn't change the ports on which VRC is listening, right?

 

So if the ports haven't changed, a simple port forward through the NAT will work fine. If you're bridged, then VMware won't require any port forwards, of course, as it's forwarding datagrams directly to the guest OS without translation. You only forward through routers, not bridges, as bridges can't and don't listen on ports, being Layer 2 devices.

 

I don't see this as being specific to VMware or VRC at all. If you require spontaneous inbound traffic behind a NAT device without recent, corresponding outbound traffic, you need a port forward through that NAT router. That's it. Everything else seems like a red herring, to me.

 

The port forward definitely worked for my problem, which was a timeout similar to what the OP was having, for the reasons in my previous post. I still have to confirm the details of the traffic when controlling (not observing), and I'll post those later.

[Wade Williams 877539]

I still don't see how VRC (or the server) knows or cares that it's in bridged mode or not, and would change the port.

 

I suspect that VRC->VMware NAT router is 3290, but if you look at VMware NAT->Intenet, you'll see that that the traffic uses a random high port. So if you're setting your external gateway to forward 3290, it will have no effect. I can show the package captures if you like.

[Jordan Krushen 1135174]

I still don't see how VRC (or the server) knows or cares that it's in bridged mode or not, and would change the port.

 

I suspect that VRC->VMware NAT router is 3290, but if you look at VMware NAT->Intenet, you'll see that that the traffic uses a random high port. So if you're setting your external gateway to forward 3290, it will have no effect. I can show the package captures if you like.

 

Okay, you're right – that is annoying, albeit correct behaviour, in the absence of a port forward. I would hope, thought, that it would understand that if you tried to forward port x through it's NAT, that it would specifically listen on the right port, and not use an ethereal one, 'cause if you add a forward it knows that all traffic on that port, regardless of destination, is only going to one guest address, and it wouldn't need to multiplex the port for multiple machines behind it, so it wouldn't need a random external port.

 

Every NAT device I've used (and I've used a lot of them, over the past 15 years) has behaved properly in this regard. VMware is actually quite within its rights to do this, 'cause NAT, in the absence of an explicit forward, will [Mod - Happy Thoughts]ume that traffic inbound has corresponding outbound traffic to keep the table entry in place, and also that multiple machines may need to receive on the same port concurrently, thus the random high ports. All that goes away with a forward in place.

 

Is there a chance you could test that for me? Add a UDP 3290 -> GuestIP:3290 port forward in VMware, and see if VMware uses 3290 externally instead of the ethereal port in your traffic traces? I'm betting that the ethereal port, as mentioned above, is simply due to it keeping the possibility of other hosts behind it (read: other VMs) needing to use the same port at the same time. The port forward precludes this, freeing it up to listen on the proper, fixed port.

 

This should make VMware listen on the proper port, so that you could add a similar port forward on your edge router (which again should listen on the proper port), and everything would work fine, without any mucking with timeouts. This is how I initially had mine working with Parallels (double NAT), until I switched it to bridged mode, and just have a single NAT forward on my edge device. Both setups worked fine.