uIP/lwIP for Amiga OS

[Trev]

:-) 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

[Colani1200]

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?

[Trev]

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

[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

[Colani1200]

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)? Or am I mixing up something?

[Trev]

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

[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

[Colani1200]

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

[MiniMorph]

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

[Trev]

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

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

[Trev]

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

[Colani1200]

How are things going? Do you make any progress?

[Trev]

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

[tnt23]

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

[Trev]

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. :-)