Login  
Search All Forums
Dart Home | PowerTCP Emulation for ActiveX | Custom Development Reply | PowerTCP Emulation / Telnet for ActiveX Topics | Forums   
AuthorForum: PowerTCP Emulation / Telnet for ActiveX
Topic: Problem Receiving 0x8D
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 5, 2003 11:45 AM
I have been testing your tool by sending and receiving raw data (bytes 0x00 through 0xFF) through the connection.

I was having problems 0x0D characters getting a 0x00 appended to them when sending. I also had problems with sequence 0x0D0A getting converted to 0x0D when sending.

I have resolved this issues, but my testing logs show that when I receive a 0x8D it becomes a 0x0D. All other bytes are received without a problem.

Do you have any idea why your tool would be changing the 0x8D character?

Thanks in advance.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 5, 2003 1:42 PM
I am not able to duplicate this. I created a file on my UNIX machine called 8d.txt that contained one byte (0x8D) and then using our Telnet control connected and sent "cat 8d.txt" and I got back a 0x8D.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 8, 2003 11:20 AM
Well, I think there might be a problem with how the options are getting negotiated.

In my program I override the Telnet_Command procedure and accept the Com Port option and any com port suboptions. Everything else is rejected, but do note that the server attempts to negotiate a binary connection.

Now, in my last post in this forum I spoke with K M Drake, who told me the following:

"When TRANSMIT-BINARY has been negotiated, a naked CR is not padded with a NULL character when data is sent, and a NULL character would not be stripped when data is received.

Conversely, if the option has not been negotiated, all naked CRs are padded with NULLs when data is sent, and the NULLs after CRs are stripped in received data."

I have found that this is not the case. Currently I am rejecting all option commands that are sent to me including binary, and I am able to send 0x0D and a NULL does not get padded or stripped. When I do accept the binary option, the NULL gets added and stripped.

I think your control is getting confused about when the option is negotiated because I am overriding the Telnet_Command function. I am seeing behavior that is exactly the opposite of what was stated to me.

Could this odd behavior be linked to the 0x8D -> 0x0D problem?

Thanks for your quick response to my last post.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 8, 2003 11:39 AM
Everything seems to be in order at my end.

In order to test this, you'll have to write a small test program that shows the behavior. Please write this and zip it up, then mail it to support@dart.com ASAP.

Make sure that the server is accesible to us!
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 8, 2003 11:47 AM
I can write a test program, but there is no way that I can expose the server in question to you guys. If I tell you the options that the server attempts to negotiate and give you some trace output, would that be sufficient?
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 8, 2003 11:49 AM
I guess it will have to be. Make the program as simple as possible so that the trace contains ONLY WHAT IS NEEDED to show the problem. I can write a local server that responds the same way yours does.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 8, 2003 12:06 PM
Just so you know, I won't be able to get the code an server information to you until tomorrow because of some conflicts I have today.

Thanks for the lightning fast responses.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 12:48 PM
Tony -

I have a couple quick questions for you about the output from your tool's Trace function that may save us all some time.

At what point does it write the data to the log file?

Does your tool change anything in that data set based on options that have been negotiated before sending it to the trace file?

What I am seeing is that the 0x8D has already changed into a 0x0D in your trace logs as well as my own logs (after the data has come through your tool). If your trace logs show the raw data coming in on the port, then
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 12:58 PM
argh... sorry for that incomplete last post. I accidentally hit the post message button.

As I was saying:

If your trace logs show the raw data coming in on the port, then there may be no problem with your tool. I have no idea why the server (which is a commercial product) would be changing that byte sequence though.

I am still going to put together the trace files and the simple test prog because I want you guys to see the strange binary option behavior that I described earlier.

Thanks,
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 9, 2003 1:18 PM
All tracing is done at the TCP level so the data you se in the trace is unprocessed.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 4:44 PM
Alright. I think I have finally figured out what is going on here. The trace files have proved invaluable to the analysis of the problem.

I override the Telnet_Command function and negotiate the binary option manually using the SendCommand function. In this case your tool does not recognize that the binary option has been negotiated and continues to change 0x0D00 characters into 0x0D.

This is what was throwing me before, I thought that the problem was with the 0x8D byte, but that is something that my server can't send when the binary option has been turned off. Everything else comes across fine because the server pads 0x0D with a NULL and your program strips it. I need to operate in binary mode so that the 0x8D comes across fine, but then your program still strips the NULL character.

I have done 4 tests that show your tool always strips a NULL character following a 0x0D regardless of the binary mode negotiated.

Since you can negotiate binary transmission, and reception I tried every possible combination to see if your tool would recognize that the binary option and stop stripping NULL characters.
In every case the NULL was stripped.

How can I stop your tool from stripping NULL characters when I override the Telnet_Command function and negotiate binary manually using SendCommand?
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 9, 2003 4:51 PM
Create a trace using the following Trace statement:

Telnet1.Trace "c:\darttrace.txt", True, True, vbcrlf + "---> ", vbcrlf + "<--- "

then zip the trace up and email it to support@dart.com. I will try to recreate the problem using your trace.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 4:55 PM
I assume you want a trace when the binary option is fully negotiated.

Also, I am working in C++, but I will rename the file accordingly and use your prompts.

I'll be sending it your way in a few minutes.

Thanks
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 9, 2003 5:02 PM
Yes. That's correct.

By the way, have you purchased the product yet? All I see in our database for your email is a trial back in March. If you have purchased the product and support, please email sales@dart.com so that your record gets updated.

Thanks.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 5:29 PM
Your tool was purchased by my company, and was originally registered to another developer who has since moved on. I am now the sole owner of the tool and can straighten anything out. What information does sales@dart.com require to mark that kind of ownership change.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 9, 2003 5:35 PM
When you send the trace, tell them your serial number and tell them it's in regards to Forum Topic 3453
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 9, 2003 5:37 PM
I just sent the trace before I read your last post. I'll resend and include the information you just gave me.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 10, 2003 9:25 AM
Please post the code from your command event so that I can verify that you are doing it correctly.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 10, 2003 11:36 AM
Here is my Telnet_Command code. I included all of my branch logic, but cut out some of the code that has no impact on the binary issue. I don't know how well this will show up in the forum...

VARIANT    ovSubOpt;

VariantClear(&ovSubOpt);
ovSubOpt.vt = VT_BSTR;
ovSubOpt.bstrVal = NULL;

if ((Command == DartTelnet::telnetWill) &&
(Opt == DartTelnet::telnetComPort)) {

//
// Removed because it isn't important to the binary question
//

}

if ((Command == DartTelnet::telnetWill) &&
(Opt == DartTelnet::telnetTransmitBinary)) {

PrintLog("Binary Reception Negotiated.");

try {
pTelnet->SendCommand(DartTelnet::telnetDo, Opt, &ovSubOpt, VARIANT_FALSE);
} catch (_com_error e) {
return;
}
return;
}

if ((Command == DartTelnet::telnetDo) &&
(Opt == DartTelnet::telnetTransmitBinary)) {

PrintLog("Binary Transmission Negotiated.");

try {
pTelnet->SendCommand(DartTelnet::telnetWill, Opt, &ovSubOpt, VARIANT_FALSE);
} catch (_com_error e) {
return;
}
return;
}

//
// Once the com port option has been negotiated, check for SupOptionEnd
// or SubOption commands that indicate data was sent via a SubOption.
//
if ((comOptionNegotiated) &&
((Command == DartTelnet::telnetSubOptionEnd) ||
(Command == DartTelnet::telnetSubOption))) {

//
// Removed because it isn't important to the binary question
//

} else {
//
// Reject any further communications as we only want a basic NVT
//
if (Command == DartTelnet::telnetWill) {
try {
pTelnet->SendCommand(DartTelnet::telnetDont, Opt, &ovSubOpt, VARIANT_FALSE);
} catch (_com_error e) {
return;
}
}

if (Command == DartTelnet::telnetDo) {
try {
pTelnet->SendCommand(DartTelnet::telnetWont, Opt, &ovSubOpt, VARIANT_FALSE);
} catch (_com_error e) {
return;
}
}
}
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 10, 2003 11:37 AM
I may not even need to look at your trace. I just ran a test and got it to work by doing the following:

1) Make sure "AutoOption" is True
2) Make sure "Binary" is True
3) After connecting use SendCommand to send a telnetDo, telnetTransmit

dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 10, 2003 12:10 PM
From what I understand of your documentation, if AutoOption is true, then the Telnet_Command event does not get fired. I need to capture the Com Port option and its suboptions using this event. I know that your control will work if AutoOption is true and Binary is true, but I can not get it to work with AutoOption set to false because it does not recognize when I have negotiated the binary option manually and continues to strip NULLs and pad Crs with NULLs as well.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 10, 2003 12:28 PM
That's true.

Are you sending Telnet1.SendCommand telnetDo, telnetTransmitBinary outside of the CommandEvent? Ideally you would send that right after connecting.

If you aren't sending that, then the option will not get negotiated unless the server offers it first.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 10, 2003 12:39 PM
The server is offering the binary option both for transmission and reception. The trace should show that. My logs show that the binary option has been negotiated in both directions (ie that particular branch logic succeeds) right when the connection is established.
dphill

From: Tucson, AZ USA
Posts: 15
Member Since: 07/16/03		 posted September 10, 2003 12:41 PM
Additionally, when I go through this negotiation with the server, it stop sending Crs padded with NULLs and stops stripping them. So the server thinks that the options have been negotiated and behaves accordingly.
Tony Priest



From: Utica, NY USA
Posts: 8466
Member Since: 04/11/00		 posted September 10, 2003 1:02 PM
We're going to have to take this off the forum. I'll have a sales person contact you regarding support options.

Sorry I was not able to resolve it here.
Reply | PowerTCP Emulation / Telnet for ActiveX Topics | Forums   
This site is powered by PowerTCP WebServer Tool PowerTCP WebServer for ActiveX