> > I'm just wondering why the test isn't (*iframe& 0xf) == 0 which would
> > handle the full number of possible 16 possible TNCs.
>
> That smells like it's a correct solution to me, given what the spec
> says. I will compile it with that test and let you know if I see any
> issues.
The code does this:
read a kiss frame from tty and pass it to the from_kiss()-multiplexer in
process.c.
Primordially, it only transfered data starting with iframe[0] = 0. Everyting
else, like kiss commands, was discarded.
Then, due to process.c, VE3DJF and VE3PNX had the idea to support
two-port-TNCs. They implemented two-port TNCs the hard way. Not three-port, not
16-port. Two port only:
#define FROM_PORT2(p) (((*(p+1))&0x10)!=0)
#define FOR_PORT2(p) (addrmatch(p,mycallsign2) || addrmatch(p,myalias2))
/* ve3djf and ve3pnx addition above
It's really hard because they decided not to code a mycallsign-list[16] but
mycallsign2, myalias2, etc..
They enhanced if (*iframe == '\0') in assemble_kiss() to if (*iframe == '\0' ||
*iframe == 0x10) in order to support their new feature. The commentary the line
above shows the old intended behavior, /* Make sure that the control byte is
zero */.
If you patch it to accept kiss-port-3-to-15-packts, then the frames would be
received. But the code for sendig it is not implementet, because there's no
FROM_PORT3/mycallsign3,myalias3, FROM_PORT4/mycallsign4,..
You'd have to also implement this (and you'd should do it better).
Also, the brutal check
if (dual_port == 1 && FOR_PORT2(a)) {
port = 0x10;
in from_ip() has to be done much more better.
Where comes dual_port > 0 come from?
config.c:
dual_port = 1;
if (mycallsign2[0] == '\0') {
dual_port = 0;
}
eh? -- Yes. The ancient patch-submitter sets dual_port to 1 and looks if
mycallsign2 is not et and then sets dual_port = 0.
This _is_ ugly.
Please make it better and send patches.
73,
- Thomas dl9sau
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
