Punter File Transfer - Image BBS 3.0 / Vice 3.6.1 / tcpser
Posted: Tue May 03, 2022 2:10 pm
I set up an Image 3.0 BBS last night for the first time and WOW - am I impressed. I mean, just look at this:
- The ability to customize which masking characters are used to cover up the users' password as they type when logging on? That is attention to detail!
I wanted to try some file transfers, which seemed to be working when using CCGMS 2021 in one Vice session to another CCGMS 2021 running in a different Vice session, both using their own instances of tcpser on separate ports. Transferring in either direction in this configuration worked without a single bad block, and at 38400 no less. (Though it did seem to pause a lot between blocks... I'm not certain it was transferring at the full 38.4 kbps, but regardless - the files went through perfectly.) When I tried uploading from CCGMS to Image BBS 3.0 however, I could sometimes get one "good" block, and the rest were bad. Watching the data scroll across each screen I could see that things were different on each pass of what should have been the same block, so clearly some data was being dropped / corrupted along the way, and not in the same place or fashion on each pass.
I decided to look at what Vice was sending and receiving at each end, and here is what I found:
- Left: Vice running CCGMS. Right: Vice running Image BBS 3.0
On the left, the CCGMS side, it tries to send four 0xff bytes to the BBS, but the BBS receives only two 0x7f bytes. 0xff is a magic byte, both for the IP232 protocol and for the Telnet NVT protocol, so back into the source of tcpser I go to try and figure out what instruction is converting these literal 0xff bytes into misinterpreted, and then mis-translated 0x7f bytes.
My guess is that tcpser is operating in ASCII mode and therefore stripping off the MSB of the even numbered 0xff bytes after discarding the odds as (erroneous) NVT_IAC bytes.
... Actually, it looks like both tcpser instances are negotiating for binary transfer mode on connect, which is good, but they keep bouncing back and forth another NVT command incessantly, like one side is reiterating the command instead of acknowledging it... This is intriguing; Still digging...
- The ability to customize which masking characters are used to cover up the users' password as they type when logging on? That is attention to detail! I wanted to try some file transfers, which seemed to be working when using CCGMS 2021 in one Vice session to another CCGMS 2021 running in a different Vice session, both using their own instances of tcpser on separate ports. Transferring in either direction in this configuration worked without a single bad block, and at 38400 no less. (Though it did seem to pause a lot between blocks... I'm not certain it was transferring at the full 38.4 kbps, but regardless - the files went through perfectly.) When I tried uploading from CCGMS to Image BBS 3.0 however, I could sometimes get one "good" block, and the rest were bad. Watching the data scroll across each screen I could see that things were different on each pass of what should have been the same block, so clearly some data was being dropped / corrupted along the way, and not in the same place or fashion on each pass.
I decided to look at what Vice was sending and receiving at each end, and here is what I found:
- Left: Vice running CCGMS. Right: Vice running Image BBS 3.0On the left, the CCGMS side, it tries to send four 0xff bytes to the BBS, but the BBS receives only two 0x7f bytes. 0xff is a magic byte, both for the IP232 protocol and for the Telnet NVT protocol, so back into the source of tcpser I go to try and figure out what instruction is converting these literal 0xff bytes into misinterpreted, and then mis-translated 0x7f bytes.
My guess is that tcpser is operating in ASCII mode and therefore stripping off the MSB of the even numbered 0xff bytes after discarding the odds as (erroneous) NVT_IAC bytes.
... Actually, it looks like both tcpser instances are negotiating for binary transfer mode on connect, which is good, but they keep bouncing back and forth another NVT command incessantly, like one side is reiterating the command instead of acknowledging it... This is intriguing; Still digging...
<-- Those were added by my daughter, which sounds very cute but she's seventeen. haha. I love her... 
