Re: [72attendees] In-room network

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 29 July 2008 16:13 UTC

Return-Path: <72attendees-bounces@ietf.org>
X-Original-To: 72attendees-archive@ietf.org
Delivered-To: ietfarch-72attendees-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFFD3A6BD0; Tue, 29 Jul 2008 09:13:25 -0700 (PDT)
X-Original-To: 72attendees@core3.amsl.com
Delivered-To: 72attendees@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32993A68AE for <72attendees@core3.amsl.com>; Tue, 29 Jul 2008 04:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.043
X-Spam-Level:
X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=1.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nQBQ7uJzQId for <72attendees@core3.amsl.com>; Tue, 29 Jul 2008 04:29:33 -0700 (PDT)
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id BB33F3A68A4 for <72attendees@ietf.org>; Tue, 29 Jul 2008 04:29:33 -0700 (PDT)
Received: from dhcp-130-129-19-120.meeting.ietf.org ([130.129.19.120]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6TBTfqS009719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 07:29:43 -0400 (EDT)
Date: Tue, 29 Jul 2008 12:29:40 +0100
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Marshall Eubanks <tme@multicasttech.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Message-ID: <25833CB3A33A957FCC91DC49@atlantis.pc.cs.cmu.edu>
In-Reply-To: <200807290055.m6T0t26n004039@raisinbran.srv.cs.cmu.edu>
References: <0A7D7D6BC1EEF6489C3D0AE1B6B161950334B865@xmb-sjc-223.amer.cisco.com> <8BC845943058D844ABFC73D2220D4665077DD0FB@nics-mail.sbg.nic.at> <200807290055.m6T0t26n004039@raisinbran.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Tue, 29 Jul 2008 09:13:23 -0700
Cc: 72attendees@ietf.org, jhutz@cmu.edu
Subject: Re: [72attendees] In-room network
X-BeenThere: 72attendees@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the attendees of IETF 72 meeting." <72attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/72attendees>, <mailto:72attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/72attendees>
List-Post: <mailto:72attendees@ietf.org>
List-Help: <mailto:72attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/72attendees>, <mailto:72attendees-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: 72attendees-bounces@ietf.org
Errors-To: 72attendees-bounces@ietf.org

--On Monday, July 28, 2008 08:14:03 PM -0400 Marshall Eubanks 
<tme@multicasttech.com> wrote:

> Tonight from my room, I get connection failures for AIM, but jabber, ssh,
> http, etc., all work fine. It sounds like port blockage to me.

Really?  Have you collected any data that shows that your packets are not 
getting through?  Or are you simply assuming that if it doesn't work, it 
must be because the port is blocked?

Someone noted earlier that the hotel's NAT seems to be allocating a 
different outside IP address for each outgoing "connection" (which, for 
UDP, often means each packet).  There are certainly a lot of UDP-based 
protocols that that will break, if it's true (I'm not entirely convinced, 
because I run things that it _should_ break pretty badly but that seem to 
work fine).

FWIW, I've also noticed AIM breaking from behind other NAT's lately, which 
may indicate the protocol is NAT-unfriendly in some way.  That would be 
news to me, but then, it's not a protocol I use often, and I avoid NAT's 
when I can.

Of course, it's also possible that some people's VPN connections are 
breaking because they expect to use a particular port, either for tunneled 
traffic or for IKE, or because they expect to use a protocol for which the 
NAT cannot multiplex multiple connections.  Those of us who've done this a 
few times presumably know about these pitfalls by now, but there will 
always be someone who's never encountered the problem before.


I would suggest that if folks are having problems getting particular 
protocols to work, that they collect as much data as possible about what is 
going on and then report the problem to the hotel.  Maybe one of the NOC 
folks can give us an idea of what sorts of data are most useful.

-- Jeff
_______________________________________________
72attendees mailing list
72attendees@ietf.org
https://www.ietf.org/mailman/listinfo/72attendees