bm and wg7j-nos

["Johan K. Reinalda" <johan@ECE.ORST.EDU>]

Your message dated: Thu, 23 Jan 92 13:42:53 EST
--------
> one priority with me is reliability. You can have all of the features
> in the world but without reliability you just have a headache.
I completely agree. I test code before i send it out, but with the
very limited tcp users here it's not possible to overload :-(
Most of my testing is between 2 copies running in different dv windows.

> If that happens much more than it's back to PA0 code for me. I have
> this thing about crashes. They drive me crazy! I have not had one in so
> long running the PA0 code (at two locations) that it is even more
> frustrating to have them now.
Agreed, if you can get me some more details on what you things was done
(commands executed etc.) i will look into it...

> I hope this does not sound to harsh. I appreci> ate very much your efforts.
> Early G1EMM code had it's share of problems. I know they will be worked
> out.
No problem. I have talked to Gerard, and expect he will take over some
of the most used 'features' i've added, so that we can have one
user-version instead of several diverging ones... :-)

> One other thing - when using another Nos' BBS to ax25 connect to your
> code (bbs) with jumpstart on, I do not get the banner unless I hit
> that extra CR. When I do I get the banner and two ID lines. I know there
> are limitations with the code understanding the connection as explained
> in the readme - is this normal?
If that system is advertizing itself as a netrom switch, that is normal.
This is what happens:
none-netrom systems connecting get the prompt immediately, and first line
gets taken as a command. Notice the 'lack' of the line that normally ate
the first line (ie. the CR) in ax25mail.c right before the mailbox
process gets spawned...

Netrom neigbours connecting do not get the jumpstart. When the first
I frame comes in (the CR), this triggers the mailbox.
The prompt gets sent, and because of the lack of the 'first-line-eater'
this line gets interpreted as a command, and results in another prompt.

It is possible to eat this line in the case of netrom connects by looking
as the incoming socket and determining if this is a netrom-neighbour
call or not, but current code doesn't do it...

Johan