Sounds similar to the problem on the 450 with bridging where an SM is
registered, but you can't get to it directly nor via LUID proxy. Just
had one do this yesterday. I finally figured out a few months ago that
the session gets into a state where it looks like ARP is being
discarded. Not sure if it's the uplink, downlink or both. But the
solution is to drop the session. This would happen daily randomly across
various APs with prior releases before we got MIMO-A, so it's some kind
of link stability issue. I've seen this only a handful of times on FSK,
but it does happen.
IIRC, the way PPPoE on the SM itself works (not in the customer's
equipment), the AP sits in the middle of the PPPoE session like a relay
so that things like DiffServ still function over the RF link. And this
involves the RF private network, which also doesn't work when the
session gets screwy because ARP for that doesn't work either.
Maybe I'm wrong and Matt's problem is another issue, but it sounds
similar enough that I'd bet $ on it.
On 8/16/2015 2:54 AM, Chitrang Srivastava wrote:
Hi Matt,
Please send engineering.cgi / cnut capture of both AP/SM(which has problems).
Thanks,
Chitrang Srivastava
Cambium Networks
________________________________________
From: Af <[email protected]> on behalf of Matt <[email protected]>
Sent: 15 August 2015 23:42:37
To: [email protected]
Subject: [AFMUG] Canopy 13.4 FSK Session Bug
Have seen this occasionally Canopy 900 FSK modems with poor signal
over years. Now seeing it on 2.4 Canopy FSK modems with 13.4. The
modem will show in sessions on AP. You can even run a link test on
the SM from AP. You cannot get to the SM's management IP. Customer
does not have service. Power cycle SM and same thing. Found you must
power cycle the AP and then power cycle the SM to restore service to
the customer. Not sure if it matters but we have PPPoE and NAT
enabled in most our SM's.
Anyone else seen this?
