uIP/lwIP for Amiga OS

[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.

[Crumb]

Although ArosTCP/MosNet are probably slower it may be interesting to take a look at it. It's opensource and quite updated. It's used by AROS/MorphOS (with slight changes)

[hardlink]

Unfortunately, I did not have much luck. Here is the cli capture, on a A4000T/060/OS3.9, for both an Ariadne II and an ethernet module on a ioblix card:


4.Ram Disk:New> uip Devs:Networks/ioblixether.device 0
uIP 0.1.0
uIP log message: Initializing...
uIP log message: failed to bring device online
4.Ram Disk:New> version Devs:Networks/ioblixether.device
ioblixether.device 37.14

4.Ram Disk:New> uip Devs:Networks/ariadne_ii.device 0
uIP 0.1.0
uIP log message: Initializing...
uIP log message: failed to configure device
4.Ram Disk:New> version Devs:Networks/ariadne_ii.device
ariadne_ii.device 43.12

[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.

[hardlink]

Trev wrote:

Eek. I don't have either of those devices...

Yes, I thought it might be helpful:) to try it with some more obscure hw (ioblix).

I cannot get the exact capture till tomarrow, but this build returned a SANA 0004(?) error for both.

I'll send you my email tomarrow using the message facility to avoid rather dull postings  :-)

[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

[Hans_]

I've had a look at these tiny TCP/IP stacks before for use on small microcontrollers (with very limited memory). One thing that I'm wondering, are there any small TCP/IP stacks with IPv6 support that are open-source?

Hans

[Colani1200]

Trev wrote:

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

Still no luck on the A600. Unfortunately, no error message / debug output whatsoever, it simply crashes.

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.

68000 with 1MB, exec.library is V37.151.

[hardlink]

Trev wrote:
Posting here lets everyone be involved. :-)

Error 4 is S2ERR_BAD_STATE ...

...On my way to Saratoga to see Suzanne Vega. . . .
Trev

Cool; good luck, and tell Suzanne I found her other sock.


About uip, immediately after a power cycle cold boot:
 
4.Work:uip> uip Devs:Networks/ioblixether.device 0
uIP: initializing...
uIP: failed to bring SANA-II device online: error 00000004
4.Work:uip>

4.Work:uip> uip Devs:Networks/ariadne_ii.device 0
uIP: initializing...
uIP: failed to bring SANA-II device online: error 00000004
4.Work:uip>


then after using OS3.9 included Genesis stack to bring ioblix on-line:

4.Work:uip> uip Devs:Networks/ioblixether.device 0
uIP: initializing...
uIP: failed to bring SANA-II device online: error 00000004
4.Work:uip>

After running uip, the message in the Genisys status window:
"blitz has been put offline"



Now trying ariadne, after quitting then re-starting Genesis, then bringing ariadne on-line:

uip Devs:Networks/ariadne_ii.device 0
uIP: initializing...
uIP: failed to bring SANA-II device online: error 00000004
 
After running uip, the message in the Genisis status window:
"ariadne has been put offline"


Looks like I have to dig up my SANA docs, or go visit Dale Larson with some 'friends' from New York ...

[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

[Hans_]

Trev wrote:
@Hans_

lwIP has unproven IPv6 support. It's promising.

Great! By the time I get round to working on the (non Amiga related) project I need it for, it should be "proven". I thought that IwIP didn't have it because I saw no mention on their website.

Hans

[hardlink]

Trev wrote:
Pooh. Could be anything at this point. Can I blame the startup code and the compiler?
Trev

I'm trying to compile it with SAS C 6.58, and having the usual fun. The makefile would not work with the 2 use-gcc-makefiles-with-sasc tools on Aminet, so I got mkmk from there. It generated an unusable smakefile with dashes in macro names, hand edited those. SAS C has no __attribute__ magic, had to add a macro to ignore those. Looks like there are some calls with register attributes on the parameters SAS C doesn't like. And there is some current state structure that SAS doesn't think is defined.

I need coffee.

[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

[Colani1200]

Thanks for your effort. I'll try the recompiled version this weekend and tell you how it works.

[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?