uIP/lwIP for Amiga OS

[Colani1200]

Looks like we´re approaching an A600 compatible version!  :-)

The good news: uIP starts up on the A600, yay!
The bad news: I can´t ping it. Looks like it does not correctly use the MAC address of the host which is pinging. You can see the correct MAC of the host in the echo request ("received 102 bytes from ..."), but the reply seems faulty, it says "sending 42 bytes to: ff-ff-ff-ff-ff-ff", which obviously is not the correct MAC of the network card.

The new version works fine on the A1200, no such problem there. Any idea?

[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

[Al1905b]

Al's_A4k:System> tangleme

Quantum Entangler for Linux v0.99
Authors:  A. Einstein and N. Bohr
Beyond the Grave Software LLC

Ported to Amiga OS4 by R. Oppenheimer 2007

tangleme 0.99> new event (patchcable.color == BLUE) {format SDCARD_GRANDMA0: all }

Warning:  Relativistic time constraints active in freeware version.

Quantum Entanglement Complete!
Spooky action at a distance active.

Would you like another entanglement (y/n)?
tangleme 0.99> n

Thanks!

Al's_A4k:System> games:mspacman

[Trev]

:-)

[Colani1200]

OK, I'm back with more test results...

It looks like the problem is related to cnet.device (or my network card using it). I have to admit that I didn't try to ping the A1200 with cnet.device. After everything successfully worked with my WLAN card, I just checked if uIP also came up correctly with cnet.device -which was the case- and assumed the rest would work also. I didn't try any further because I had no network cable where my A1200 sits. No QA as it should be, I have to admit - shame on me...

Today, I network cabled the A1200 with cnet.device, fired up uIP, tried to ping it and voila: it has the same problem as the A600, it just keeps responding to ff-ff-ff-ff-ff-ff. :roll:

I can't check prism2.device on the A600, because it requires at least OS 3.0... Don't think I haven't tried it nevertheless... I usually don't trust READMEs :-D
But no luck, SetPrism2Defaults crashes the A600.

Trev wrote:

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.

It keeps receiving & responding, you can close it with CTRL+C, fire it up again, no problem. It just keeps replying to ff-ff-ff-ff-ff-ff... I can dump the traffic with tcpdump or something when I have time. Maybe some other user can check uIP with cnet.device in the meantime to verify if the problem is related to my card.

[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

[Colani1200]

Trev wrote:
Are you using the latest cnet.device from http://www.g-mb.de/cnet/index_e.html?

No, I had V1.9 beta1. I upgraded to 1.9 but it doesn't help.

Can you post a dump of the PCMCIA registers for the card?

How do I do that?

There's also an excellent support matrix at http://www.g-mb.de/pcmcia_e.html.

I know that matrix. I have a Fiberline FL-4680, I was the one who tested it with NetBSD  :-)

[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

[Trev]

Also, I received a small and simple patch for MorphOS support for anyone that wants to play with the currently posted source code. Thanks, Stefan!

uip.diff

Code: [Select]


--- m68k-amigaos/sana2dev.c Tue Nov 13 18:53:50 2007
+++ ppc-morphos/sana2dev.c Fri Nov 16 14:37:02 2007
@@ -33,7 +33,12 @@
 #include <SDI_compiler.h>
 #include <clib/alib_protos.h>
 #include <clib/exec_protos.h>
+#ifdef __MORPHOS__
+#include <devices/sana2.h>
+#include <emul/emulregs.h>
+#else
 #include <devices/sana2r4.h>
+#endif
 
 #include <stdlib.h>


Makefile

Code: [Select]


all: uip

CC     = gcc
AR     = ar
APPS   = webserver
CFLAGS = -Wall -O2 -fpack-struct -s -noixemul -I../uip -I.
-include ../uip/Makefile.include

$(OBJECTDIR):
mkdir $(OBJECTDIR)

uip: $(addprefix $(OBJECTDIR)/, main.o sana2dev.o clock-arch.o) apps.a uip.a

clean:
rm -fr *.o *~ *core uip $(OBJECTDIR) *.a


Speaking of ports, the next time I upload source code, I'll make sure vbcc build instructions/scripts/makefiles/whatever are included for at least m68k-amigaos and ppc-morphos.

Trev

[Colani1200]

Great job, it works!!! I tried both A1200 and A600, everything fine.

So what's next? Will we see a version that accepts , and as parameters? I've been wanting to have an A600 webserver sitting somewhere in the corner for a long time...  :-D

[Trev]

I'd like to see DMA working properly, but I think the number of devices (software, not hardware) that actually support anything other than 8-bit transfers is limited. Options are 8-bit, 16-bit, and 32-bit bufferred and 32-bit DMA. Reducing the number of copies would certainly improve performance. Memory tricks in the copy callbacks would be dependent on knowledge of how the SANA-II device allocates memory, and that's why there are multiple tags.

As far as configuration goes, I think supporting all three options--static, DHCP (and maybe BOOTP), and ping-assigned--is a good way to go. uIP is meant to be embedded, so command-line options are probably a better choice than a configuration file. That should let multiple uIP applications coexist nicely, assuming the SANA-II device behaves properly. I'm still liking the idea of uIP in ROM or flash, but we'd need a SANA-II device that fits in with that scheme as well. Devices that completely autoconfigure and don't rely on features not availabe at startup should work. You think?

lwIP also supports link-local auto-configuration, which is a great feature for small networks. Even without auto-configuration, other link-local features, including .local name resolution, are pretty cool and fit in nicely with the spirit of the Amiga.

EDIT:

Jens warned against using the RR-Net on an Amiga, but with enough hacking, I'm sure a clock-port-enabled A500 could be up and running, too. Are there other ethernet options for the A500? ... Looks like there were a few sidecar-style adapters made, but that's no fun. And I guess parallel adapters are out. Serial-to-ethernet is an option, but those devices tend to be microprocessors and firmware that do all the IP work for you and wrap RS-232 or other standards. But with a little creative bridging....

Trev

[Trev]

@Hans_

uIP has IPv6, too, but I haven't tested it.

@all

New version. Back to a simple event loop to aid in troubleshooting applications as opposed to my own bumbling.

Instead of ping-based configuration, this version supports both DHCP (unlike my version of Genesis) and static addresses. It should be possible to keep ping-based configuration around as a backup to DHCP, but I'm not sure that's necessary when static configuration is an option.

I've also added more Amiga-like command-line options via ReadArgs(). Here's a quick summary:

/*
 * Command-line options.
 *
 * Default: DEVICE Devs:Networks/openpci_8139.device UNIT 0 CONFIG DYNAMIC
 *
 * DEVICE
 *   Fully-qualified path to device to open.
 *
 *   Example: DEVICE Devs:Networks/openpci_8139.device
 *
 * UNIT
 *   Unit number to open.
 *
 *   Example: UNIT 0
 *
 * CONFIG
 *   IP address configuration. Valid values are DYNAMIC and STATIC. If
 *   STATIC, the ADDR, MASK, and DEST options are required.
 *
 *   Example: CONFIG DYNAMIC
 *   Example: CONFIG STATIC
 *
 * ADDR
 *   IP address.
 *
 *   Example: ADDR 192.168.0.100
 *
 * MASK
 *   IP subnet mask.
 *
 *   Example: MASK 255.255.255.0
 *
 * DEST
 *   IP default gateway.
 *
 *   Example: DEST 192.168.0.1
 */

So, to configure cnet device 0 using DHCP, you can run any of the following commands:

uip device Devs:Networks/cnet.device unit 0 config dynamic
uip device Devs:Networks/cnet.device unit 0
uip device Devs:Networks/cnet.device

Similarly, for static address assignment, you can run something like the following command:

uip device Devs:Networks/cnet.device config static addr 192.168.0.23 mask 255.255.255.0 dest 192.168.0.1

Note that if you specify 'config static', the addr, mask, and dest options are required.

There's a note in the 3.5 autodocs about ReadArgs() expecting newline characters after strings passed as defaults in the option array. I haven't done that, so if using the defaults fails on EXEC <= V37, try using a complete command-line. Anyone have details on this one?

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

So, now we need to come up with some creative uses for uIP--something better than a silly test web server. A general purpose web server would be fun. One that uses the file system instead of pre-compiled files. And performance can be improved. (The port I did for MS-DOS packet drivers performs quite well.) The stack isn't sending full-sized packets, so there's probably a simple buffer issue to overcome.

As I've said before, bsdsocket.library support would be very cool, but I'd rather do that on lwIP.

Trev

[Colani1200]

Wow, that was quick. I'll test the new version tonight (I hope).

Trev wrote:
So, now we need to come up with some creative uses for uIP--something better than a silly test web server. A general purpose web server would be fun. One that uses the file system instead of pre-compiled files.

That would be great. Maybe the web server option could also be togglable?!

I'm still liking the idea of uIP in ROM or flash, but we'd need a SANA-II device that fits in with that scheme as well.

When you say "ROM" you mean Kickstart?! Sounds like a nice experiment. Might also be an option for the Minimig... But for most people (i.e. the classic users), a software solution will be just fine. I'm thinking of a command-line uIP as a tiny "all-in-one" solution and maybe lwIP as a full featured stack with config files that maybe later can be GUI manipulated...

with enough hacking, I'm sure a clock-port-enabled A500 could be up and running, too. Are there other ethernet options for the A500? ... Looks like there were a few sidecar-style adapters made, but that's no fun. And I guess parallel adapters are out. Serial-to-ethernet is an option, but those devices tend to be microprocessors and firmware that do all the IP work for you and wrap RS-232 or other standards. But with a little creative bridging....

Having all those questions of people in mind that are looking for a way to transfer their ADFs, an A500 version might be useful aswell. I have no idea which hardware could be used though (are there many A500 with clockport out there?)

[Trev]

Maybe the web server option could also be togglable?!

It could be, but it's the applications that make it useful. I suppose a swiss army knife style bundle of server-based apps would be cool. A stand-alone port of wget sounds interesting, as does a stand-alone SNTP/NTP client. Think WATTCP for Amiga (only not WATTCP, which would have been an interesting port, too).

When you say "ROM" you mean Kickstart?!

That's what I was thinking, for remote boot options.

I'll put some work into optimizing performance first. I could add an option for multiple simultaneous receive requests, but dropped packets don't appear to be a problem yet. (That's dependent in part on how frames are bufferred in the hardware itself.)

Sends are controlled by the event loop, so there isn't really a need for multiple send requests; however, performance could be improved by spawning a request management task that does nothing but wait for IO completion and put requests back into the queue. That would remove the requirement for a WaitIO() call in the send routine.

I'll be replacing the default checksum routines with 680x0 optimized ones as well.

Trev

[Colani1200]

Tried the new version, what I can tell you already that it works on my A1200 with prism2.device.  :-)  Didn't try the A600 and cnet.device yet.

Trev wrote:

It could be, but it's the applications that make it useful.

I was hoping to be able 3rd party apps like ncftp, but that doesn't work (I assume that's the missing bsdsocket.library support you were talking about?). You said that you'd rather implement that in lwIP. What footprint does it have compared to uIP? Will it still work on lo-spec AMIGAs?

I'll put some work into optimizing performance first.

Hm... yeah, I noticed that my A1200 with 030/50 slows down to an almost unusable state when I run uIP.

I could add an option for multiple simultaneous receive requests, but dropped packets don't appear to be a problem yet.

I didn't test that long, but no dropped packets appeared in the stats.

[hardlink]

Trev wrote:
compiled with Cygwin-hosted vbcc
Trev

What did your Makefile for vbcc look like?