[aprssig] AX.25 RR bit test - Holy Grail?
andrewemt at hotmail.com
Fri Nov 30 13:54:14 EST 2012
Just as a reminder, these bits are in AX.25 headers. _not_ in messages sent through APRS-IS, and not available in any clients speaking to command-mode TNC's. Only KISS-mode TNC's would be able to pass such non-standard packets.
Would that cause a problem with any plans you have for this?
Andrew Pavlin, KA2DDO
> From: bruninga at usna.edu
> Date: Fri, 30 Nov 2012 13:30:24 -0500
> To: aprssig at tapr.org
> Subject: [aprssig] AX.25 RR bit test - Holy Grail?
> Byon, Scott, everyone...
> Have I been asleep for 30 years? Or are these RR bits in every AX.25
> packet the available extra bits I have been looking for all these years?
> Who can generate raw AX.25 packets with these bits set to something other
> than "11" so we can see what existing APRS hardware does with them???
> If so, and if all existing TNC's ignore these bits then we have tremendous
> potential for expanding APRS capability without obsolescing anything! ...
> Every APRS packet has at least 4 of these bits we can play with... Every
> digipeated packet has 2 more
> Or is this just another "senior moment"?
> The bits I have always wanted are for setting PRIORITY levels and OPERATOR
> PRESENT for starters... Now the HAS-BEEN-PREEMPTED is another...
> Bob, WB4aPR
> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu]
> Sent: Friday, November 30, 2012 12:36 PM
> To: TAPR APRS Mailing List
> Cc: Robert Bruninga
> Subject: RE: Premptive Digipeating (b) PATH MARKING
> Taking comments to date, I added the sentence about keeping the remainder
> of the path open, and attempted to address Steve Dimse's very valid points
> about traceability. I'm suggesting we can use the RR bits in the SSID
> field. CAN WE DO THIS?
> PREMPTIVE DIGIPEATING DEFINITION (rev b): When ON, the digi will search,
> starting at the first unused field and then to the end for a match to any
> of its potential matching aliases (MYCALL, MYALIAS, UIDIGI). If a match,
> it will mark that and all prior fields as HAS-BEEN-USED, it will REPLACE
> its ALIAS with its MYCALL and will digipeat it once. All remaining fields
> are still active.
> INDICATORS: When the packet is preemptively digipeated, the preempted
> path can either be DROPPED, or MARKED. If dropped, then the packet
> arrives with only the preemptive digipeater's MYCALL and remaing path as
> normally done. All prior path data is lost. Or if MARKED is SET, then
> the entire path is retained but the LSB of the two RR bits is set to 1
> indicating the field was prempted.
> In the GATEWAY scenario, one would probably use the DROP setting. In the
> normal network scenario, then the MARK setting might be the best setting.
> PRIORITY BIT: Now why not use the other RR bit in the SSID field for a
> PRIORITY bit. The existing default value of the RR bit is 1 and will
> indicate a PRIORITY packet but if "0", then this packet is of less
> priority and can be dropped in future networks that recognize it..
> QUESTION: Does playing with the RR bits break any existing processing?
> To see the definition of these bits, see figure 188.8.131.52.1 in:
> So the PREMPT TNC command now has 3 settings: OFF, DROP, MARK to indicate
> how to indicate the action.
> The rest of the below remains as originally
> PACKETS TO HOME SCENARIO: In this scenario your goal is to get your
> packets targeted to a particular digi or area. The path WIDE2-2,HOMEX
> With the HOMEX digipeater recognizing pre-emptive digipeating would make
> sure that all your packets got to HOMEX in from 1 to 3 hops. To get them
> say 4 hops from City A to City B without flooding everywhere, the path
> WIDE1-1,CITYA,WIDE2-1,CITYB would get to CITYB no matter where you are in
> A or B or inbetween, but not involve ANY OTHER DIGI's than the shortest
> path between them. ETC...
> Or CITYD,CITYC,CITYB,CITYA would let you go on a trip to CItyD, but your
> packets would get back home to A no matter where you were inbetween. When
> close, then they would only go 1 hop. Or if you wanted those at CityD to
> anticipate your arrival, you might use the path CITYA,CITYB,CITYC,CITYD
> and then your packets would all preceed you to CITYD until you got there,
> but with fewer and fewer hops as you got close.
> GATEWAY SCENARIO: IN this scenario there is a special event on FREQB with
> lots of FREQB digis that desires to get at least one (and only 1) copy of
> each packet into the 144.39 system via a cross-channel gateway with the
> callsign GATE. The path of FREQB7-7,GATE,WIDE2-1 would make sure that a
> packet got everywhere in the special event network but only one copy
> always gets through the gateway at least one hop into the APRS network.
> (such as the linear appalachan trail event or an underground multihop cave
> NO PREMPTIVE DIGIPEATING ON UIFLOOD and UITRACE. The reason is, that it
> would preclude any use of any kind of WIDEn-N AFTER going through a gate,
> and that is one of the main reasons for doing it.
> Remember, these 4 hop Premptive SPECIFIC paths are MUCH less load on the
> network than a WIDE4-4 which can potentially cause 34 DUPES, compared to
> only a maximum of 4 hops with the explicit preemptive hop approach.
> Have I missed anything?
> Bob, WB4APR
> aprssig mailing list
> aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig