| |
ZL3AI > APRDIG 09.04.04 16:27l 272 Lines 10089 Bytes #999 (0) @ WW
BID : 3119-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 06, 1/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<IK1ZNW<IK6PYS<N2BQF<VK3TE<ZL2BAU<
ZL2BAU<ZL3VML
Sent: 040409/1401Z @:ZL3VML.#80.NZL.OC #:22137 [Chch-NZ] FBB7.00i $:3119-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Tuesday, April 06, 2004.
1. AX.25 Address field question?
2. Re: [ui-view] KPC-3 v8.2 digi setup questions
3. Re: 441.125 APRS Freq?
4. RE: AX.25 Address field question?
5. RE: AX.25 Address field question?
6. Re: Mic-E Packet Help Needed
7. RE: AX.25 Address field question?
8. Re: Mic-E Packet Help Needed
9. RE: AX.25 Address field question?
10. RE: AX.25 Address field question?
11. Re: Mic-E Packet Help Needed
12. RE: AX.25 Address field question?
13. Re: Mic-E Packet Help Needed
14. RE: AX.25 Address field question?
15. Why archive only SPAM on the TAPR lists???
16. Re: Mic-E Packet Help Needed
17. Re: Why archive only SPAM on the TAPR lists???
18. OpenTracker kits are now shipping
19. Re: Why archive only SPAM on the TAPR lists???
20. Re: Mic-E Packet Help Needed
21. Re: Mic-E Packet Help Needed
22. Re: Mic-E Packet Help Needed
23. Re: Mic-E Packet Help Needed
24. Re: Mic-E Packet Help Needed
25. FW: Mic-E Packet Help Needed
26. 2004 TAPR Digital BASH at Hamvention
27. Re: AX.25 Address field question?
----------------------------------------------------------------------
Subject: AX.25 Address field question?
From: "Michael J. Pawlowsky" <mikejp@videotron.ca>
Date: Tue, 6 Apr 2004 6:55:18
X-Message-Number: 1
I'm a bit confused about the address fields for AX.25 and was hoping
someone could help me out a bit.
In the specs I read:
3.12. Address-Field Encoding
The address field of all frames consists of a destination, source and
(optionally) two Layer 2 repeater subfields. Each subfield consists of an
amateur callsign and a Secondary Station Identifier (SSID). The callsign is
made up of upper-case alpha and numeric ASCII characters only. The SSID is
a four-bit integer that uniquely identifies multiple stations using the
same amateur callsign.
The HDLC address field is extended beyond one octet by assigning the
least-significant bit of each octet to be an `extension bit.' The extension
bit of each octet is set to `0' to indicate the next octet contains more
address information, or to `1', to indicate that this is the last octet of
the HDLC address field. To make room for this extension bit, the amateur
radio call- sign information is shifted one bit left.
-------------
When I look at a packet coming from a Tiny Trak (via AGWPE) I get:
(AGWPE changes byte one from a flag to it's port number. The rest should be
the same)
--------------
0000: 00 82 A0 A8 66 62 60 60 82 92 A4 62 40 40 60 A4 : ....fb``...b@@`.
0010: 8A 98 82 B2 40 60 AE 92 88 8A 40 40 60 AE 92 88 : ....@`....@@`...
0020: 8A 40 40 61 03 F0 2F 30 33 35 36 33 31 68 34 35 : .@@a../035631h45
0030: 32 35 2E 37 30 4E 2F 30 37 33 35 31 2E 34 36 57 : 25.70N/07351.46W
0040: 5E 33 36 30 2F 30 30 30 2F 41 3D 30 30 30 31 32 : ^360/000/A=00012
0050: 34 : 4
--------------
If we decode the first part we get:
82 A0 A8 66 62 60 60 = dest addr = APT3100
82 92 A4 62 40 40 60 = source addr = AIR1__0
A4 8A 98 82 B2 40 60 = RELAY_0
AE 92 88 8A 40 40 60 = WIDE__0
AE 92 88 8a 40 40 61 = WIDE__0
------
My question is there seems to be 3 repeaters when the specs say there
should not be more than 2. How come there are 3 here and is there a limit?
----------------------------------------------------------------------
Subject: Re: [ui-view] KPC-3 v8.2 digi setup questions
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 06 Apr 2004 08:55:34 -0400
X-Message-Number: 2
>>>James Smith <k9apr@tawg.org> 4/5/04 7:48:44 PM >>>
>
>We currently have just about every digi in Indiana set this way,
Great work, but... Shoot me now, or shoot me later...
Under the new n-N paradigm, I recommended, and you set:
UIFLOOD WIDE,28,NOID
UITRACE SS,28
This is a good starting point, as it introduced the SSn-N
concept with no impact to current operations and allowed
users to learn the use of SSn-N with no change to WIDEn-N
support. But it doesnt really help encourage a change in
how users use WIDEn-N nor "manage" the improper use of
WIDEn-N.
After that recommendation, I think the new n-N paradigm
evolved to a later recommendation to reverse the two as:
UIFLOOD SS,28,NOID
UITRACE WIDE,28
This works identically to end users, but it puts the full
trace on WIDEn-N to 1) provide full traceability on all paths,
2) discourage the use of LONG paths where not needed,
3) to help identify good or bad usage, and 4) to help
identify possible locations for WIDEn-N Firewalls if needed..
Also, then, since the SSn-N is SELF-LIMITING to only
the range of the SS digis, the value of N is less important
and less damaging and so the recommended user path
is WIDE,SSn-N. This still allows the path to indicate the
starting point for the packet.
Thus, both WIDEn-N and WIDE,SSn-N users and paths
are traceable to their source, and SYSOPS can see full
traces on all abusively long WIDEn-N packets. In this
area, then the receommended user settings would be:
WIDEn-N for travelers in and out of area
WIDE,SSn-N (or RELAY,SSn-N) for all local use
Anyway, something to think about. The change
has little impact on users except that in the SSn-N
case you would be asking them to use WIDE,SSn-N.
and there is no longer a need for WIDE,WIDEn-N
since WIDEn-N now becomes traceable independent
of the user setting...
Just some ideas...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: 441.125 APRS Freq?
From: Keith Allen <kallen2@bellsouth.net>
Date: Mon, 22 Mar 2004 12:08:04 -0600
X-Message-Number: 3
Robert Bruninga wrote:
>Actually, the one I have promoted is 445.925 the lowest
>of the simplex voice channels. It is for "APRS and APRS
>voice coordination"... Thus it is in the voice part of the
>band. Using PL like we use for VOICE ALERT, APRS
>and voice are compatible for local use.
I'm doing 2M right now. Is there anyone out there in alabama playing
with UHF APRS??
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: "Scott Miller" <scott@3xf.com>
Date: Tue, 6 Apr 2004 08:15:10 -0700
X-Message-Number: 4
Depends on what version of the spec you're reading. Version 2.0 says:
2.2.13.3 Multiple Repeater Operation
The link-layer AX.25 protocol allows operation through more than one
repeater, creating a primitive frame routing mechanism. Up to eight
repeaters may be used by extending the repeater-address subfield.
I really don't know the history behind version 2.2. I'm guessing that the
limit was imposed because in regular connected-mode packet radio you're not
supposed to need that many hops anymore. The 2.2 spec was written in '97,
so maybe they just weren't aware of how APRS was using the repeater fields.
Anyway, I've never seen an implementation that strictly followed 2.2.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 06 Apr 2004 11:36:30 -0400
X-Message-Number: 5
TAPR, etc.
We must get this AX.25 version 2.2 changed. If future MFR's
start building to 2.2, and prohibit DIGI's beyond 2, then we
will lose an essential feature of UI digipeating. Yes, 2 hops
is sufficient for connected packet, but AX.25 is NOT JUST
for connected packet. We MUST get this changed. Who
can spearhead the writing campaign (after first confirming
the facts...)
de Wb4APR, Bob
----------------------------------------------------------------------
Subject: Re: Mic-E Packet Help Needed
From: "Eric Christensen" <christensene@mail.ecu.edu>
Date: Tue, 6 Apr 2004 12:2:36
X-Message-Number: 6
So, what was ever figured out with this? Roger (UI-View Author) says that
if the TNC is in KISS mode (which it is) then it doesn't matter what the
Filter settings are because the TNC doesn't do any filtering to the
packets... they are just passed through to the Computer.
One of the stations was altering the Mic-E packets and sending them on to
the IS and the IS servers weren't seeing them as dups and was allowing both
to pass. Any ideas?
Eric KF4OTN
On 03/31/04, ""Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>" wrote:
>2004-Mar-31 09:54:25 (UTC) KB4TOH-13>S5QT6V,K4ROK-10*,WIDE,KE4TZN,I:'i?6l
>k/]"4"}
>
>2004-Mar-31 09:54:26 (UTC)
>KB4TOH-13>S5QT6V,K4ROK-10,KD4PBS-3*,qAR,N8VNR-1:'i?6l k/]"4"}
>
>I noticed a problem on the network last night. When one station (actually
>it was occurring with other station's Mic-E packets as well) was sending a
>Mic-E packet out it was hitting two I-Gates (as sometimes happens). This is
>when I started noticing that the dup suppression on the IS wasn't filtering
>one of them out. On a closer look, I noticed that the packet received and
>processed at N8VNR-1 has an extra space in the Mic-E portion of the packet
>compared to one heard by KE4TZN. I looked to see if this was happening to
>"regular" packets but I did not see this occurring.
>
>I queried both stations to get software/hardware information:
>
>KE4TZN: KPC-3 and UI-View32 V1.99. Verified that the TNC had 8bitconv ON
>and that his modem was in KISS mode.
>
>N8VNR-1: APRSd v2.2.5. No other information was confirmed at this station
>at this time.
>
>So, my question is:
>
>1) Which packet is correct?
>2) If it is an added space (which I suspect) what does this do to the packet
>on decode? If it is a deletion of a character, why is it occurring and,
>well, I can guess what that does to the data.
>3) Is this a known issue?
>
>An obvious problem would be the fact that more than one packet is making it
>through the IS Servers and are not being duped out, which adds to the IS
>load and to the load of the databases that are gathering the data.
>
>DISCLAIMER: Callsigns left in for later support. I am not blaming a
>specific user but rather trying to narrow down a problem so that if it is a
>software issue it can be fixed.
>
>Thanks,
>Eric KF4OTN
----------------------------------------------------------------------
Read previous mail | Read next mail
| |