Our website would like to use cookies to store information on your computer. You may delete and block all cookies from this site, but parts of the site will not work as a result. Find out more about how we use cookies.

Login or Register

Powered by
Powered by Novacaster
 
iChat testing - are your ports OK?
by Simon at 12:26 17/08/07 (Blogs::Simon)
Fed up with a problem chatting to folks-in-law in the US (it's worked for 18 months, and then suddenly stopped), I decided to write a bit of Perl to see if UDP and TCP was getting through successfully.

Now, in order for this to be useful you need to have a packet filter/traffic watching tool installed and logging on the remote machine ie the one you're NOT running the script from.

All we're looking for is that the packets end up being seen to arrive on the remote side.

I use Interarchy because it lets you describe filters using the PCAP packet filter logic.

Here's the Perl script ("ichattest") - very rough and ready:

#!/usr/bin/perl -w

$|++;
use strict;
use IO::Socket;

# Usage: ./ichattest remote_host

# Send UDP datagrams and TCP connection attempts to iChat required ports
# from this machine to a remote machine to see if they get through or not.

# Needs a packet logging tool (eg Interarchy) on the remote machine
# configured to watch with this filter:

# (udp or tcp) and (src sender_ip and dst receiver_ip)

# sender_ip will always be the publicly visible ip of the sender but
# receiver_id may be an unrouteable address if the remote machine is
# behind NAT.

# The single command line param remote_host will always be a routable IP 
# assuming you're not trying to test between machine on your local private LAN

# We expect to see UDP datagrams logged on the remote machine on ports:
# 5060, 5190, 5678 and 16384 to 16403 inclusive.
# We may also see 5059, 5061 to 5063 logged but those aren't required for iChat

# We expect to see TCP connection attempts on ports 5190 and 5298, but
# we don't expect successful connections.

my $host = $ARGV[0];

die "Need to specify host\n" unless $host;

_tcp();
_udp();

sub _udp {
        for my $port (5059 ... 5063, 5190, 5678, 16384 ... 16403) {
                # Start at 5059 to bracket the range.
                # We don't expect socket errors here.
                print "UDP $port\n";
                my $socket = IO::Socket::INET->new(
                        Proto => "udp",
                        PeerPort => $port,
                        PeerAddr => $host
                ) or die "Can't make UDP socket (it's not OK):\n$@\n";
                $socket->send("UDP Ping!");
                sleep 1;
        }
}

sub _tcp {
        for my $port (5190, 5298) {
                print "TCP $port\n";
                # We don't expect to be able to connect to these port
                # we're just trying to trigger an entry in the packet
                # log on the $host side to check the firewall's open.
                my $socket = IO::Socket::INET->new(
                        Proto => "tcp",
                        PeerPort => $port,
                        PeerAddr => $host,
                        Type => SOCK_STREAM
                ) or do { warn "Can't make TCP socket (it's OK):\n$@\n"; next };
                print $socket "TCP Ping!";
                close($socket);
                sleep 1;
        }
}

(Attached below is a downloadable version - control click and "Save as")

What this has told me about my particular problem is that the remote side isn't seeing UDP datagrams sent to port 5060 from here, which means that something is filtering them out en route. It's not the remote side's firewall because I tested with the firewall off and on and got identical results.

Running the script on the remote side and logging here, I can see that all the required UDP and TCP stuff is getting through OK.

What seems likely is that the remote side's ISP (or one of its upstream providers) is blocking 5060 inbound. Alternatively, one of my upstream ISPs might be blocking 5060 outbound from here, but since I can video chat to people as far apart as the UK and Australia just fine, that seems unlikely.

Hope this may be useful for someone else.

Google fodder: Error -8, communications error, 10.4.7, OS X

--
simon

Attachments...
Plain text (2 K) ichattest Perl script
<< Freight Transport Association ... No right of reply >>
View Comments (Threaded Mode) Printer Version
iChat testing - are your ports OK? Simon - 12:26 17/08/07
Re: iChat testing - are your ports OK? Bruce Ure - 15:16 17/08/07
If you want another person to test with I have a macbook with a camera, not that I've ever set it up so there might be firewall tweaks to make.

--

Re: iChat testing - are your ports OK? Simon - 15:38 17/08/07
Cool - yes please.

Mail me your AIM or .Mac username so I can add you to my buddy list.

I'm (my usual cix id)@mac.com

There's an Apple tech note about which ports to open/forward on the OS X and/or third party firewall.

http://docs.info.apple.com/article.html?artnum=93208
--
simon

Re: iChat testing - are your ports OK? Bruce Ure - 17:06 17/08/07
Having said this I'm not sure I'll get it done today, as I'm out tonight -- and then I'm away next week in Italy. Will do my best though.

--

Re: iChat testing - are your ports OK? Simon - 17:12 17/08/07
Hopefully you're out tonight at JT's? Hugo and I are heading over.
--
simon
Re: iChat testing - are your ports OK? Bruce Ure - 17:33 17/08/07
Indeed I are... see you then!

--