Did this occur during a spike (the above)? If not... mebbe that's not all that's going on. Are you trapping just outgoing packets or also incomming, because it's probably something zoc is sending.

If so, run it both with zoc and w/ a normal telnet. It has to be something that's going back and forth, which can only be a packet. There has to be something there...

quote:Originally posted by CummingsSM

Thrawn702: Sorry for the confusion - I use SynchroNet (the most current version, 3.13a).

After 445 turns, I was able to duplicate the problem with SynchroNet and TWGS hosted on different systems (i.e., ZOC from computer a to SBBS on computer a via telnet, SBBS on computer a to TWGS on computer b via rlogin). I'm going to set TWGS to telnet and access it through the telnet gateway and see if the problem persists, that way.


No problem. I too run SynchroNet BBS. I run both the TWGs and the BBS on the same machine. I had to use the *telgate command line to work.

I have logged into TWGS via my BBS using my helper and found in the logs there are some commands that the TWGS tries to pass back to the helper, but the BBS seems to not know what to do with. I too experienced problems with the rlogin, so I do not use it. After months of going through similar experiences, I switched to just telgate. So you are on the right path...

Unfortunately, the telgate command will not allow us to have the username passed from the BBS to the TWGS at this time. I'm looking to also have that feature. The BBS uses drop files, so remember to go to a door, it reads either a door.sys or dorinfo.def file (or whatever you use). Using telgate is an external portal, so you can't route that info to the next connection.

Anyways, seems you have a handle on it. Figured I'd just drop my fun I had from one SysOp of SBBS to another

Not sure how relevant there previous posts are but at any rate they seem to address other potential problems and perhaps some other issues you have yet had a chance to address such as multiple players, etc. I was wondering also if it could be a Windows/OS TCP/IP/telnet overtake and reroute type of problem or port forwarding related issue? Eh, just something to consider.

Discussion w/ Toad’s SBBS setup, also talgate related.
http://www.tw-attac.com/TWForum/topic.asp?TOPIC_ID=2562

Discussion involving drop file problem efffecting multiple users:
http://www.tw-attac.com/TWForum/topic.asp?TOPIC_ID=7303

Lag in BBSes:
http://www.tw-attac.com/TWForum/topic.a ... C_ID=11044

Kemper discussing BBS 500ms inherent lag issue that causes pack loss and a CN9 set to all keys problem (seems related to what you have been explaining) and the like:
http://www.tw-attac.com/TWForum/topic.asp?TOPIC_ID=7173


Overview of the BATCH files involved, also mention of possible required FOSSIL driver use:
http://www.tw-attac.com/TWForum/topic.a ... C_ID=18504

I think you saw this already is the step by step manual by cwnowell and some info by Thrawn (telgate related also direct connect to TWGS or via BBS front-end):
http://www.tw-attac.com/TWForum/topic.a ... C_ID=20029

quote:Originally posted by RexxCrow

[beige]Not sure how relevant there previous posts are but at any rate they seem to address other potential problems and perhaps some other issues you have yet had a chance to address such as multiple players, etc. I was wondering also if it could be a Windows/OS TCP/IP/telnet overtake and reroute type of problem or port forwarding related issue? Eh, just something to consider.



It's a hard route when tracking the problem. Almost like tracking an electrical problem in a car. There are so many variables when using communication programs. Your connection, speed, etc. Our connection, speed, etc. All a SysOp can do is eliminate one task at a time, from simple items to the ones we would never even suspect.

I use to run both Remote Access BBS and SBBS for DOS back when TradeWars was DOS only. They used the standard dorinfo1.def or door.sys drop files and you had to configure each node in TradeWars. No matter the player connect rate, that info was passed to the TradeWars game from the drop file.

Now we have SynchroNet and the ability to use either rlogin or telnet access. I've tried to use the rlogin and had the same results. There were many delays and when checking my logs from the BBS it appeared the helper was trying to send/receive data and the BBS could not handle it. So I switched to just the telnet only login, using the *telgate command. It still gives those errors, but not as frequent and there are no delays.

So from my experience, it seems that a helper going through the BBS will work great on telnet. The old expression we use in IT is "if it works via door #1 but not door #2, then use door #1". There are more variables involved here than before. As pointed out by Rexx, it could be something such as Windows/OS TCP/IP/telnet or an anomoly. However, I am very much interested if you do keep at it and get it working.

Another thought is the rlogin por and port forwarding, as pointed out by Rexx. For example, Synchronet has it's default port for rlogin, and I had assumed that if I set the TWGS to port 2002 that was the port for both telnet AND rlogin. Perhaps the issue lies in the routing table. If you have the port forwarding the BBS rlogin port, it could be getting stuck coming from the BBS port to the TWGS port and back. I realize I could be skating on a vapor trail, but as i said before one must look at both the obvious to the unimaginable when tracking an IT issue. Especially packet delays/losses.

Singularity: Yes, that was during a spike - like I said, when I press enter it generally "unspikes" for a limited amount of time and reads my "enter" as a new command. Sometimes it unspikes only long enough to give me half of the next output dump, sometimes it unspikes long enough to do three or four trades. Eventually it spikes permanently, until I shutdown the tw2002.exe process (in any of numerous ways). The packet scan was all traffic for port 513 on the TWGS host, so it included the incoming data from SBBS (i.e., when I pressed enter, it posts the character strings for a DOS/Windows line break: \r\n). I see absolutely nothing abnormal about the input ZOC/SBBS is delivering to TWGS, but I do see incorrect output (i.e., the data that should be in one packet is not, it is delivered in a subsequent packet only after additional input is generated). I can post some packet sniffer results, if you're interested in sorting through it. I will look at it again when I have more time, but I'm not sure there's anything there. I will also try comparing the results of directly connecting with ZOC

Thrawn702: I'm not really using a helper, just ZOC, which is a pretty standard telnet client. No scripting, et cetera. I think this is likely to be a more fundamental error in someone's implementation of rlogin, or something like that. I have almost definitely isolated it to rlogin and to ZOC. I've tested several thousand turns without one of those two components and haven't been able to recreate the problem. But regardless of what else I do, if those two components are present it's only a matter of time until tw2002.exe starts misbehaving.

Both TWGS and SBBS seem to be smart enough not to bind to the same port. I forgot to disable SBBS's rlogin service before I started up the TWGS service and it refused to start, correctly, because the port it was configured to use (513) was already in use. This is definitely not a port issue. I use SBBS on the standard telnet port (23) and TWGS on the standard rlogin port (513) and neither of them use the other port, except when I configured TWGS to use telnet instead of rlogin, and at that point, they were on different machines.

RexxCrow: The FOSSIL driver/BATCH file/drop file/et cetera stuff is for the DOS version of TW2002, which I have installed and runs perfectly on my BBS. I'm only having problems with the TWGS version, which cannot be configured as a BBS door.