@olsen
The "amigazation" and access to inner workings of packets and connections is very nice.
It's better than learning how to wrestle with the Unix APIs. The Unix APIs are still there if they are needed, but if you want to do interesting things, easier access to the power of the TCP/IP stack will get you there faster. I always believed in putting a match and a stick of dynamite into the hands of the developer, and leave him to figure out what to do with those two.
I have never had need for PPPoE, but PPP I use quite a bit, "tethering" (?), or lately on MiniMig using nullmodem or bluetooth link, and my experience is that stability is a heck lot more important than speed.
Stability can be a difficult thing with PPP. The problem with PPP was that quite a number of implementations were deployed while the specs were still under development. There's a nice book documenting PPP which came out of Sun, Inc. that details the gory bits, what works, what doesn't always work, and where the dragons are.
If you write your PPP driver from the specs chances are that there will be interoperability issues. If you port the Unix/BSD/Solaris PPP code you may end up having to jump through a number of hoops if your system's target architecture does not match the one the PPP code was written for. This happened, for example, with the Linux PPPoE daemon: it actually converts PPP packets intended for serial communications into PPPoE frames, and the other way round.
The code I came up should work reasonably well. It did outperform Holger Kruse's own ppp.device, and the PPPoE support provided by the special ppp-ethernet.device has extremely low overhead.
Zeroconf is nice (never needed it), but what I miss is media players capable of playing content streamed over multicast, which means support for PIM-SM, SDM, SSM...
Only one way to find out if it works.
Mind you, not all SANA-II Ethernet drivers support multicast operations robustly.
As for IPv6, I think it's probably best to use KAME, since that is what "all the others" in the BSD camp are using already.
NetBSD took its sweet time integrating KAME into the mainline code, from where it spread to the other members of the family. I think this is the smart way to approach it: use the integrated code and try to not repeat the process yourself. By now the BSD line of TCP/IP stack code should be so well-groomed that it would be a bad idea not to adapt it, wholesale, for the Amiga. I only got started with 4.4BSDLite-2 in Roadshow because the documentation was so good. If I were to do this again, I'd use a more recent TCP/IP stack implementation.
And as you probably know, it's not just a matter of "switching to IPv6", there's also the issue of running dual stack and deal with various transition technologies.
Like I wrote, were are probably not going to see much of a demand on the consumer's side for IPv6 unless you don't have an ISP which does all the heavy lifting and protocol conversion for you. Given how long a rollout of proper broadband connectivity has taken in Europe already, I wouldn't want to bet on when exactly a move to IPv6 were to happen. Of cause, this IPv4 to IPv6 protocol conversion business stinks, since it defeats the very idea and purpose behind IPv6. But it wouldn't be the first time that business decisions being made keep overriding engineering decisions. ISO networking and protocols died a quiet death while IP was trampling all over it, in spite of the fact that the ISO ideas more often than not were better than what the designers of IP and TCP had come up with in the 1970'ies.
Current estimate for IPv4 exhaustion is summer next year, we ("amiga land") are already a decade late in terms of what should have been done, and at least half a decade behind just about any other platform.
All our APIs are IPv4 only. All our software is IPv4 only. Unless you can get every bit of software rewritten that's already out there, you won't see IPv6 adoption, at least in consumer/user land.
So, please, the priorities are somewhat skewed with Amiga TCP/IP stack software.
And what guarantees are there that you wont do the same when selling it? I mean, seriously, it's not like it would be the first time in history of Amiga that this happens. I'll admit that your promises count alot more than most others, though.
One thing I learned is that promises in the Amiga business tend to last as long as butterfly kisses. Sure, they can be nice, but they are more something of the moment than something that will last and keep you feeling warm and fuzzy all over.
I am not promising anything but that I'll try in my little way to hold up what I believe in.
That's totally beside the point, what is the point is that whoever willing then have a much better chance to fix whatever is bugging him/her without needing to contact some author who's no longer around, doesn't care anymore, no longer has the sources, has changed email address etc.
Sounds like you got burned like the rest of us, huh? This Amiga situation has never been pretty. I still recall how Commodore did business back in the 1990'ies, and that wasn't pretty either. When the company went bust the market turned. Some people got out of it altogether, some people flourished while the going was good, and they all were pretty much overshadowed by the con men, the hucksters and the scum that preys on other people's misery. And the really bad thing was that sometimes couldn't really tell which group the guy you were dealing with belonged to.
So, I can see where you're coming from. Seeing the train rumbling along, with no way to stop it, get it back on the tracks, can be a bitch. I've been on that train myself and found that it took me to strange places. But you don't have to stay where it takes you, and you don't have to like it. Either you get bitter about it, or you try to make that strange place you came to a better place.
I'd rather hang on to the stuff I built and try to make it better. There's a limit to how far this can be done. You can burn out (like I did) along the way, and you can find that your own standards are so hard to attain that you lose a lot of steam.
So there's always a chance that you'll let yourself and everybody else down. I'm not excluding myself from that group. It happened, will happen again. I just hope I'll pick myself up, dust myself off and try again.
I fix things in open source software all the time, but only rarely bother to contribute these fixes back upstream, as they're more quick work-arounds for my particual situations than anything else - I'm after all not a programmer.
Everything good and perfectly alright about it. Hey, I could use a hand maintaining my old code, too. It's just that I'm so old-fashioned that I try to dig myself out of my own mess first before I go about shouting for help. I'm just like that. Why make somebody else's life harder? It's bad enough that I made my own life harder.
Sure, but this is not something "most users" bother with.
Uhm, I dont get this part. The reason to stay AmiTCP V3 compatible is that this is what all software today use. Create an IPv6 stack tomorrow, it will still be the case. Nothing prevents an IPv6 capable bsdsocket.device in UAE.
Perfectly understandable. But without anybody using these toys, how will you build the knowledge of how to use and maintain such software? It's not just about getting the bugs out.
Anyways, WinUAE recently got A2065 emulation (iirc) - so anyone who want to play around with that can do so, but i really don't think there are many.
Well, the a2065.device driver is in really poor condition. The uaenet.device does work better. I suppose the A2065 hardware support came about so that you could use software deployed using the A225 kit. There is not a lot of it about, though. I only recall Maxis' "Robosport" title which supported multiplayer gaming over Ethernet through A225.
OK, I'm almost tempted to register in order to give you hell, then :laughing:
That's the spirit...
Btw - on a related note, people have been moaning about wireless stack for about half a decade as well now, feel free to port wpa_supplicant, opensea, open1x or make your own ... hohum... AirShow too. I can keep you busy there with testing and bug reports for years, really. And funny things are often needed to be changed in the IP stack as well when you start playing with wireless, the OSI model is after all just that - a model, in real life the layers typically become much more entangled 
Well, I tend to try and make stuff I'd be likely to use myself. Of all the wireless gadgets I have at home, none I would like to use with an Amiga. Do I have to cook up my own crypto code for that, too? I'd rather not to. This sort of thing always ends in tears, if not worse. So there's probably not going to be any sort of WPA or VPN solution from my side for a while.
PS: Thanks for Term, although I admit I most often end up using VLTjr that doesn't suck up all that much RAM. I once started looking at how to strip off all the unneeded fluff in Term, but like so much I start doing on amiga, it never got far.
Gee, somebody's still looking at 'term'. I'm amazed, puzzled and a bit scared to read about it.
