Hi Richard.
> Hi all, as I will be working in Germany for the next year, no
> that doesn't mean you wont hear from me !,
Chuckle...
> I've come across a problem common to linux node, jnos, tnos and
> fbb and probally a few more as well. All of the above check for
> valid callsigns , ie 6 characters and a number in it somewhere.
> now how about the following
> dc/g8jvm
> a perfectly valid callsign but the "/" is not accepted or any
> other delimiter.
You are presumably aware of the CEPT rule that states that CEPT
facilities can only be used for stays not exceeding six months ???
> I know that Tomi is aware of this problem, but is f6fbb ???
This is actually a limitation of the AX.25 specification, which only
allows for a maximum of "six alphanumeric characters" in the callsign
section thereof. When GB500KC was on air to celebrate the 500th
anniversary of the founding of King's College, it was impossible to
set up a packet radio station using that callsign for precicely this
reason.
Also note that the following is a perfectly valid callsign which also
doesn't fit in the AX.25 spcification:
PA/GM7GOD/MM
That is the callsign that *I* would have to use if operating from a
ship sailing in tidal waters claimed by the Netherlands. There was
also the following not that long ago...
GB50CAN/AM
...authorised aboard an RAF Canberra to celebrate the 50th anniversary
of the said plane.
> I can see absolute chaos being caused if I can only log on to a
> fbb bbs with my own call, as white pages reads the r lines.
Providing you are only using the one BBS, there shouldn't be any
chaos caused at all - the WP system is designed to track your
CURRENT location, and that's what it will do.
About four years ago, I was operating from a base on the west coast of
England (as G7GOD of course), and the only BBS that I could connect to
was in the Republic of Ireland, with an EI callsign. That caused no
problems whatsoever.
> This affect ip as well as when an arp request is sent it will
> receive an invalid call , but as linux node, tnos & jnos wont
> accept the ax25 mycall over 6 chars , I guess it wont get any
> further. I know tnos gets a lot of slagging but its the only
> thing so far that allows a user with a cept style call to log in
> to a bbs.
Are you sure of that?
> So it looks like the only way around this is to apply to the
> German PTT for a true reciprocal licence , and you know how
> pedantic the Germans can be !.
My understanding is that the convention used to deal with this problem
in the CEPT case is to just use your home callsign without any of the
prefixes or suffixes.
> Or is it a case of so what we'll just wait til some country uses
> 7 char callsigns, well that may not be too far off.
Examples have been in use for many years - any UK special event
callsign with more than one digit in it is likely to qualify. In fact,
I believe there's been a case of GB100xxxx being issued, which is 9
characters as it stands.
To be honest, the AX.25 specification needs SERIOUS revision in this
area, to allow for callsigns of any length or pattern to be used.
However, it needs to be done in a manner compatible with the current
standard.
My suggestion would be to make it dynamic to suit the callsigns, but
allow individual callsigns in the address field to be padded with
spaces. Here's my thoughts on the matter:
1. The actual callsign bytes in the address have the character
in the top seven bits of the byte. The following ASCII codes may
be considered for valid characters in that field:
' ', '/', '0' to '9', 'A' to 'Z', 'a' to 'z'.
These correspond to the following bit patterns:
' ' 0100-0000
'/' 0101-1110
'0'-'7' 0110-xxx0
'8'-'9' 0111-00x0
'A'-'G' 1000-xxx0
'H'-'O' 1001-xxx0
'P'-'W' 1010-xxx0
'X'-'Z' 1011-0xx0
'a'-'g' 1100-xxx0
'h'-'o' 1101-xxx0
'p'-'w' 1110-xxx0
'x'-'z' 1111-0xx0
2. Each callsign field is followed by an SSID byte, formatted as
rrrssssf where the subfields are defined as follows:
rrr Reserved for future use.
ssss SSID for this callsign.
f Final byte of address flag.
I have a sneaking suspicion that some of the bits in the rrr
field have been given meaning, but have no details to hand.
3. All of the possibly valid character codes have the feature
that at least one of the two MSB bits is set. Therefore, one
way to allow dynamic callsign fields would be to precede each
callsign field with a length byte. If this is done, it could
be defined as 00xx-xxx0 and still remain compatible with the
current AX.25 specification, since this inserts a code not in
the above table, ie., one beginning with 00. This also avoids
any possible problems from the format of the SSID field.
This allows for callsigns up to 32 characters in length (if a
length of 00000 is taken as meaning 32 rather than 0), and
such should suffice for at least a few months 8-)
4. The current specification requires the use of UPPER case letters
in the callsign field. Another way to allow dynamic callsign
fields would be to require that LOWER case letters be used in
the callsign field with the new specification. This results in
all of the valid character codes for the new specification being
ones where bit 6 is set. The SSID field would then be defined to
have bit 6 clear, thus producing an unambiguous flag to separate
the two fields.
If this option is taken, then the format in use is determined by
whether the first letter in the first callsign is in lower or
upper case, so it would place a restriction that all callsigns
must contain at least one letter. However, I am not aware of any
valid callsigns that break this rule.
5. In both cases, it would be possible to revise the SSID field if
the new specification were to be used, should such be deemed to
be advisable.
Comments?
> An help with this one would be very appreciated , especially
> from anyone in the Munich area who could help with a reciprocal
> call.
Scotland is a little too far from the Munich area for me to be able to
help, I'm afraid. Sorry.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
