David et al;
On Mon, 2016-06-06 at 14:46 -0700, David Ranch wrote:
Ok... all important points to understand and we
absolutely rely and
appreciate all your help on running the current AMPRGW solution. Before
even jumping to conclusion, we'd need to know if GRE really would be
more successful than IPIP. In Brian, N1URO's situation, I'm curious if
a Comcast "Business" class service would remove some of these
intentional filtering issues.
No. I'm at their L4 support group (engineering) and they've been amazed
I was able to figure out that their Cisco/Linksys CPEs they're deploying
has a crippled firmware as per Comcast's specs. Now that they've been
found out they're trying to make a business decision as to put these
"features" up as a pay service or open them up for normal usage which
would mean a massive upgrade deployment across their network to the end
points.
An example of this is their DMZ which -is- on a watchdog timer. It
should not be and they even admit that their DMZ is crippled in the
units they're deploying - however I also found this appears to be
standard Cisco config. These units are also deployed in some of their
business circuits so to answer your question it's really a moot issue.
Comcast did inform me that they're NOT filtering ip protocol 4 or any
others by nature (except for routing protocols such as BGP/OSPF/etc.)
and the "fix" does appear to put their CPE into bridge mode and run your
own routing device behind it as I've proved with a DD-WRT router.
As for GRE, years ago we decided to remove it from MFNOS mainly because
no one was using it... but then again it'd have been feasible as we were
mainly forwarding our encap frames to a central server located within an
ISP co-owned by a ham. Back in the day, MFNOS was what we mainly used
here in the northeast. Either GRE or IPEncap worked fine in this case.
For the "average to advanced" ham user what we're doing now with policy
routing our encap frames is a LOT more efficient coupled with the RIP
broadcasts and the portal's ability to refresh any IPs via dynamic
hostname resolution however for those on HamWan or a HamNet such a
config using IPEncap or GRE isn't necessarily feasible.
Personally, I find it insane to have to use more than one device to
handle my incoming IP feed when I'm sure with a matter of some tweeks to
the firmware this can all be resolved (Comcast even agrees) for now it's
the best solution if you're having issues with them or another ISP who
you know isn't filtering IPEncap/protocol 4. I also don't see why this
can't be done using a Pi if the device is natting/policy routing/etc
too. Just seems like a lot of work when I don't feel it's necessary.
</$.02>
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
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, Pennsylvania,
Rhode Island, and Vermont.