[En-Nut-Discussion] changes inside the ip stack?
Dave
ethernut at wormfood.org
Sat May 28 07:21:01 CEST 2005
Hi Gerd,
While not directly related to the problem you asked about, I do have a
fix for your workaround I thought you might like :-) While erasing the
first 27 characters (9 telnet options) will work with your telnet
client, it may break other clients. I know, because another telnet
client I tested only sent 5 options, or 15 characters. I probably spent
an entire day researching telnet, in detail, for my project. The RFCs
that cover all the parts of telnet are scattered around, and it is a
real mess.
Anyways, here is what you could do to 'fix' your workaround.
Delete the workaround
> //27Byte workaround :-(
> fgets(nbuff,28,stream);
and find the 2nd fgets just a few lines down
> if (fgets(nbuff, sizeof(nbuff), stream) == 0)
> break;
and insert the following code somewhere after it.
cp=nbuff;
while(*(cp)!=0)
if(*cp==0xff)
memcpy(cp,cp+(*(cp+1)==0xff?2:3),strlen(cp+1));
else
cp++;
Using memcpy the way I do may be abuse of the system, since the docs say
not to use it of the source and destination buffers overlap, but it
works for me. Use memmove instead if it is a concern.
What my code snippet does, is search the buffer for 0xFF, and if the
next byte is also 0xFF it deletes 2 bytes, otherwise it deletes 3 bytes.
If you would like code that sends back a suitable response to the telnet
options received, let me know, and I'll share that code with you too,
but just ignoring the options seem to work just as well.
I've expanded the portdio program into quite a bit more than it was,
just like you did. I plan on sharing what I'm doing when I'm done. Your
code already has a few odds and ends I have on my list of things to do.
If you would like to share code and ideas with me on the subject, let me
know. I written a few commands for mine that you don't have yet, that
I'd be more than happy to share with you (or anyone else who asks).
-Dave
More information about the En-Nut-Discussion
mailing list