Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Trev on November 09, 2007, 04:29:18 AM
-
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 (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 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...
-
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?
-
@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
-
What a nice little server :-o
(http://chain.3dgrafika.cz/temp/uIP.GIF)
tested on:
A4000/060, os 3.9, hydra.device
-
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.
-
@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
-
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?
-
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.
-
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).
-
@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
-
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?
-
@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
-
@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 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.
-
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)
-
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
-
@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.lha)
http://www.babacar.org/uip-src.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 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 :-)
-
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
-
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
-
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.
-
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 ...
-
@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 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
-
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.
-
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
-
Changes:
buffers allocated at run-time with AllocVec
compiled with Cygwin-hosted vbcc
http://www.babacar.org/uip.lha (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
-
Thanks for your effort. I'll try the recompiled version this weekend and tell you how it works.
-
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?
-
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
-
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
-
:-)
-
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.
-
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 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 :-)
-
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
-
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
--- 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
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
-
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
-
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
-
@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
-
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?)
-
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
-
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.
-
Trev wrote:
compiled with Cygwin-hosted vbcc
Trev
What did your Makefile for vbcc look like?
-
I'm using a batch file and a custom vc.config file at the moment. The next source release will include gcc and vbcc makefles and a sample vc.config file for the vbcc vc front end. Really, it should compile with the default vbcc target packages. That shouldn't be difficult to do, assuming vbcc is installed on the host system per the vbcc documentation.
I'm no longer using gcc as there's no current support for the m68k-amigaos port. Everyone (including me) bases their packages on years old Geek Gadgets patches, and the results for building cross-compilers tend to vary. It's too bad Hyperion isn't keeping the OS3 compiler stuff up to date as they continue work on OS4. I don't have the compiler kung fu to do it myself.
Trev
-
@hardlink
Here's a Makefile that works for vbcc:
.PHONY: all clean
all: uip
CC = vc
APPS = dhcpc webserver
CFLAGS = -I../uip -I. -lamiga
-include ../uip/Makefile.include
uip: $(addprefix $(OBJECTDIR)/, main.o sana2dev.o clock-arch.o $(APP_SOURCES:.c=.o) $(UIP_SOURCES:.c=.o))
$(CC) $(CFLAGS) $^ -o $@
clean:
rm -fr *.o *~ *core uip $(OBJECTDIR) *.a
The default target is determined by your vc.config file. I'll expand the makefile later to allow target selection when building using the default vc config file names, e.g. aos68k. The config files need to be modified appropriately for your host (environment variables, OS include paths, etc.).
You'll also need to modify Makefile.dhcp in uip-1.0/apps/dhcpc to kill the vlink errors:
APP_SOURCES += dhcpc.c
timer.c is compiled as part of the main uip source.
Trev
-
Trev wrote:
Here's a Makefile that works for vbcc:
Trev
Thanks!
I gave it a try, but...
Using vbcc makefile:
7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make uip
make: *** No rule to make target `/main.o', needed by `uip'. Stop.
7.Work:uip/uip-1.0.vbcc/m68k-amigaos>
Okay, I'll give ya a rule, how about this added to Makefile:
main.o: main.c
$(CC) $(CFLAGS) main.c
7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
vbcc V0.8j (c) in 1995-2006 by Volker Barthelmann
vbcc code-generator for m68k/ColdFire V1.6a (c) in 1995-2005 by Volker Barth
elmann
>#include "webserver.h"
error 248 in line 156 of "uip-conf.h": file 'webserver.h' not found
1 error found!
vbccm68k failed returncode 20
vbccm68k "main.c" -o= "T:t_8_0.asm" -I../uip -I. -O=1 -Ivincludeos3: faile
d
vc failed returncode 20
make: *** [main.o] Error 20
7.Work:uip/uip-1.0.vbcc/m68k-amigaos>
Okay, who needs a webserver?
-comment out #include "webserver.h" in uip-conf.h;
7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
>extern u8_t uip_buf[UIP_BUFSIZE+2+15] __attribute__
warning 54 in line 423 of "uip.h": ; expected
>extern u8_t uip_buf[UIP_BUFSIZE+2+15] __attribute__ ((
error 20 in line 423 of "uip.h": no declarator and no identifier in prototyp
e
Okay, added "#define __attribute__(x) /*NOTHING*/" in uip.h;
7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
> uip_tcp_appstate_t
warning 56 in line 1185 of "uip.h": } expected
> uip_tcp_appstate_t appstate;
warning 54 in line 1185 of "uip.h": ; expected
> uip_tcp_appstate_t appstate;
warning 125 in line 1185 of "uip.h": no declaration-specifier, used int
>}
Okay, 'uip_tcp_appstate_t' only defined in 'hello-world.h' !?!
-referred to in comments in 'uipopt.h'
Any ideas?
-
It sounds like your version of make doesn't support the -include option. The missing rules are defined ../uip/Makefile.include, ../app/dhcpc/Makefile.include, and ../app/webserver/Makefile.include. The APPS variable tells ../uip/Makefile.include to include each of the application-specific makefiles. Are you using GNU make? If so, which version? If not, you'll have to sort out the makefile options and commands and build one large makefile. Shouldn't be difficult.
Your includes should be (in addition to the OS stuff in vc.config):
-I../uip -I. -I../uip/apps/webserver
Compile and link the following modules:
main.c sana2dev.c clock-arch.c ../uip/uip.c ../uip/uip_arp.c ../uip/uiplib.c ../uip/psock.c ../uip/timer.c ../uip/uip-neighbor.c ../apps/webserver/httpd.c ../apps/webserver/http-strings.c ../apps/webserver/httpd-fs.c ../apps/webserver/httpd-cgi.c
Link with amiga.lib, e.g. -lamiga. It shouldn't work with the minimum startup code, so you're vc.config will need to use the biggy. That's something that needs to be changed to minimize executable size and memory usage. I just couldn't be bother to do all the library management myself when I got started. :-)
The application doesn't do much without the web server. ;-)
I ditched the __attribute__ stuff and switched to an external (defined in sana2dev.c) uip_buf allocated by AllocVec.
uip_tcp_appstate_t should be typedef'd by all the TCP applications in ../apps. (Changing how that works is one of the challenges of making uIP more general purpose, i.e. to allow more than one application. If a bsdsocket.library emulation layer was the application. . . .)
I'll upload some new source code tonight. It should build correctly assuming your version of make likes the makefiles.
Trev
-
Trev wrote:
It sounds like your version of make doesn't support the -include option.
Trev
I tried to find the latest version of GNU make on Aminet, and used that; it is version 3.76.1; I'll keep looking.
I also contacted a friend who uses Cubic IDE to ask for assistance, so that may work; I believe Cubic uses the latest GNU tools:
http://developers.xoomwebs.com/
-
You can download the Cubic IDE compiler package separately. Pretty sure it's stuck in the same Geek Gadgets quagmire as the rest of the community. And up to date port of make would be nice. Apart from that, Cubic IDE (and GoldED in general) is pretty cool.
There's a copy of make 3.81b1 on http://amiga.sourceforge.net, but I haven't used it.
Try changng '-include' to just 'include'. The '-' ignores errors. Perhaps that feature wasn't available in 3.76.1? I don't know enough about make's history to say.
For the curious, I use Visual Studio as my IDE/editor (currently Visual C++ 2008 Express Edition), a makefile project, and Cygwin (as note before) to host the compiler (and make and anything else I might need). I move stuff back and forth between the PC and the Amiga using floppies. (My house is littered with Catweasels, but I'm using FAT floppies at the moment.) I was using Amiga Explorer, but the latest version has some shell extension-related oddities--and it's a pain opening it up and shutting it down on the Amiga side to test the changes to uIP. Floppies are faster.
I tried AmiDevCpp, but the IDE isn't a well-behaved Windows application. Plus, it wouldn't save the option to override the default makefile. And as we saw earlier, there were issues with either the cross-compiler or the startup code. I want to play with uIP and lwIP and not compilers and IDEs, so I switched to vbcc. :-P
Trev
-
Trev wrote:
I move stuff back and forth between the PC and the Amiga using floppies.
Time for a good TCP/IP stack, huh? :lol:
-
A600 and cnet.device works fine, but quite a few dropped packets...
-
I was curious, as I selected uIP for a microcontroller project some weeks ago, but didn't start adjusting the code yet.
A4000 + HIGHWAY + NORWAY works also. But: I need to go online with Miami once (and offline again) to get uIP opening the norway.device successfully.
Could be a problem with device initialisation?
uIP seems to be a tick slower than Miami for pings.
How can I add DNS entries?
Anyhow, nice effort from you! Go ahead, it's a promising start.
Michael
-
@mboehmer_e3b
I certainly do seem to have some issues with device configuration and initialization on a number of different interfaces. I've been out of town for a few days but will be fixing broken things and adding new things tonight and tomorrow.
I believe the slowness in ICMP echo replies is caused by the structure of uIP's event loop and uIP's default checksum calculations. I'll be adding M680x0 optimized checksum routines tomorrow.
I haven't compiled in the DNS resolver, as from the current demo's perspective, it wouldn't be very useful. Is that what you meant? On the remote host (not the Amiga running uIP), adding DNS or hosts entries is system-dependent.
@Colani1200
Dropped packets are probably not a good thing. I'll look into it. I'm going to solve the 100% CPU usage issue as well by moving back to signals and waits; however, they'll work properly this time (they were the cause of dropped packets in the past).
I'll also be bringing the maximum packet size back down to 576 bytes as path MTU discovery hasn't been implemented. This will make the stack more interopable, but if/when SLIP (probable) or PPP (not so probable) support is added, I'll need to look at the impact of the MTU size in general.
Trev
-
Updates:
The first response to any request (ICMP/TCP/UDP) was dropped in leu of an ARP request if the ARP cache did not contain a mapping for the destination host. This has been resolved [1] by enabling uIP to update the ARP cache whenever a request is received.
1. This may not be the desired behavior (the source hardware address for an IP may not be the same as the destination hardware address for the same IP, i.e. routers, hosts with multiple interfaces, hosts that do transmit load-balancing across a virtual interface, etc.), so I should probably make this an option. If disabled, it would be up to the requesting application to retransmit (TCP) or ignore (ICMP echo and UDP) the unacknowledged or dropped packet, respectively. For now, it's enabled.
More to come....
-
Trev wrote:
Dropped packets are probably not a good thing. I'll look into it.
This appears to be a problem of slower systems (A600). On the 1200 with 030, there were no dropped packets.
-
If the A600 is taking longer than 1 second (de facto standard delay between requests) to respond to an ICMP echo request, then yes, something will get dropped. I'll need to look at the counter implementation and see what gets ticked as dropped and what gets discarded, i.e. packets that weren't meant for the active uIP process but made it past the link layer.
-
Thinking out load, it would be nice to have a checksum off-loading device in the Amiga. I see possibilities. It may be possible to use the blitter on slower systems, but I think the CPU will be faster on even slightly upgraded systems. (Thoughts?) 3D chipsets, e.g. Voodoo 3, and advanced processors, e.g. 68060, might be used for vector and superscalar operations.
Anyhow, an optimized checksum routine should suffice. Benchmarks to come over the next few days.
-
Trev wrote:
If the A600 is taking longer than 1 second (de facto standard delay between requests) to respond to an ICMP echo request, then yes, something will get dropped.
I didn't test that with ICMP, but browsed the web pages and the dropped packets were increasing quite quickly.
-
I do know that with a single receive buffer, the stack doesn't process incoming requests quickly enough. For example, Internet Explorer ACKs the connection and sends the first HTTP GET in less than a microsecond. uIP hasn't yet processed the pending I/O request for the ACK and so never receives the first HTTP GET.
Using more buffers uses more memory, of course, so we're down to a memory/performance trade-off. The number of I/O requests to queue will be an option soon.
Trev
-
Multiple receive buffers have been implemented and a command-line option (BUFFERS) has been added. The minimum number of buffers is two--one for IP and one for ARP. Currently, the first buffer is reserved for ARP and the rest are used for IP. Each buffer consumes ~600 additional bytes of memory. Three or more buffers provide a decent level of interactivity.
The device I'm using (openpci_8139.device) sends "orphaned" frames to all pending S2_READORPHAN requests. I'm not sure if all devices do that, but I suppose it makes sense. Device driver authors have no way to determine the intent of a task or process when it queues multiple S2_READORPHAN requests. Anyhow, I was receiving multiple copies of frames after implementing mulitple receive requests. That lead to the split between ARP and IP requests. Reads and writes are still raw (the entire frame minus the ethernet trailer is copied to the buffer), but reads will only catch ARP and IP frame types.
EDIT: You know, a device also has no way of knowing how a process or task is going to use multiple ARP or IP requests. As devices are required to service requests for all callers as of S2R3, device driver authors would have to make a conscious decision to send one frame per CMD_READ request once per task or process and not the same frame across multiple CMD_READ requets. Not sure why the same decision wasn't made for S2_READORPHAN requests. More digging to do, I guess.
The PNG image in files.shtml failed to transmit because of a bug in the Perl script that converts content into C. The script was using read(), which wraps stdio. On Windows, CRLF sequences are converted to LF. Not a good thing for binary files. Replaced read() with sysread() to fix that.
Still have checksums to implement. I also have a few ideas about why certain devices aren't initialized properly.
-
A 680x0 specific checksum routine has been shamelessly stolen from RTEMS (uses a BSD stack) and modified for vbcc. Oh, the joys of open source software. Cycle-wise, it's about 250% faster than uIP's default routine (but only a pinch faster than the BSD optimized C routine). Being BSD-derived, the routines are very similar to AmiTCP's. I'm steering clear of AmiTCP code, however, since it's GPL. I'd rather stick with a BSD-style license that doesn't place any restrictions on use or distribution (short of copyright notices).
Toni Wilen has added a SANA-II device (uaenet.device) to the latest builds of WinUAE. Very cool, but it currently requires TAP-Win32. I'd rather see an implementation that doesn't require a bridged virtual network adapter. Microsoft Virtual PC does it (of course), and so does nmap. Regardless, cheers to Toni for all the hard work.
Still confused as to why some adapters configure and go online and some don't. For those that go online after being configured by another stack, e.g. Miami, the problem is obviously with my initialization code.
If anyone wants to take a stab at using sanautil (available on Aminet) to configure and bring a card online, please let me know the results. I'm particularly intersted in the output of "sanautil device status" before and after the card is configured and before and after the card is brought online.
Here's the compatibility list as it stands today:
ariadne_ii.device,43.12,no
cnet.device,1.9,yes
hydra.device,?,yes
ioblixether.device,37.14,no
norway.device,?,yes*
openpci_8139.device,1.2b4,yes
prism2.device,?,yes
uaenet.device,1.0 (1.4.5b13),yes**
* after configuration by separate stack
** acquires DHCP address; hangs on first ICMP echo reply
Trev
-
My checksum routine wasn't working 100% of the time, so I had to put together a nice set of test cases. Anyhow, it should be good to go now. Here's the current set of command-line options:
/*
* 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
*
* BUFFERS
* Number of buffers to allocate.
*
* Example: BUFFERS 10
*
* 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. Required if CONFIG STATIC is specified.
*
* Example: ADDR 192.168.0.100
*
* MASK
* IP subnet mask. Required if CONFIG STATIC is specified.
*
* Example: MASK 255.255.255.0
*
* DEST
* IP default gateway. Required if CONFIG STATIC is specified.
*
* Example: DEST 192.168.0.1
*/
And a link to the latest revision:
http://www.spookysoftware.com/uip.lha (http://www.spookysoftware.com/uip.lha)
I still expect folks to have problems configuring and bringing online certain adapters. If anyone gets a chance to run sanautil as requested above or knows the ins and outs of configuration for a particular device, please let me know.
Apart from that, this revision should be more responsive--both uIP and the OS itself--than the last. I'm interested in ping response times for various Amiga configurations using a full-sized frame, e.g. ping -l 572 n.n.n.n.
For best performance, use three or more buffers (the minimum is two). After that, it's a memory/performance tradeoff. There's also a point where increasing the buffers won't help, as uIP only processes pending outbound frames twice per second (configurable in code). That's why the shtml pages are so slow--the data is sent periodically.
EDIT: Oops. Forgot to put a buffer size check back in. Binary updated. Note, the URL has changed.
Trev
-
Another little revision. I modified the DHCP client to randomize the transaction ID field per process and use the client indentifier option. Assuming your ethernet device supports it, this should allow you to run multiple instances of uIP on the same interface and still allow use of DHCP.
This would be required, for example, if you wanted to embed uIP in multiple applications and run them simultaneously. Each application would have its own IP address. This won't work if your device only sends an incoming IP packet to the next pending IO request. If it sends the packet to the next pending IO request per process, then you're good to go.
Caveat: I haven't implemented DHCPRELEASE, so keep an eye on your DHCP scope(s).
http://www.spookysoftware.com/uip.lha
EDIT: Also, Toni has switched from TAP-Win32 to WinPCAP for the new uaenet.device. Looks even more promising now, although there are some new issues to resolve. We all know it, but WinUAE is one awesome piece of software. Everyone involved in UAE's development over the last 13 years (has it really been that long? yikes) really deserves our gratitude.
Trev
-
Trev wrote:
Apart from that, this revision should be more responsive--both uIP and the OS itself--than the last. I'm interested in ping response times for various Amiga configurations using a full-sized frame, e.g. ping -l 572 n.n.n.n.
Ping times are usually between 55-60 ms on my A1200 030/50 with prism2.device (buffers 10). I noticed some strange behavior though: The first pings (looks like the number is related to the buffers?!) seem to be fired very fast. After that, they happen in the usual 1 second interval. When I ping for the first time, I also get a whole bunch of "ping: sendto: Host is down" messages before it actually starts working. The OS indeed seems to retain its normal responsiveness when uIP is running in the background, so that's a great improvement.
However, I have a problem with uIP on the A600. It won't start up. When I try to run it, I get back my shell prompt immediately without anything happening.
-
prism2.device shouldn't be replying to more than one request per packet. If it is, it's yet another inconsistency in the way folks develop SANA-II device drivers. (This is why companies like Apple and Microsoft provide test cases, test tools, code verification tools, and code validation services. Alas, Amiga has gone to a "better place," so we get what we get.)
Are you pinging from Amiga to Amiga? Most newer implementations of ping (the non-Microsoft ones) send a single request and display " is alive" or something similar. Microsoft sends four requests on a non-configurable interval of 1 second. The only ICMP-related message you'll receive from uIP at the moment is "icmp: not icmp echo." if an ICMP packet with a type other than echo request is received. Anyhow, which ping are you using?
Combining those previous two paragraphs, we may be able to infer that uIP is reponding nine times (BUFFERS - 1) to the first echo request (thanks to prism2.device?), and for whatever reason--probably queueing of the responses by the underlying stack--your ping client interprets those replies as bad responses (wrong sequence number) to the next eight requests. Just guessing, don't know for sure. If that's the case, I'd say the client side is broken, as it should just discard those extra packets. Regardless, we'll sort it out. Try BUFFERS 2 (the old behavior) and let me know if it still happens.
I started linking with vbcc's auto library during testing. That's probably what's preventing the application from starting on OS 2.1. I'll pull it out, as I'm not using it at the moment. I should probably start loading libraries by hand, but it's nice when the compiler and libraries do it for you. :-)
Now that WinUAE supports a SANA device, I can start testing on various combinations of Kickstart and Workbench.
Trev
-
Toni mentioned that Genesis calls S2_ONLINE before calling S2_CONFIGINTERFACE. That got me thinking once again about how device driver developers interpret the SANA-II specification. Some drivers may initialize their hardware in S2_ONLINE and some may initialize their hardware in S2_CONFIGINTERFACE. e.g.:
weird.device:
1. S2_ONLINE
2. S2_CONFIGINTERFACE
3. S2_ONLINE (?)
sane.device
1. S2_CONFIGINTERFACE
2. S2_ONLINE
This sticky point is brought to light in Sana2Device.doc/S2_ONLINE:
This command is responsible for putting the network interface hardware back into a known state (as close as possible to the state before S2_OFFLINE) and resets the unit global and special statistics.
and S2_OFFLINE:
While the interface is offline, all read, writes and any other command that touches interface hardware will be rejected with ios2_Error set to S2ERR_OUTOFSERVICE
If you interpret S2_CONFIGINTERFACE as "any other command," that would explain the problems with uIP failing to configure and bring online certain devices. I follow the semantics as described for the sane device.
Thoughts? norway.device appears to be of the weird variety, and I should have some more information on that device in particular soon.
EDIT: I should be able to just check the S2_CONFIGINTEFACE result for an S2ERR_OUTOFSERVICE value, and call S2_ONLINE if necessary. Hmmm. But that may break other devices. Maybe this should be a command-line switch? I'll call it WEIRD and leave it off by default.
Trev
-
I didn't add a WEIRD option, but I did add an extra little bit of logic to try S2_ONLINE if S2_CONFIGINTERFACE fails with S2ERR_OUTOFSERVICE or S2ERR_BAD_STATE.
If you had problems with uIP configuring or bringing a device online, please try it out and let me know what happens:
http://www.spookysoftware.com/uip.lha
This could make ariadne_ii.device, ioblixether.device, and norway.device work properly. Latest compatibility notes:
DEVICE VERSION WORKS
ariadne_ii.device 43.12 no
cnet.device 1.9 yes
fastethernet.device yes
hydra.device yes
ioblixether.device 37.14 no
norway.device yes [1]
openpci_8139.device 1.2b4 yes
prism2.device yes
uaenet.device 1.4.5.b14 yes [2]
1. Must be configured by Miami first.
2. Does not see broadcasts from host environment (Windows).
If results still aren't consistent, we can sort out the per-device requirements with sanautil (or I can write a little test application) and perhaps put together a little compatiblity file (uip.compat or something) that tells the init routine how to configure a particular device based on name and perhaps version.
@Colani1200
I also removed the link to auto. Give it a try.
Trev
-
DEVICE VERSION WORKS
norway.device 1.8 (25.05.03) yes
The new version works nicely with norway.device. No other config is needed anymore, I just start the uip and everything works fine.
DHCP is also working nicely with my router here.
BTW, you don't look as default into devs:network/ for the device files?
No speed tests done yet, but IBrowse (demo version) complains on not finding a "bsdsocket.library or compatible networking interface".
Anyhow, as this little bug is fixed now I'm quite confident for the future.
Thanks for your efforts! Go ahead with this amazing little stack :-)
Michael
-
No speed tests done yet, but IBrowse (demo version) complains on not finding a "bsdsocket.library or compatible networking interface".
Uhm, this thing doesn't implement bsdsocket.library (it's a linklib tcp/ip stack), so that is no bug.
-
Trev wrote:
Anyhow, which ping are you using?
I was pinging from FreeBSD 6.2, I suppose the client side is pretty healthy ;-)
Try BUFFERS 2 (the old behavior) and let me know if it still happens.
I'll do so, just a little patience...
I started linking with vbcc's auto library during testing. That's probably what's preventing the application from starting on OS 2.1. I'll pull it out, as I'm not using it at the moment.
Maybe the arguments are not read correctly on the 600? I double checked them, so I am quite sure that there was no typo, but uIP quits without feedback when your arguments are incorrect, so you never know... Maybe you can build in some context help?
EDIT: Didn' check your latest version on the 600 yet, I hope I can try it tonight...
-
@mboehmer_e3b
Awesome. We'll call that done. Hopefully, the workaround will fix other non-working devices as well.
You are correct. I don't search devs:networks/ or devs: for the device driver. I suppose I should add that, but it means some calls to string mangling code in the uIP driver. Extra fluff ;-) like that will hurt the stack size-wise when I start optimizing.
@Piru
Not yet, anyway. ;-) Although I'd rather turn lwIP into a bsdsocket.library implementation. It's possible with both, though.
@Colani1200
I have a feeling the problem is the device, but you never know. I'll look at the prism2 code. If there's something I'm doing incorrectly for that device, I'll need to implement a fix in a way that doesn't break other devices.
The new build dumps "required argument missing" when you pass a bad command-line. The CLI is probably the most unuserfriendly part of Amiga OS.
When auto fails to load a required library, it exits without an error message. The startup code should do the same if it fails to load dos.library. Per the vbcc documentation, they don't check for minimum versions unless you specifically ask them to with variable overrides in code. Need to double-check that. It would be nice to have the link library and startup source. :-(
Trev
-
Trev wrote:
I have a feeling the problem is the device, but you never know. I'll look at the prism2 code. If there's something I'm doing incorrectly for that device, I'll need to implement a fix in a way that doesn't break other devices.
I suggest you don't investigate on this any further at the moment. The problem somehow seems to be also related to my network. I have the same effect when I ping other hosts with -l 572.
Good news: The latest version runs on the A600 again :-) I have ping times of ~120 ms with cnet.device. But buffer settings don't seem to have much effect and dropped packets are still there. Maybe you want to have a look at it yourself? You can reach my A600 here: [EDIT: Link removed, offline now]
-
:-) Are you behind a firewall and using port mapping and packet forwarding for HTTP? This shouldn't be working:
Pinging wanda25.dyndns.org [82.207.247.250] with 1464 bytes of data:
Reply from 82.207.247.250: bytes=1464 time=228ms TTL=53
Reply from 82.207.247.250: bytes=1464 time=225ms TTL=53
Reply from 82.207.247.250: bytes=1464 time=221ms TTL=53
Reply from 82.207.247.250: bytes=1464 time=244ms TTL=53
Ping statistics for 82.207.247.250:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 221ms, Maximum = 244ms, Average = 229ms
Trev
-
Trev wrote:
:-) Are you behind a firewall and using port mapping and packet forwarding for HTTP? This shouldn't be working
Yes, I configured port forwarding for http. OK, when you ping the address, it's the firewall that is responding, so that's pretty useless. But did you check the dropped packets in the TCP statistics?
-
I didn't see any when I looked. I'll put together a little list of events/scenarios that would result in a dropped packet counter being incremented, and we'll go from there.
Trev
-
These are the conditions that will increment the drop counters:
TCP:
invalid header
invalid header checksum
invalid checksum
fragemented packet
wrong IP address (not a broadcast)
a protocol other than TCP, UDP, or ICMP
UDP:
invalid checksum
ICMP:
a type other than ECHO
I've also put up a new version that includes support for renewing DHCP leases. The lease times will be displayed along with the rest of the configuration. When the lease is renewed, it just spits out the configuration again. If the lease is not renewed, the IP address is set to 0.0.0.0 (may need to make that 255.255.255.255--haven't tested this scenario) and the DHCP discover/request/renew process starts over.
Releasing DHCP addresses isn't strictly required (the DHCP server will clean up leases when they expire), and adding release support will require non-trivial changes to the DHCP client. I'll look at it again when I get around to the non-trivial stuff (read: bsdsocket.library). ... Actually, as I was typing that, I thought of a trivial way to implement it. I'll try it out tomorrow.
You'll find uip and uip-debug in the archive. uip-debug has a little bit of extra logging information and checksum output enabled.
http://www.spookysoftware.com/uip.lha
Trev
-
Trev wrote:
I've also put up a new version that includes support for renewing DHCP leases.
That's great, I was slowly running out of leases already. :lol:
If the lease is not renewed, the IP address is set to 0.0.0.0 (may need to make that 255.255.255.255--haven't tested this scenario) and the DHCP discover/request/renew process starts over.
Shouldn't that be some 169.254/16 address (RFC 3927 (http://www.rfc-archive.org/getrfc.php?rfc=3927))? Or am I mixing up something?
-
Link-local addresses aren't implemented. Implementation of that and other zero configuration networking bits isn't a high priority for me; however, link-local addresses, multicast DNS, et al are very Amiga-like things. They'd also make interaction with Windows, OS X, modern printers, consumer NAS devices, and other cool things pretty straightforward for end users (assuming the required protocols were there, too). When implemented properly, Zeroconf "just works."
Trev
-
For anyone that's interested, lwIP is coming along as well. It compiles (obviously, that's not the difficult part), but the Amiga-specific stuff isn't really working at the moment. It's a much bigger stack, closer to the BSD stack (AmiTCP) in complexity, depending on what you choose to implement.
I'll have something to share in the next week or so, I think, hopefully with full bsdsocket.library emulation. No promises. Worst case, it'll be similar in nature to the current uIP port--a proof of concept to show folks that it works.
For both stacks, I really do intend to have source code up. Seriously--I need advice on how best to optimize the Amiga bits for the smallest footprint possible.
And good news for me, my grandmother's boyfriend (yes, grandparents date, too, apparently) explained to me how a tap works and what I need to buy to drill and tap properly. I'm obviously not mechanically inclined. My Z4 tower arrived with the Z4 busboard holes off-center (apparently, there was more than one revision of the Z4? or maybe Eyetech goofed when they pre-drilled the last set), so my "pre-built" tower ended up being a DIY project anyway. I'm not much of a DIY guy, so we'll see how it goes.
Trev
-
Trev wrote:
lwIP is coming along as well.
Great news. My Amiga systems can´t wait to run it ;-)
Keep up the good work!! I wish I could contribute with coding, but my skills limit me to beta testing. Maybe one day...
-
Ok call me a dumb ass newbie if you like but can somebody point me to the Sana III specs?
I have plans on making a compatible device long term ;)
-
R1 and R2 are on AmiNet (SANA.lha and sana2_v2.lha, respectively). R3 is on Developer CD V2.1, and R4 was posted on the Amiga, Inc. developer forum a number of years ago. R4 is probably also part of the OS4 SDK. The headers themselves aren't that useful. PM your email address, and I'll point you in the right direction. If you can find a copy of Developer CD V2.1 somewhere, it's a must have. If you already have the CD, look in Extras/Networking/ and DevInfo/Networking/. There are various other bits located throughout the CD. It's a bit of a mess sorting it out and putting it all together.
The best thing to do is download the source code for cnet.device, prism2.device, and other devices and look at how they're implemented. The upcoming release of WinUAE will have some interesting source code to look at as well.
Be mindful of your interpretations of S2_ONLINE and S2_CONFIGINTERFACE and be sure to test with AmiTCP 3.0, AmiTCP 4.x, Genesis, and Miami. You'll definitely encounter odd behavior. (See notes in previous posts.)
Trev
-
No lwIP yet. Got busy last week, and I proposed to my girlfriend (now my fiancee) on Monday and really haven't had time to code. :-) We're going to be apart for Christmas :-( ... so I guess that's good for lwIP. Anyhow, lwIP is multithreaded, and implementing a workable thread abstraction is a pain in the ass. Task or process? Task, I say, but that means implementing a messaging subsystem for debug output and quadruple-checking lwIP for code paths that might fall into areas not accessible to tasks. Blah.
-
Still busy, but haven't put lwIP aside. Will be out of town for a bit and then back to work.
Went with processes instead of tasks, as the core lwIP code wants functions that fall into dos.library. The stack is up and running with a loopback adapter but occassionally crashes. D'oh. Got to find out where, fix it, and add ethernet support. (It's probably just crashing on my debug output. Console I/O is wrapped with a semaphore--is that enough to make it thread safe?--but there are probably some stray printf statements somewhere causing havoc. Or it could be something else entirely. Need to do what I was talking about and implement a separate process that does nothing but accept and output debug messages.)
Trev
-
How are things going? Do you make any progress?
-
Hey. Yes, progress has been made. The crashes are all fixed, and lwIP runs happily as a CLI process without access to the network. Work to do: SANA-II code; resident stuff; bsdsocket.library. I've been playing with other things (VGA, iSCSI, AoE, and some Windows stuff), so I haven't been working on lwIP as much as I could be. My fiancee and I have also been catching up with the TiVo queue.
In the meantime, Robert Norris' blog on WebKit is a good read for anyone interested in the ins and outs of porting software: http://cataclysm.cx. He's done quite a bit of support work related to WebKit that could be helpful to other projects as well.
Trev
-
Trev: great work! As for the missing dongle, just in case, here's a nice link for replacing one:
http://labs.cexx.org/dongle.htm
-
Or I could buy one on eBay, which I'd need to do anyway after destroying my card while trying to modify it. ;-)
Update: Still working, but not much progress. I've been looking at ways to improve performance in uIP, including making it much, much smaller, and backport the code to earlier operating systems. I might have a fun surprise for everyone sometime in the next few weeks. It all depends on how quickly AmigaKit fulfills my latest order. :-)
-
To bridge the waiting time for lwIP, I created an icon for it (MagicWB style). It is my very first icon, so don't judge too hard... ;-)
(http://www.wanda25.de/lwip_screenshot.png)
-
That's pretty cool! I guess I'd better write something that understands Workbench semantics. :-) The combination of ReadArgs and tooltypes is great for bridging the gap, but I need a ReadArgs replacement for older Amigas (or a less buggy ReadArgs replacement for all Amigas).
-
Hi there,
Any news on the lwip implementation? I'm looking to build something like hombre, but for IP.
-Cheers Max
-
@Trev
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.
Coincidentally I am at the work working on lwIP implementation for our embedded board. It is efficient but only when you are not using BSD socket API but its own API. It should be also noted that although lwIP has BSD socket compatibility layer it lacks select(). It also has some other deficiencies (at least our implementation seems to have fixed number of sockets, I dont know did subcontractor screw it up or something) and I dont think it is suitable for the desktop use.
We also benchmarked lwIP against proprietary BSD based stack and performance gain achieved by lwIP was not astonishing (but lwIP won that proprietaty stack).
-
@maxlock
I got bored, and my Amiga is still spread about my desk in pieces. So, I've been spending time with my fiancee, playing video games, and generally slacking. In programming, I've been toying with a clean room specification for the MS-DOS redirector/IFS interface.
I'll get back to uIP and lwIP eventually, though, and probably from a different perspective. While we're stuck with the bsdsocket.library interface, I'd like to see something less UNIX-like and more Amiga-like, too. Maybe something like a udp.resource and tcp.resource that lets you allocate and use ports in an Amiga-friendly way. Anyhow, that's all just floating around my head, nothing on paper yet.
A Bonjour/mDNS implementation is on the back burner as well, although its utility on the Amiga is questionable. Build it and the apps will come, I suppose?
Trev
-
http://www.a1k.org/forum/showthread.php?t=21746
Maybe you can join forces...
-
My A500 looks similar to that one, although I still need to cut a hole in the case for the jack. :-) The RRNet works just fine over the clockport. Performance isn't fantastic, but it's not as bad as you'd think.
I'd join the conversation over on a1k.org, but I don't speak German. EDIT: Jens is active there, too. :-( It's too bad he ditched Amiga.org.