3113Re: BPQ32 Keepalives
- Apr 28, 2010Good deal, I have a site where using a dataengine would be more practical. Just need to find one (and preferably a spare), but like most of the "old but good" Kantronic's stuff....darn hard to find anymore.
John is the DE BPQ code pretty much in sync feature/bug fix wise with the BPQ32 codebase now? I assume that due to the limited hardware resources in a DE that there is stuff in BPQ32 that will not "fit" into the DE code. Good solid basic switch functionality that "just runs and runs" is what I would need at this site...less I have to touch it...the better ;-)
Is IDLETIME hard coded to 900 in BPQ32 now? Seems like I tried working with that a bit and nothing changed.
John I'm thinking Brian (N1URO) never finished the netrom portion of UROnode. I think his priorities were the FlexNet portion of it since FlexNet is very dominant in the northeast USA networks. KD1ZD is kind of unofficially maintaining it now. So far I think he's just been focusing on getting it going on the more modern kernels. May have to have you two hook up and debug what is going on between UROnode and BPQ32. Sooner or later we'll probably have others wanting to mix those two together ;-)
I'm going to try and go back to the new version of BPQ32 today. We've got node broadcasts turned off and I think a locked route on both ends might be the best workaround for now.
--- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
> I don't have a Data Engine, but I've tested with a DOS BPQ Node (which
> uses the same source code as the DE version), and the BPQ32 keepalive
> system doesn't cause any problem SO LONG AS the IDLETIME param on the
> DOS Node is at least as great as that of the BPQ32 node.
> This issue with IDLETIME would apply to other systems, so if you are
> having problems with links closing regularly, check the IDLETIME
> settings at each end.
> Jeff's problem with UROnode seems to be different - for some reason it
> is treating a connection from a node as if it is from a user. I don't
> know enough about linuxnode and it's derivatives to know if this is a
> configuration problem or a design feature.
> John G8BPQ
> -----Original Message-----
> From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
> James Wagner
> Sent: 27 April 2010 23:52
> To: BPQ32@yahoogroups.com
> 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@...>
> 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
> 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 <mailto:BPQ32%40yahoogroups.com> , "John
> Wiseman" <john.wiseman@ ...> wrote:
> > Ok, I'll see if I can add a way to turn off the keepalive function.
> > users are successfully linking bpq32 to xrouter xnet and snos nodes,
> > I don't think there is anything fundamentally wrong with my process
> > holding links open to verify node-node connectivity.
> > John G8BPQ
> > -----Original Message-----
> > From: BPQ32@yahoogroups. com <mailto:BPQ32%40yahoogroups.com>
> [mailto:BPQ32@yahoogroups. com <mailto:BPQ32%40yahoogroups.com> ] On
> Behalf Of
> > Jeff - WA4ZKO
> > Sent: 27 April 2010 21:08
> > To: BPQ32@yahoogroups. com <mailto:BPQ32%40yahoogroups.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
> > 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
> > 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
- << Previous post in topic Next post in topic >>