home *** CD-ROM | disk | FTP | other *** search
- P1111.BUGS
-
- Oh heck, there are always bugs. I can run my own programs for years and
- never see a bug, but give it to someone else and XAPPO! Many of these
- have been fixed, some are not really bugs, others are not caused by program.
-
-
- 1. There is a bug where the TNC reconnects to the other station after the
- other station disconnects. This can happen when there is data left in the
- TNC buffer after the disconnect, and it seems the TNC reconnects so that it
- can complete the transmission. KA2BQE says this is a bug in the AX25L2V2
- protocal and that the NETROM writers saw this and invented their own
- protocol. Never been able to duplicate the reconnect when AX25L2V2 was
- turned off, so he may be correct.
-
- 2. FULL-DUPLEX TNC operation. This is when your TNC starts transmitting,
- and you know by listening to the packets that it should be receiving. On
- the Kantronics KAM, I found this happened when MAXUSERS or (USERS?) was
- set to 0/1. Didn't care if FULLDUP parameter was on or off.
-
- 3. Header time changes EST to UTC. Re-assemble to change. Argh!
-
- 4. The garbage on the screen when a station disconnects. OK, the
- disconnect sequence has been the real tuffy on this BBS thing. I am still
- studying all the numerous ways a disconnect can screw up, and the junk is
- the only way I can watch what happens. Most of it will be eliminated at
- some future revision.
-
- 5. When used as a terminal on packet, in the monitor mode (F5 toggled on)
- I keep thinking that it misses the first line of a message on occasions.
- Must have looked for this bug 20 times, and keep drawing a blank. Me thinks
- that this bug doesn't exist.
-
- 6. New message overwrites older message. Happens when you delete a message
- from the top of the DIR. The BBS looks at the first 4 bytes of DIR and
- uses that number as the last message number used, adds 1 to it and writes
- the next message under this new number. Can't see an easy way around this,
- the answer for now is to not delete the top entry in DIR.
-
- 7. Kantronics PBBS forward. Not a bug because this works, both on older
- and newer Kantronics PBBS's. This BBS sends SP WA3MNT < N3ET @ BBS
- and this format works, but is not the 'standard' for forwarding (assuming
- there is a 'standard').
-
- 8. PRMBS (a la KA2BQE). Forwarding works, but you never know what BQE is
- gonna do on his next PRMBS revision. Forwarding may look strange at times
- when TO or FROM a PRMBS, but I've never seen a forward fail.
-
- 9. *** ERRORS. This BBS will tend to disconnect when it sees an ERROR
- message. Well, better this then carry on for hours sending WHAT, HUH, or
- INVALID COMMAND. Also, there may be a case where this BBS sends a
- *** ERROR message, then sends a prompt '>'. Still watching for this.
- The prompt may cause the other end to think a message was properly forwarded.
-
- 10. F9 BBS disable. There may be a problem if you have the BBS disabled
- and someone connects and the terminal part times out, causing the BBS to
- be enabled for the next connect. I gotta see if I can force this.
-
- 11. HELP-KEY - Press this a second time before first completes, lose stack.
-
- 12. NETROM. If you connect to EPA, then tell EPA NETROM to connect
- to KB3UD, you think you are connected to KB3UD. No. You are connected to
- EPA, not KB3UD. BBS picks up on correct call from NET/ROM, TheNet, and
- KA-NODES and works OK.
-
- 13. NETROM. Set your FRACK and DWAIT a little higher if you get too many
- collisions with AX25L2V2 polls.
-
- 14. MESSAGE disconnects. Someone starts a message and disconnects. If no
- text has been entered, the BBS looks dead. Give it 256 seconds ~4 minutes
- to time out.
-
- 15. MESSAGE too big. This BBS has a safety switch that stops saving a
- messsage after 65k. You will have no indication of this. The counters
- and all are capable of many gigabytes, but my computer isn't.
-
- 16. CAPTURE too big. The terminal part has a safety switch thats stops
- capturing after 1.8 megabytes (+/-). Seemed a good number for my 3 megabyte
- RAM. I think this was deleted ??
-
- 17. MESSAGE forward. A lot of TNC STATUS lines go to the screen when the
- BBS forwards a message. The BBS looks for # (busy) C (connected to)
- D (Disconnected) etc. Again, this is useful debug info.
-
- 18. #ELK connection. The TNC won't allow this (C #ELK).
-
- 19. RM returns with error when no message for you.
-
- 20. *** DISK FULL. Another PRMBS special. I think this BBS will disconnect
- when it sees this message. If it don't, then it is a bug.
-
- 21. SP WA3MNT N3ET. BBS will not recognize N3ET, nor report the error.
-
- 22. CMD: HUH eh?. You may get 50 of these in a row. Happens when someone
- tries to connect and doesn't copy you. BBS retries out, sees another
- connect, and gets confused. Takes a while, but BBS should recover.
-
- 23. USR file corrupted. Usually drops everything but call, then gets wrong
- name on next user. I've had this happen after pushing PANIC BUTTON, F10,
- when BBS was active. Also happens with disk errors or messed up B:USR.
-
- 24. DIR file corrupted. Only saw this happen when SYSOP faked an entry
- without correct number of spaces. If you get lost, have another BBS or
- person send you a message like SP WA3MNT @ KA3JAI < WB3HVJ then look
- at what the BBS did in the DIR.
-
- 25. B:BID sometimes messes itself. New B:BID with old pointer. Fixed??
-
- 26. LIST NONE. If nothing to list, 'L' command just prompts.
-
- 27. Amiga DIR command. You get a GURU if you use DIR RAM: OPT I
- and then type 'T' on a file that BBS is writing to.
-
- 28. NO MEMORY. Gimme a break, if you run out of memory or DISK space,
- the AMiga should (will) tell you about it. I don't know how to handle
- this cause I never let it happen.
-
- 29. STACK 8000. BBS really needs about 1000 byte stack or less.
- I run with STACK 8000 in my S/Startup-Sequence file.
-
- 30 ICONS. I don't. So the BBS don't either. Sorry, but you rodent fans
- hafta learn CLI. Read this => you can't use the MOUSE to run the BBS from
- WORKBENCH.
-
-