Loading ...
Sorry, an error occurred while loading the content.

3105Re: [BPQ32] Re: My my what a mess

Expand Messages
  • James Wagner
    Apr 27, 2010
      Ooops, typo - obviously meant BPQ ....

      Jim, KA7EHK

      From: James Wagner <ka7ehk@...>
      To: BPQ32@yahoogroups.com
      Sent: Tue, April 27, 2010 3:51:59 PM
      Subject: Re: [BPQ32] Re: My my what a mess


      Greetings -

      Does anyone have a DataEngine running PBQ node software to verify whether or not there are any keep-alive with that?

      Jim Wagner
      Tangent, OR, USA
      G8BPQ-DE node LYONS

      From: Jeff - WA4ZKO <wa4zko@yahoo. com>
      To: BPQ32@yahoogroups. com
      Sent: Tue, April 27, 2010 3:16:11 PM
      Subject: [BPQ32] Re: My my what a mess


      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:
      > 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-----
      > From: BPQ32@yahoogroups. com [mailto:BPQ32@yahoogroups. com] On Behalf Of
      > Jeff - WA4ZKO
      > Sent: 27 April 2010 21:08
      > To: BPQ32@yahoogroups. com
      > 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
      > systems.
      > 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.
      > 73
      > Jeff
      > WA4ZKO

    • Show all 18 messages in this topic