On Thu, May 18, 2017 at 10:08:09AM -0400, Craig Brauckmiller wrote: Then you have cut your own throat by disabling one of the internet's primary troubleshooting tools. Yes, it connects from 169.228.66.251: telnet 96.86.86.53 443 Trying 96.86.86.53... Connected to 96-86-86-53-static.hfc.comcastbusiness.net. Escape character is '^]'. ^] telnet> q Connection closed. I have been told that comcast-provided CPE doesn't allow protocol 4 through it unless it is placed in raw bridge mode. - Brian

Comcast Business cable modems *do* allow protocol 4. I can't speak to the consumer service. Michael N6MEF

Ok, is anyone on Google Chat aka Hangouts? I'd love to run some live troubleshooting. Thanks Craig KC1ETB(a)gmail.com for Hangouts. On Thu, May 18, 2017 at 11:04 AM, Brian <n1uro(a)n1uro.ampr.org> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > For clarity sake... > > On Thu, 2017-05-18 at 07:20 -0700, Michael Fox - N6MEF wrote: > > > > I have been told that comcast-provided CPE doesn't allow protocol 4 > > > through it unless it is placed in raw bridge mode. > > > Comcast Business cable modems *do* allow protocol 4. I can't speak to > the > > consumer service. > > Comcast as a corporate policy does not have a filter on ip protocol 4 by > default. While there are a good number of things they do filter, ip > protocol 4 blocking is a byproduct of their socket watchdog timer... and > it affects inbound only. Outbound is fine pending you're able to receive > RIP. Unfortunately, there's no user menu control to disable this in > their devices so one fix would be to place the Comcast CPE into bridge > mode and supply your own device in which you have the ability to shut > off the watchdog timers. > > I wrote up documentation about this after spending a good part of this > past saturday night working on some end point issues with BK. You may > find it, and some tests, at > https://n1uro.ampr.org/linuxconf/amprcable.html > > One site in particular who was hit by this is 44.60.0.1 who after > selecting the hardware solution mentioned in my document should now be > reachable from the ipip mesh. Prior to this he was not. > > Some of you may recall I experienced a similar issue a few years back. > Fortunately I was able to get some information via an old friend of 44/8 > who's one of their chief engineers in the Boston area to find solutions > to this. While the effect appears that they filter ipencap/gre/etc they > do not... it's the watchdog timers that do and it affects inbound > traffic only. > > While there may be many reasons for keeping these on and not allowing > the end user to disable them, one logical one I can think of would be to > allow the CPE to keep stale/old NAT sessions flushed so they're not > hogging up ram resources unnecessarily. After all these aren't high end > cisco or juniper devices. > > -- > I don't have to worry about body fitness in 2017. All I do is > show my body to itself in the mirror and it throws plenty of > fits. > -------- > 73 de Brian - N1URO/AFT1BR > email: (see above) > Web: http://www.n1uro.net/ > Ampr1: http://n1uro.ampr.org/ > Ampr2: http://nos.n1uro.ampr.org > Linux Amateur Radio Services > axMail-Fax & URONode > http://uronode.sourceforge.net > http://axmail.sourceforge.net > AmprNet coordinator for: > Connecticut, Delaware, Maine, > Maryland, Massachusetts, > New Hampshire, New Jersey, Pennsylvania, > Rhode Island, and Vermont. >

Sure...I can do a lunch chat. What time exactly? I'm outside of Boston. Thanks Craig On Thu, May 18, 2017 at 11:52 AM, lleachii--- via 44Net < 44net(a)hamradio.ucsd.edu&gt; wrote:

Guys, I think I may be missing something here. I've seen a couple references to RIP being required. I didn't see that mentioned in any of the on-line docs. Perhaps I've missed it, and if so, I apologize. I'll go look at the Wiki to see if it is there. Is this required or optional? Thanks Craig On Thu, May 18, 2017 at 12:18 PM, Craig Brauckmiller &lt;kc1etb(a)gmail.com&gt; wrote:

I do that for security, but ok. I just re-enabled ICMP. Ping away! :) Thanks Craig On Thu, May 18, 2017 at 10:17 AM, Brian Kantor &lt;Brian(a)ucsd.edu&gt; wrote:

On Thu, 18 May 2017, Brian Kantor wrote: In addition to being an useful troubleshooting tool, ICMP packets are used for Path MTU Discovery (PMTUd), which is pretty good and essential Internet functionality when you have smaller MTUs involved. And, with our IPIP tunnels, we have just that! The encapsulation causes our link MTU to be smaller than the standard ethernet 1500 bytes. https://en.wikipedia.org/wiki/Path_MTU_Discovery "Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection." So, please do not block all of ICMP; ICMP Unreachable messages (type 3) should be permitted, especially on a network like ours. - Hessu

Craig, Pinging (and connecting to port 443 on) 96.86.86.53 work from amprgw. Tcpdump on amprgw shows that IPIP traffic is being sent to you from 169.228.66.251. If you're not seeing it, either your modem or the network are filtering it out. My bet is on the modem. - Brian On Thu, May 18, 2017 at 10:43:19AM -0400, Craig Brauckmiller wrote: