Skip to main content
Topic: New uIP code features (Read 41859 times) previous topic - next topic

New uIP code features

Hi all,

Just dropped another update to the uIP stack project to svn/trunk/web-platform/firmware/uIPStack.
Some notable changes are:
  • The code runs 3 "tasks" that it multitasks between. One for the IP stack, one for the serial port (debugging help) and another for a handler for telnet (port 23). The point of the multitasker is to make it simpler to code stuff without worrying about blocking other things that need to happen (particularly, the network stack, or other tasks)
  • The telnet server task is pretty easily extendable ( just add the name of the command, and a pointer to the function that implements it to telnettask.c)
  • To find out what commands it supports, enter "help"
  • It should be reasonably easy to write a web server task now, but without the ability to read files, you can't serve much (maybe dump all the memory to a html response??)

Some FYIs:
The IP address is fixed in code as 10.0.0.251. You'll need to change as desired.
Lots of debug stuff still being printed to the serial port at 115200 (8/1/none)

Good luck!
Tony.

Re: New uIP code features

Reply #1
Great! but... Just tried this and two comments:

1) The serial debug messages don't sent a carriage return, only a line feed, so hard to read (I'm using Tera Term)
2) Telnet doesn't appear to echo anything back - errors in serial console:

app: connected. Ports 5888:-11004
echo: connect from 000a0100
echo: using handle 0app: newdata. Handle: 0. len=16
echo: file state 3
echo: event 1
echo: can_read 16 @ 15f8
echo: seek 0
echo: not_found seek 16

I typed 'h' - was starting to type 'help'

Re: New uIP code features

Reply #2
Ah!
Well see I'm a linux user so the linefeeds are sufficient. I hadn't thought of that. It should be a simple matter to do a bulk replacement of n with rn (or nr...I'm not sure which way round they should go )

And that probably also explains the second one - my telnet uses line mode and seems to do local echo automatically. It doesn't send the data to the device until you hit "enter", so I didn't echo back what was sent. The messages you see in the console aren't errors; just debugging stuff ( I don't have a picKit or anything like that - it's all just printf statements for debugging )

And thinking about how the parser works now, it's probably not going to work in 'one character at a time' mode. To be honest, I'm not really happy with that part of the code, so I'll have to revisit it. If you can set your telnet to line mode, it should work (if that's any consolation?)

But good feedback, thanks!

Re: New uIP code features

Reply #3
rn seems to be the common, but both should work.

There was a topic about the telnet server from microchip, in which some bugs were revealed when using different clients. ( http://dangerousprototypes.com/forum/in ... opic=501.0 ) Dunno if it helps.

Re: New uIP code features

Reply #4
Thanks Sjaak, I'll keep that thread in mind (note that my implementation doesn't require you to "logon" at all at the moment)
Hopefully I can do some telnet option negotiation soon, and that should help improve the interoperability.

An improved telnet task was committed to svn about 10 hrs ago. It now echos ( annoyingly if your client is in character, local echo mode) and added a new command "paramcheck" as a demo of how to read parameters for commands from the line it "executes".

Todos: option negotiation for echo and line/char mode; support for backspace character in char mode; then adding some useful? commands. I have these in mind: settting the date/time; configuring ip address, mask and gateway and storing those to the flash memory chip...and of course reading them and setting up uIP on startup. Might be good to be able to set the mac address too.

Re: New uIP code features

Reply #5
[quote author="bonybrown"]
Hopefully I can do some telnet option negotiation soon, and that should help improve the interoperability.
[/quote]

Don't waste your time on the Windows default telnet.exe - you can't get it out of char-by-char mode. It only supports the following operating parameters:

    *     WILL AUTH (NTLM Authentication)
    *     WONT AUTH
    *     WILL TERM TYPE
    *     WONT TERM TYPE
    *     LOCALECHO off
    *     LOCALECHO on

Yep, pretty much a broken client and lost cause.

Re: New uIP code features

Reply #6
Thanks for the tip Trev.
If I can get the echo state stored out, it will work sufficiently, except for the backspace key at the moment.

Re: New uIP code features

Reply #7
Neat stuff.

I tried Tera Term Pro, Putty, Hyper Terminal and windows Telnet, with original code - non work properly, even if I send help, I get nothing back.
 But - Linux telnet works fine - as you expected!

Keep up the good work, once a windows telnet is working, I will try adding a 'read_adc' command for my MAX147 demo!

Thanks,

Will

Re: New uIP code features

Reply #8
Trev, good advice about using a packet sniffer for the telnet traffic. I used wireshark and it even decoded the telnet options being passed back and forth, so that helped a lot.

So the telnet server has now been updated.
I've tested it with linux, windows and mac clients ( all the OS standard "telnet" commands) and it works fine, all in character at a time mode, ie, lowest common denominator.

I've added a new command as well : [tt:]memdump [address] [count][/tt:] which will dump the memory from [address] to the telnet client. Here's a sample session:
[tt:]tony@barellan:~$ telnet 10.0.0.251
Trying 10.0.0.251...
Connected to 10.0.0.251.
Escape character is '^]'.

Web platform telnet. Enter help for commands.
>help
Configured commands:
help
echo
time
quit
memdump
>time
RTCC Date/Time: 2010-05-16 23:16:12
>memdump 0x1400 64
1400    ce de 42 9d 6f 64 f8 f5 ..B.od..
1408    d0 a6 6b f7 a3 e1 4a ad ..k...J.
1410    44 3c 4c d4 9f 07 9c 0b D1418    72 78 95 ba a9 bc 26 fa rx....&.
1420    4e fe e7 7a 56 65 7a 83 N..zVez.
1428    0b 75 a7 39 a6 0e f4 f9 .u.9....
1430    f0 c5 d3 27 74 a9 b1 7f ...'t...
1438    30 5a 90 03 1c 47 0a 6d 0Z...G.m
>quitConnection closed by foreign host.
tony@barellan:~$[/tt:]

For those interesting in implementing commands for telnet, the signature of the function you would need to implement is now:
[tt:]void telnet_command( file_handle_t handle, char** argv, unsigned int argc )[/tt:]
That is, almost exactly like a standard 'c' main(), except the return type is void, and the file handle for the tcp connection is passed in for your command to read and write from. The parameters to the command are already parsed and presented in the char* array argv, with argc items. argv[0] is the command name. argv[1] is the first param.

Regards,
Tony

Re: New uIP code features

Reply #9
Very nice! I might have to implement a telnet Bus Pirate using the new code :)
Got a question? Please ask in the forum for the fastest answers.

Re: New uIP code features

Reply #10
[quote author="ian"]
Very nice! I might have to implement a telnet Bus Pirate using the new code :)
[/quote]

Don't make it multiuser ;) Could be fun to 'help' collegaes ;)

Re: New uIP code features

Reply #11
Another new feature: you can now read files and list directories from the SD card.
I've added the 'cat' and 'ls' commands to the telnet server (I guess that's 'type' and 'dir' to the windows' folk)

There's also a 'sddump' command that will dump sectors from the sd card in the same way that  memdump dumps memory, for troubleshooting.

Writing files is as yet untested (and there's no telnet commands that do any writing yet, anyhow), but the dosfs library does support it.

Would be good to know if it works with other people's SD cards.

Regards,
Tony.

Re: New uIP code features

Reply #12
I noticed you used DosFS, did it work ok for you? As I recall, there were several things I had to fix the last time I used DosFS on PIC. I had been looking at this FAT stack for a future project:
http://dangerousprototypes.com/2010/04/ ... d-library/
Got a question? Please ask in the forum for the fastest answers.

Re: New uIP code features

Reply #13
I took the existing code from the dangerous prototypes SVN, so maybe I already have your fixes?

That code didn't work at first, but that was due to the SPI interface. I see lots of code that doesn't bother to read SPIBUF after a write, but on the dsPIC, doing that will lock up the SPI due to the receive overflow bit being set - so maybe that's a dsPIC specfic thing?

Once that was sorted out, I didn't seem to have any problems. Maybe I'll hit problems when I start looking at writes?

Re: New uIP code features

Reply #14
[quote author="bonybrown"]
Would be good to know if it works with other people's SD cards.
[/quote]

Kingston 4Gb

Code: [Select]
>ls /
Error finding partition start

>sddump 1
Error reading sector. Response code:01

A small amomaly that took me a while to figure out: the uIP stack fails to initialise (ie it hangs immediately after "timer init" and a blank line) if I use the reset button or after a firmware upload. The heartbeat LED is on solid. The only way to get it to work is to remove the power and then it's fine.