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

3108Re: My my what a mess

Expand Messages
  • Jeff - WA4ZKO
    Apr 27, 2010
    • 0 Attachment
      Does it hear your BPQ32 node good?

      If so watch between node broadcasts from it when things are idle between you and it. Does the obs counter for LEHIGH on your BPQ32 node stay where it should? Just do a N LEHIGH every minute or two for a bit. Or do you see odd drops (more than 1 down) on the obs counter after a bit...maybe even it disappearing from your BPQ32's nodes list for a minute or two till another broadcast comes in from LEHIGH?

      Like I said previously, if you're not doing locked routes and depending on the broadcasts to keep things correct...you may have the problem and not know it. Occasionally you would be missing a node in the list that should of been there, then minutes later it's back and all seems fine.

      I've also seen it get possessed at times and the obs counter will show a triple digit value like 200 or so (wow). That's rare and I haven't seen it with the latest version of BPQ32.

      73
      Jeff
      WA4ZKO

      --- In BPQ32@yahoogroups.com, "Jerry - N9LYA" <n9lya@...> wrote:
      >
      > Jeff. My Lehigh node is a TheNET Node V 2.08B if you can get to me have a
      > look around and see if you see anything that helps or ????
      >
      > 73 jerry
      >
      > _____
      >
      > From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of Jeff
      > - WA4ZKO
      > Sent: Tuesday, April 27, 2010 6:16 PM
      > To: BPQ32@yahoogroups.com
      > 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?
      >
      > 73
      > Jeff
      > WA4ZKO
      >
      > --- In BPQ32@yahoogroups. <mailto:BPQ32%40yahoogroups.com> 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. <mailto:BPQ32%40yahoogroups.com> com
      > [mailto:BPQ32@yahoogroups. <mailto:BPQ32%40yahoogroups.com> com] On Behalf
      > Of
      > > Jeff - WA4ZKO
      > > Sent: 27 April 2010 21:08
      > > To: BPQ32@yahoogroups. <mailto:BPQ32%40yahoogroups.com> 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