First off I think the idea in principle is a good one
other than adding chatter on RF and some folks (right or wrong) are not too
crazy about that.
I've heard that this causes some odd issues on TheNet networks, but haven't had
a chance to verify it myself. Maybe just the older versions of TheNet too? May
have to spin up a TheNet node in earshot of a BPQ32 node and see what happens.
The the problem I've hit is I'm trying to do an AXIP (AXUPD to be exact) link
across the internet to a system running UROnode and JNOS. We can link and share
node lists okay so far, admittedly we've only started testing it so we may hit
other issues on down the road.
All is fine till my BPQ32 node hears a nodes broadcast from the URONode. The
BPQ32 node takes that broadcast and adds the UROnode nodes fine. Now the fun
begins. Once BPQ32 hears the node broadcast it wants to open a node<>node
link and hold it open for the keepalive functionality. Problem is UROnode takes
this incoming "keepalive" connection and thinks it's a user connect
and logs the BPQ32 node in as if it's a user. Things set there idle to a
timeout (probably on UROnode's end) drops the connection. This process repeats
every 15 minutes or so. Also looks like the keepalive function is hardcoded to
900 (15 minutes) now?
Since the test node is just basically serving as an AXIP hub and I don't have
to run the other modules on it (example BPQBBS) I tried another tactic to get
around this. Looking through the change log I could see that the
"keepalive" function was added into the Oct 2009 release of BPQ32. I
had a copy of the Sept 2009 version of BPQ32 on hand, so I installed it. Bingo,
all looked fine at first. BPQ32 to UROnode links, node broadcasts, and
connections worked fine.
But, one little gotcha started to be noticed....
Watching things closely I could see that since the older version of BPQ32 isn't
responding to the "keepalive" coming from downstream BPQ32 nodes. On
those nodes I could watch the obs counter start dropping over a period of a few
minutes as the keepalive's fail. If the timing is right and the downstream node
does not get a fresh node broadcast in time....the upstream node falls out of
the node list. This stays this way until a new/fresh node broadcast comes in
from the upstream node and "heals" things for awhile. Dependings on
what timings are used, this may heal itself quickly or it could be a few minutes.
Very possible that some folks make have the issue and not even know it if they
don't watch things closely. If you intermittently notice your adjacent nodes
being gone one minute, back the next...you may be seeing this in action.
Maybe going to locked routes and aggressive node broadcast timings would
prevent this, but that comes with it's own share of potential gotchas when
linking to other systems.
End of the world? No since it sort of heals itself repeatedly. Then again it
creates unexpected behavior if you try to let the autorouter do it's thing.
Probably a heck of a lot easier said than done, but a selective approach to
enabling/disabling it would be nice. Maybe a way of detecting if the neighbor
node is BPQ32 or not?
Problem we face now if we gut the keepalive functionality out...everyone needs
to upgrade or else those on the previous versions will likely hit the same
problem at times?
--- In BPQ32@yahoogroups. com, "John
Wiseman" <john.wiseman@ ...> wrote:
>ymailto="mailto:BPQ32%40yahoogroups.com">BPQ32@yahoogroups. com [mailto:BPQ32@yahoogroups. com] On Behalf
> Ok, I'll see if I can add a way to turn off the keepalive function. But
> users are successfully linking bpq32 to xrouter xnet and snos nodes, so
> I don't think there is anything fundamentally wrong with my process for
> holding links open to verify node-node connectivity.
> John G8BPQ
> -----Original Message-----
> Jeff - WA4ZKOymailto="mailto:BPQ32%40yahoogroups.com">BPQ32@yahoogroups. com
> Sent: 27 April 2010 21:08
> Subject: [BPQ32] My my what a mess
> Amazing how much of a headache the simple addition of the non-standard
> netrom neighbor node polling can create when you link to non-BPQ netrom
> I took the test node back to the Sept 2009 version, the one before the
> polling/keepalive feature was added. Solves the compatibility of talking
> to a UROnode system, but creates fallout on nodes down stream running
> the newer version.
> Sure would be nice to be able to turn that polling off, at least
> selectively per port/link.
> As long as you're doing BPQ to BPQ netrom links and running current
> versions...all is fine. Go to a mixed environment and you're probably
> looking at a mess.
> Just about ready to toss in the towel and give it up.