18 May
2017
18 May
'17
10:15 a.m.
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.
>