uIP/lwIP for Amiga OS

[Trev]

Here's a small demo of uIP running a built-in web server. It's slowish and probably buggy, but it works for me. For simplicity, it's reading orphaned packets (in SANA-II lingo), and probably will not work along side other network stacks.

Download here: http://www.babacar.org/uip-0.1.0.lha

To install, extract to your favorite temp directory.

To run, issue the following command from your favorite CLI:

uip Devs:Networks/xxx.device n

where xxx is your SANA-II ethernet device and n is the unit number.

An IP address is not automatically assigned, and the stack is configured to use ping-based assignment. From a remote host, issue the following commands (or their equivalents):

arp -s n.n.n.n xx-xx-xx-xx-xx-xx
ping n.n.n.n

where n.n.n.n is a local IP address, e.g. 192.168.0.3, and xx-xx-xx-xx-xx-xx is the physical address of the ethernet device. It will be displayed when you start uIP.

A bare-bones uIP implementation (in source form, of course) could be useful for anyone wanting to add basic embedded IP support to an application.

lwIP is quite a bit more complicated, but it's a good candidate for a free and open source replacement for AmiTCP 4, Genesis, Miami, et al. Nice to have features (like a dialer, which you could easily implement in a script) would have to be implemented separately.

EDIT:

And because this is Amiga software, I should also note that it only works with red patch cables. If you to try to use a blue one, the software detects the treasonous act and will attempt to format your grandmother's vacation photo SD cards using spooky action at a distance (in linear time, unfortunately).

Trev

[Dandy]

Trev wrote:

...
I should also note that it only works with red patch cables. If you to try to use a blue one, the software detects the treasonous act and will attempt to format your grandmother's vacation photo SD cards using spooky action at a distance (in linear time, unfortunately).

Trev

 :-D
Tell me more...

[Colani1200]

Very cool!! What are the system requirements?

Trev wrote:
running a built-in web server.

Are the web pages also built in? Or can you put them into the uIP directory?

lwIP is quite a bit more complicated, but it's a good candidate for a free and open source replacement for AmiTCP 4, Genesis, Miami, et al.

So, are you going to port that one as well?

[Trev]

@Dandy

Quantum coupling is slated for the next release.

@Colani1200

The web pages are compiled in, but the web server could be modified to read files instead. Anyhow, it's just one of the sample applications included with the uIP package.

I'd like to make uIP more robust and improve performance to the point that it's actually useful. After that, yes, I'll be working on lwIP. For anyone with just a little bit of Amiga device I/O knoweldge, uIP is quite simple. I hadn't looked at Amiga code in a few years, so it took a few days to get back up to speed.

A ROM-able IP stack would be cool. That might make things like PXE possible. It's a very Intely specification, though.

EDIT:

Regarding system requirements, I hadn't thought about it, and I haven't done any profiling. I'm using a PCI adapter for testing. When I get a few moments, I'll test on a vanilla A1200 (Kickstart 3.1 / Amiga OS 3.1) with a PCMCIA adapter. I have an A500 with Kickstart 1.3 here but no network interface. uIP was design for 8-bit architectures with very little RAM (it's the stack inside Contiki on the C64), so it shouldn't be a problem to get it working on an A500 in some form or another. Whether or not I get it working on older/slower hardware is entirely dependent upon how interested I stay in the project. This is just one of my many hobbies, after all. ;-)

Trev

[Chain]

What a nice little server  :-o



tested on:
A4000/060, os 3.9, hydra.device

[Colani1200]

IMHO an interesting target platform is the A600, because it is much more diffiicult to expand than an A1200 or the big box Amigas, plus it also has a PCMCIA slot. This means, plain 68000, 1 MB RAM. I´ll try it out on my 600 when I have a free minute.

[Trev]

@Chain

Sweet. Now I know it works on something other than my test system. ;-)

@Colani1200

Yes, the A600 is an attractive target. Wish I had one. I need to dig up a PC card compatible with cnet.device or find a 3C589. I know I've got one of those somewhere. The hard part will be finding the dongle. That reminds of this great ad Xircom ran circa 1998 for their RealPort PC card. On one page, a picture of Michelangelo's David sans genitalia. On the other, a picture of the card and the slogan, "Lost the dongle."

Quick rundown of future plans:

1. More buffers. I'm using one now, which results in missed packets. This would increase memory usage by 1518 bytes plus struct overhead (IOSana2Request and any list management data) per buffer. Not an attractive solution, but it will increase performance. This should be a runtime option.

2. Instead of watching for orphaned packets, watch for IP and ARP packets. That requires at least two requests. The code could be written to share a buffer, but again, missed packets.

3. Use an event based loop rather than a polling loop. Not difficult, but timer requests will add yet more memory overhead.

4. Share source code. It's full of commented out sections of code right now. Need to clean it up and post it. It's a BSD-style license, which means you can do whatever you want with it and distribute it however you like (with or without source code) as long as you pass along the copyright information.

The SANA-II v3 device specification does not require devices to cache or buffer information in any way. That makes it difficult (if not impossible) to share the device with another stack looking for the same data. The device could be written to service multiple requests for the same data, but since we can't make any assumption about the device apart from what's documented in the specification, I'd say support for uIP or lwIP alongside AmiTCP or another stack is out.

Trev

[Colani1200]

OK, I tried it on my stock A600, but I get a Software Failure. Error: 8000 0003 Task: 0005CAE0.

My A600 (like most of them) is OS 2.1 of course. I don´t know if that is the problem though. Any chance to debug this?

[Matt_H]

Some of the terminology here is over my head; is this a tiny little TCP/IP stack, or is it a custom networking interface?

Looks like fun, though. Hope you continue to work with it.

[Piru]

he SANA-II v3 device specification does not require devices to cache or buffer information in any way. That makes it difficult (if not impossible) to share the device with another stack looking for the same data. The device could be written to service multiple requests for the same data, but since we can't make any assumption about the device apart from what's documented in the specification, I'd say support for uIP or lwIP alongside AmiTCP or another stack is out.

Actually later SANA2 speifications updated this, making it mandatory to handle multiple readers properly (that is, the packet is sent to all readers, rather than sending it to the first reader in queue).

[Trev]

@Piru

I did finally read that addendum to the specification. It's uncertain, however, how many developers have kept up with the specification given its age. It doesn't help that SANA-IIR2 is the only release on Aminet. SANA-IIR3 is split up among three or four different directories on the Developer CD V2.1, and SANA-IIR4 was posted on the short-lived Amiga, Inc. developer forums. Hyperion has included a current SANA-II header set in the OS 4 SDK, but the documentation itself is missing. :-(

Source code availability--as with your cnet.device, for example--is the exception rather than the rule. Do you know if anyone has put together a list of features--SANA-II revision, tag support, etc.--supported by available SANA-II devices?

I'm testing with openpci_8319.device, and it appears to use S2_CopyFromBuff for most transfers. Ben's always been helpful. I'll send him a message and see if he can shed some light on the internals of his driver.

Speaking of tags--and I haven't looked at the cnet source yet--how did you interpret the implementation of S2_DMACopy*Buff32?

EDIT:

Just looked at the cnet source (no longer maintained by you--oops!) and answered the question. Exactly what the SANA-IIR3 documentation states. :-)

VOID * SAVEDS REGARGS DMACopyFromBuff32(REG(a0, VOID * from));
VOID * SAVEDS REGARGS DMACopyToBuff32(REG(a0, VOID * to));

And assuming we passed a properly aligned and allocated buffer in the first place, 'return from;' and 'return to;'. Of course, one hopes the buffer used in CMD_READ is large enough to hold the data, since the callbacks don't ask. It looks like ios2_DataLength is actually used by the driver in this case.

Trev

[Colani1200]

I tried uIP on my A1200 and it works fine both with cnet.device and prism2.device (wireless).  8-)

How could one track down the problem on the A600? I tried SnoopDOS, but it does not show very much:

 7     [4] Shell Process  GetVar     work:uip/uip                Alias   Fail
 8     [4] Shell Process  FindVar    work:uip/uip                Alias   Fail
 9     [4] Shell Process  GetVar     _pchar                      Local   Fail
 10    [4] Shell Process  GetVar     _mchar                      Local   Fail
 11    [4] Shell Process  #EXAM_OBJE     63AE,    296C3          DH0     OK  
 12    [4] Shell Process  #PARENT        63AE                    DH0     Fail
 13    [4] Shell Process  #FREE_LOCK     63AE                    DH0     OK  
 14    [4] Shell Process  ChangeDir  DH0:                                    
 15    [4] Shell Process  Lock       work:uip/uip                Read    OK  
 16    [4] Shell Process  *Lock      work:uip/uip                Read    OK  
 17    [4] Shell Process  #LOC_OBJEC        0,    296FA, FFFFFFF DH1     OK  
 18    [4] Shell Process  #EXAM_OBJE     63AE,    17430          DH1     OK  
 19    [4] Shell Process  #FREE_LOCK     63AE                    DH1     OK  

Is there something like truss or strace for Amiga?

[Trev]

@Colani1200

I suppose I should add some debug information to the code. The Amiga-specific bits of code should be allocating memory on 32-bit boundaries. I haven't verified the portable bits.

I also haven't looked at alignment of structures defined in code. It's possible they're on odd boundaries, and the optimizer isn't picking it up.

I've modified the code quite a bit since I posted the binary, mostly to test things I'll be doing in lwIP (started on that, too). While I was doing that, however, I was thinking it's probably a good idea to keep uIP as simple as possible and write something that works on all manner of Amigas, assuming they have a SANA-II ethernet device of some sort. All this is really just driven by what I find interesting at the moment, so we'll see. ;-) Anyhow, expect gcc-compatible source code with that.

I'll be in and out of town for the next two days, but I'll try and get something new up by Wednesday evening.

All that said, you might want to verify you're using the correct SANA-II device on your A600, i.e. the 68000 one. (I guess that's obvious, but I know I've renamed something.device.68020 to something.device in the past and completely forgotten that it's 68020 specific. Speaking of rookie moves, I overwrote openpci.library with a copy openpci_8139.device earlier today. Stupid CrossDOS file system. ;-) Anyhow, big fun restoring it--wasting a CD on a 30K file--since my only floppy is hooked up via a Catweasel Mk3 PCI. Time to flip it over and use the Zorro edge, I guess.)

Trev

[Trev]

@Matt_H

uIP (read: micro IP) is a very tiny IP stack. It has both a raw and a BSD socket-like interface. It's really meant to be embedded as a special purpose stack for sending small, unfragmented frames, although it scales up if necessary. When installed in ROM (on a theoretical PCMCIA network card, for example), it has a very (very!) low RAM footprint. My implementation is a bit of a pig.

lwIP (read: lightweight IP) is a general purpose IP stack and a possible replacement for AmiTCP, Miami, et al as the guts behind bsdsocket.library on Amiga OS 68K.

Trev

[Colani1200]

Trev wrote:
All that said, you might want to verify you're using the correct SANA-II device on your A600, i.e. the 68000 one.

The device is correct since it works fine with AmiTCP 4.0 demo (except that it you can't do much with it without running out of memory).

I've modified the code quite a bit since I posted the binary, mostly to test things I'll be doing in lwIP (started on that, too).

Sounds great, I really appreciate your work. An open source stack for the Amiga (maybe for all Amiga/Amiga-like platforms one day) would be awesome.