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

Re: Nodes/Routes not dropping out after link failure

Expand Messages
  • Jeff - WA4ZKO
    This involved a PK-96 TNC that will not be the permenant solution. There are several XKISS options you can set with it. Mine has the v7.0 firmware (latest = ?)
    Message 1 of 6 , Feb 3, 2011
    • 0 Attachment
      This involved a PK-96 TNC that will not be the permenant solution. There are several XKISS options you can set with it. Mine has the v7.0 firmware (latest = ?) and FYI it's standard KISS seems fine, but XKISS looks buggy.

      I have a Paccomm Spirit-2 I'm refurbishing for this port, it's at least a notch or two better for backbone use. Plus I can use a patched BPQKISS EPROM to get what I want (XKISS w/ chksum & ackmode). I've had really good results with this approach and MFJ-1270C's.


      73
      Jeff
      WA4ZKO
      "Packet Radio never died, it just evolved."
      Packet: WA4ZKO@WA4ZKO.#NKY.KY.USA.NOAM
      http://twitter.com/wa4zko

      --- In BPQ32@yahoogroups.com, "la7um" <la7um@...> wrote:
      >
      > If using XKISS mode, as implemented in KPC4 from v 5.1 I seems to remember that the BPQ KISSMODE Ack, and Polled, Checksum also had to be used.
      >
      > Don't know if this XKISS special Kantronics Kiss mode is implemented in PK TNCs and will work well with those tncs using the special BPQ Kiss mode.
      >
      > On air, this polling system resembles the DAMA way of working.
      >
      > Latest KAM+ and later TNCs have DAMA slave I believe in Terminal and Host mode, but in KISS mode for NetRom use, something more has to be built into the Node SW.
      >
      > But I think that RMS Express, Airmail and other Client SW included RMS PACKET and the other BBS SW systems do need to implement the necessary counterpart.
      > 15-20 years ago my impression was that in US there was little or no understanding of Dama...just like in Norway with spread population, while it was quickly implemented in the crowdy german and other Eu rural areas.
      >
      > Germany was way ahead of all of us.
      >
      > It may really be worth some thinking.....is it practical.....when building new packet networks for Emcomm use?
      > Can it technically be used in KISS mode (with the inherent asyncronuous way of interaction with the on air network?
      >
      > 73 de la7um Finn
      >
      > --- In BPQ32@yahoogroups.com, "Jeff - WA4ZKO" <wa4zko@> wrote:
      > >
      > > After noticing backbone packets showing in monitor but not being heard on the airwaves, I dug in deeper. Should of caught this sooner, but oh well.
      > >
      > > Would seem the XKISS implementation in the AEA PK-96 TNC is hinky. Switching to standard KISS on the TNC and in bpq32.cfg seems to have cleared some things up.
      > >
      > > I'm still baffled at how things worked here:
      > > "After both nodes were restarted (the axip link is still down at this point) and exchanged node broadcasts, they seemed to talk fine over the RF backbone."
      > >
      > > Maybe it's a hit and miss w/ PK-96's XKISS ;-)
      > >
      > > I haven't had time to test if the nodes will "fail-over" to RF properly during AXIP link failure, but will report back on that when I have tested that.
      > >
      > > Still seeing some cases of a BPQ32 node not removing failed nodes and endlessly retrying them.
      > >
      > >
      > > 73
      > > Jeff
      > > WA4ZKO
      > >
      > >
      > > --- In BPQ32@yahoogroups.com, "wa4zko" <wa4zko@> wrote:
      > > >
      > > > I recently installed a 9.6k backbone to backup a somewhat shaky internet connection between two BPQ32 based sites. The 9.6k ports have a route quality a few notches below the AXIP links. My assumption was that BPQ32's internal router should detect the AXIP link is down (may take a minute or two, but that's fine) and automatically "fail-over" to the 9.6k RF path.
      > > >
      > > > Last night, for giggles, I pulled the network cable to simulate a failure of the AXIP port. From there I watched and waited. The nodes (as expected) tried to talk over AXIP for a bit. One eventually dropped the AXIP route, the other just seemed heck bent on using the AXIP port. This went on for a good 20 minutes. Even after fresh node broadcasts were exchanged on both ends....the one node continued non-stop trying to contact the other node over the AXIP port. They refused to talk over the backbone RF port, insisting on using the axip port. During this there was no way I could connect via the 9.6k RF port to the other node.
      > > >
      > > > The one node required a total restart to get it to stop trying to use the AXIP port.
      > > >
      > > > After both nodes were restarted (the axip link is still down at this point) and exchanged node broadcasts, they seemed to talk fine over the RF backbone.
      > > >
      > > > We have a couple other BPQ32 nodes nearby in testing and fairly often we'll see one fail/refuse to remove a "down" node and spend hours trying to reach it. Restarting the node seems to be the only way to stop it.
      > > >
      > > > Thoughts? Ideas? Bug in the BPQ32 router?
      > > >
      > > >
      > > > 73
      > > > Jeff
      > > > WA4ZKO
      > > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.