Hello Bob!

Oct 15 15:00 03, Bob Jones wrote to Bo Simonsen:

 BS>> No it has nothing to with 7/8 bit thing because the 
 BS>> telnet "server" in maximus is running 8 bit.. 

 BJ> That's what we think.  Have we proved that maximus is running 8-bit 
 BJ> clear on the TCP/IP channel?  Including no control character 
 BJ> interpretation, etc.

Not really.

 BS>> The 
 BS>> problem is that Maximus isn't taking care of control 
 BS>> charecters is beeing send twice.. So formfeeds fx. is 
 BS>> beeing send as FF FF but maximus doesn't take care and 
 BS>> remove the extra FF..

 BJ> Ok.  So you are saying that the formfeed character (Control-L, 
 BJ> character 12 (decimal), 0x0C (Hex), or 014 (Octal)) is getting sent 
 BJ> twice when it should only be sent once by the Maximus BBS code?  I 
 BJ> assume you found this via a run of OD like I suggested, correct?  If 
 BJ> not, how was it observed?  

It's just a these, because I know that telnet is sending control charecters
twice, so I bet maximus isn't taking care of it.. Anyway I can find the
place where the code should correct for it.

 BJ> Is this being observed in sending of 
 BJ> files, such as the QWK packets?  What is happening to break uploads?

Yes, there is no problem with plaintext files.

 BJ> In that case, we probably need to look at the end-of line termination 
 BJ> translations that Wes probably put in or tweaked for the Unix / Linux 
 BJ> port.  There is some CR/LF stuff that has to get handled between Unix 
 BJ> / DOS think on the BBS side and what the VT-100 based code sends.....  
 BJ> It's been a while since I've looked at this type of stuff....  

Okay, but I bet we are on track of the problem.

 BS>> I were having a headache yesterday, so I really did 
 BS>> have problems, about thinking logically.

 BJ> Ok.  We all have bad days at some point.....  Hope you are feeling 
 BJ> better today.

I do :-)

Regards,
Bo

--- Msged/LNX 6.1.2 (Linux/2.4.18-586tsc (i586))