Re: [72attendees] In-room network

Marshall Eubanks <tme@multicasttech.com> Tue, 29 July 2008 12:24 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 8A8EA28C1A4; Tue, 29 Jul 2008 05:24:10 -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 36F1328C1A4 for <72attendees@core3.amsl.com>; Tue, 29 Jul 2008 05:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.537
X-Spam-Level:
X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Lpzh1eBAgSt7 for <72attendees@core3.amsl.com>; Tue, 29 Jul 2008 05:24:08 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 2504B28C177 for <72attendees@ietf.org>; Tue, 29 Jul 2008 05:24:08 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 12281649; Tue, 29 Jul 2008 08:24:20 -0400
Message-Id: <1BCC7D52-F720-4B78-8255-4059B1BEF96C@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
In-Reply-To: <25833CB3A33A957FCC91DC49@atlantis.pc.cs.cmu.edu>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Tue, 29 Jul 2008 08:24:17 -0400
References: <0A7D7D6BC1EEF6489C3D0AE1B6B161950334B865@xmb-sjc-223.amer.cisco.com> <8BC845943058D844ABFC73D2220D4665077DD0FB@nics-mail.sbg.nic.at> <200807290055.m6T0t26n004039@raisinbran.srv.cs.cmu.edu> <25833CB3A33A957FCC91DC49@atlantis.pc.cs.cmu.edu>
X-Mailer: Apple Mail (2.926)
Cc: 72attendees@ietf.org
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"; DelSp="yes"
Sender: 72attendees-bounces@ietf.org
Errors-To: 72attendees-bounces@ietf.org

Something that I did not mention that is relevant is that I was using  
AIM from the room Sunday night.

So, something changed over 24 hours.

Regards
Marshall

On Jul 29, 2008, at 7:29 AM, Jeffrey Hutzelman wrote:

> --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