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

[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

[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

[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

[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

[Trev]

@Crumb

I do intend to check it out. lwIP has a lot going for it, though: it's actively maintained by experts in network and embedded programming, it's used on many platforms, and it continues to garner support and visibility in industry publications.

EDIT:

AROSTCP is a port of AmiTCP, so there may be some benefit in creating a branch of AmiTCP that includes improvements from AROSTCP and the MorphOS stack. I think AmiTCP works fine for most people as-is, however, and AmiTCP 4 and Genesis are available for folks who want a commercial (unsupported?) stack.

@hardlink

Eek. I don't have either of those devices, but I'm sure we can sort through it. The SANA-II documentation is ambiguous in parts, and everyone has their own interpretation. I'm probably doing something incorrectly, although the S2_ONLINE and S2CONFIGINTERFACE commands are pretty straightforward. It might just boil down to me not zeroing out unused fields in the IORequest structure prior to sending the commands.

If you've previously brought the device online using another stack, you may need a cold reset before the device will work properly with a different stack. In a perfect world, we could see if the device is already online, and if it is, just start listening. In practice, it doesn't work that way. At least, not yet.

New executable, no optimization, slightly better output with error codes; and source code:

http://www.babacar.org/uip.lha
http://www.babacar.org/uip-src.lha

(EDIT: Man. My complimentary web hosting account is dog slow. I'd be better off hosting the stuff here at home. I suppose this will show up on Aminet once it's in a condition suitable for mass consumption.)

The base requirements should be a 68000, Exec V36, and a SANA-II ethernet device. It's small enough that it should run under any memory configuration.

There are probably numerous errors as a result of my much outdated and hole-filled Amiga coding knowledge. Don't laugh at my code or Dick Cheney will invite you along on his next hunting trip. :-P

The only uIP-related bug I know about is the web server timing out sending fade.png, which should show up as a usage bar on the file statistics page. UDP didn't work the last time it was compiled in, but I haven't looked at why yet. It's currently turned off as it's not required by the web server.

[Trev]

Posting here lets everyone be involved. :-)

Error 4 is S2ERR_BAD_STATE. Are either or both devices already configured and online when you run uIP? I'm not handling all possible cases in code. I should be handling a few more, of course, and I'll probably have to add checks for non-conformant errors, i.e. results that fall outside the SANA-II specification for a particular command.

I'll take a look at the devices and documentation for your interfaces tomorrow afternoon. On my way to Saratoga to see Suzanne Vega. . . .

Trev

[Trev]

@Hans_

lwIP has unproven IPv6 support. It's promising.

@Colani1200

Pooh. Could be anything at this point. Can I blame the startup code and the compiler? Seriously, I could be having issues with a so-so cross-compiler. The only native Amiga compiler I have is Storm C 3.0. Not the most user friendly and up to date.

Anyone have experience with the gcc package bundled with Cubic?

@hardlink

I'll be reading up as well. It's either the compiler or static libraries or something wrong with my SANA-II stuff (that's a lot of big or's).

Suzanne said not to worry--she'll borrow mine.

Trev

[Trev]

Having a copy of SAS/C would be nice. I, like many, have bugged SAS over the past few years, but they're not into selling or giving away discontinued software. (Fortunately, not all vendors are so bad. Compuware sent me a free copy of SoftICE for MS-DOS after I asked them nicely.)

Doesn't SAS/C have an __aligned keyword? That can replace the __attribute__ ((aligned (x))) modifiers. The SDL headers need to be updated to deal with alignment-related keywords. In any case, it's only there because I don't know how m68k-amigaos-gcc aligns static variables, and proper alignment is required (?) for fast copy functions. Better, perhaps, to make uip_buf a pointer and allocate the buffer at run time with AllocMem or AllocVec. The size of the buffer itself would still be configurable at compile time. One catch: keep in mind the 2 bytes of overhead reserved for the stack. That should make 1520 bytes (multiple of 16) a safe size for most purposes. For an application that doesn't require full size frames, a smaller buffer size can be used. You think?

You should be able to safely remove the register hint from the psock.c functions. A complete port, i.e. one that ties the protocol to the architecture (the opposite of what I'm attempting), would evaluate each function and use the calling convention appropriate for the desired performance to interoperability ratio. (At that point, you'd ditch protothreads on a mutlitasking operating system and use system-specific task/thread functionality.)

Trev

[Trev]

Changes:

buffers allocated at run-time with AllocVec
compiled with Cygwin-hosted vbcc

http://www.babacar.org/uip.lha

May make a difference on a stock A600 if startup code was a contributing factor. Obviously, things need to be written/instrumented to support debugging and logging on all platforms.

Will play some more tomorrow and this weekend.

Trev

[Trev]

That sounds normal up to a point. The first "reponse" should be an ARP request, so the sequence of events looks like this:

1. HOST -> ICMP -> A600 (static ARP entry)
2. A600 -> ARP -> BROADCAST (ff-ff-ff-ff-ff-ff)
3. HOST -> ARP -> A600
4. A600 -> ICMP -> HOST (may not occur)
5. HOST -> ICMP -> A600
6. A600 -> ICMP -> HOST
7. HOST -> ICMP -> A600
8. A600 -> ICMP -> HOST
9. ...

4 may not occur because of the order in which IP and ARP frames are processed. Needs to be fixed.

If you run a protocol analyzer (Microsoft Network Monitor, tcpdump, WireShark, etc.) on the remote host, you should see the ARP request leave the A600 as a broadcast and hit your local interface. If you don't, the frame never left the A600, and there's an issue with either the uIP send code or the SANA-II device.

The send code is pretty simple:

  ios2_send->ios2_Req.io_Command = CMD_WRITE;
  ios2_send->ios2_Req.io_Flags = SANA2IOF_RAW;
  ios2_send->ios2_DataLength = uip_len;
  ios2_send->ios2_Data = uip_buf;
  BeginIO((struct IORequest *)ios2_send);
  WaitIO((struct IORequest *)ios2_send);

Does uIP continue to receive data after the "sending..." message, or does it hang? Does it respond to CTRL+C? If it responds to CTRL+C, then SANA-II I/O is hung. If it doesn't repond to CTRL+C, then uIP (or the system itself, if nothing responds) is hung.

EDIT:

Have you tried both cnet and prism2 on the A600? Do both fail?

Also thinking that some SANA-II devices may require src and dest addresses and possibly even packet type (IP, ARP, etc.) to be populated in the request even though SANA2IOF_RAW is specified.

Trev

[Trev]

:-)

[Trev]

Thanks for testing it out. Are you using the latest cnet.device from http://www.g-mb.de/cnet/index_e.html? I'll take a look at the source code and see if there's something about CMD_WRITE that doesn't like SANA2IOF_RAW and broadcasts. Might have to use S2_BROADCAST instead. It could also be a compatibility issue between your card and the devicem but if it works with other stacks, probably not. Can you post a dump of the PCMCIA registers for the card? There's also an excellent support matrix at http://www.g-mb.de/pcmcia_e.html.

Trev

[Trev]

I've had a look at the cnet.device source, and I think the problem is a very poor assumption on my part regarding DMA transfers. On a stock A600, the only place for memory to be allocated is in chip memory, and AllocVec should have properly aligned it. cnet.device only supports DMA for writes (sends), which is probably why reads (receives) are still working. I've removed the S2_DMACopyToBuff32 and S2_DMACopyFromBuff32 tags from this build. The debug version of cnet.device (unfortunately, only distributed in binary form for 68020 and higer) would have sent something like "cnet: using DMA write from $nnnnnnnn!" followed by "cnet: txintcode: transmit DMA timeout!" to a debug console (or sashimi).

Updated: http://www.babacar.org/uip.lha

If at any point in time I start talking out of my ass, hopefully folks will continue to chime in and correct me. ;-)

Trev