Roadshow for 68K -Needs your support!

[olsen]

This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send."  I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.

I suspect that the design of the DHCP protocol contributed to the odd client and server behaviour. The purpose of DHCP is to allow a client to learn about the network it is part of, and to share network resources without interfering with other clients. To this end DHCP makes sure that the exchange of information between clients and servers is well-defined and produces results: either the client gets what it wants, or it can be certain that no requested information will be forthcoming.

That's the plan, but there is no mechanism in DHCP to specifically help uncovering implementation errors. You have packet exchanges which say something along the lines of "here is the choice I can offer you", "this is what I want", "here is what I can give you".

But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.

I remember that during OS4 testing, there were reports from cable modem users who said that they were losing their DHCP-assigned IP addresses. It turned out that the IP address leases assigned by DHCP were relatively short, and the Roadshow DHCP client correctly sent out lease extension requests, and eventually address renewal requests. Only that the DHCP server paid no attention to either, which eventually led Roadshow to stop using its assigned IP address altogether (all according to spec).

It would have been helpful to know why the DHCP server chose not to respond to the DHCP client messages. I now believe that the DHCP server found something in the packets it did not like. But as the DHCP protocol has no mechanism for notifying the client of such glitches, there was no way to figure out what was going on.

SHIP SHIP!  As for the GUI, I think leaving it without one gives the option of providing our own.  Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones.  I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.

How the configuration files work, where they are stored, etc. is documented. Source code for all the shell tools is included, right down to the tcpdump/libpcap ports I cooked up. Anybody curious enough to start tinkering can do so with my blessings.

If you want to make a GUI, using the provided SDK material should allow you to do so.

What about a volume discount?  Seriously, I, for one, like the price notion.

Whoa! I haven't thought that far yet. Really, the imperative now is to get the thing ready to ship, and then ask the really difficult questions.

[olsen]

I'll buy just as soon as it's available!

I assume the command line would be similar to ifconfig under linux?

Um, no. I hope that they are better than that

Since the TCP/IP stack I built upon comes out of the BSD Unix heritage, the usual set of network setup/control/information commands to ship with it would include "ifconfig", "route", "arp", "netstat", "traceroute" and "ping". Of these I chose only to keep "arp", "traceroute" and "ping" and wrote Amiga-fied versions of the rest.

For example, to set up and configure interfaces and routing you would use the "AddNetInterface" and/or "ConfigureNetInterface" commands (they combine what "ifconfig" and "route" can do). To change the routing, you would use the "AddNetRoute" and "DeleteNetRoute" commands (these do what "route" could do). To obtain information about the state of the network you would use the "ShowNetStatus" and/or "GetNetStatus" commands (these do what "netstat" could do, and a bit more than that).

The point of making new commands was that, well, the originals were very terse and cryptic, and if they had been deliberately designed to make them harder to use, the designers couldn't have done a better job. I repeatedly ran afoul of the BSD "ifconfig" and "route" syntax, at which point I really had it, and I started to write Amiga-specific APIs for doing what these configuration tools would do (the "ifconfig" and "route" code itself is incredibly convoluted and crufty, too). Then I wrote new Amiga-specific commands to use these APIs.

I hope that these replacements provide better control, better error reporting and better platform-specific functionality than the original Unix commands would do. For example, you can use "GetNetStatus" (especially in script files) to test if specific aspects of the network are configured and operational; to the best of my knowledge there is no single Unix command which would provide you with this set of information.

I realize that ditching the "ifconfig", "route" and "netstat" commands may make it a bit more difficult to learn how Roadshow is set up and configured, assuming that you have prior knowledge of these Unix commands. But: to the best of my knowledge no two Unix/POSIX systems use the same syntax and switches, regarding these three commands. For example, the OpenBSD versions of "ifconfig" and "route" do not work like the Linux versions, or the Mac OS X versions, etc.

Bonus: the "traceroute" command has bugs fixed which have been around since 1987 and are still present in today's *BSD implementations of the command

Lack of GUI doesn't bother me but I can appreciate others would prefer this.

Will basic network commands (ping, traceroute etc) come with this?

Yes. "arp", "ping" and "traceroute" are included, as well as "tcpdump" and the BSD "ftp" client, and the tools that are part of Darren Reed's ip filter package. Source code for tcpdump/libpcap and the Amiga-fied shell commands is included (but not for the "ftp" client, etc. mentioned above; I didn't quite see the point since these tools are so simple).

I also ported "wget", which should become part of the shell command collection, but I'm not sure where I put the source code

[olsen]

A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK.

The purpose of the NAK message is to tell the client/server that the contents of a request are unsuitable. But in order to get as far as knowing that a NAK message should be sent in response, you have to have processed the meaning of the original message first.

If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.

What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.

I suppose that could encourage continuous bad behavior from a bad client, however.  I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:

There is a lot of bad news in how DHCP implementations actually behave, as compared to the deceptively simple RFC specification. Some of the quirks are really outlandish, such as the minimum packet size. With a lot of handwringing, that minimum packet size comes out of the original BOOTP specification (RFC 951). Why a server would have to reject such a packet purely based upon its size, rather than its contents, is (at least for me) puzzling.

A problem I frequently saw in the past was that of identical IP schemes in use in multiple places.  The problem was DNS.  A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home.  The office DHCP server would happily approve the request, provided the IP was not in use on the network.  The client would then retain all of its network configurations including DNS, which may or may not work on the office network.  Or vice-versa.

Sounds like a poorly-configured DHCP server to me

For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.

[olsen]

Hello!
I read about the "evolution" of this thread and Roadshow, but I missed (or wasn't stated) something about the limitations of the plain 68k version: it's written it's going to be, but there are no details about.
Could you tell us something Olaf?

Limitations? Hm... there are not going to be any functional limitations, compared to the version of Roadshow available as part of OS4.

Given the age of the code Roadshow is based upon, you won't see TCP/IP stack features which were added after 1994. This means that features such as path MTU discovery, T/TCP or IPv6 support will not be available. But they are not available in the OS4 version of Roadshow either.

I am determined not to put any DRM or anti-piracy measures into the 68k version, if this is what's mainly on your mind.

The current plan is that you will be able to legally use each copy of Roadshow on up to two computers at the same time, provided you paid for your copy. If you intend to use that copy on more than two computers at the same time, you will have to buy another copy. But (read the bit about DRM and anti-piracy measure above), I will not try to stop you from using your copy on more than two machines at the same time. It's your responsibility to comply with the usage requirements.

Due to how Roadshow works, it requires Kickstart 2.04 or higher. AmigaOS 1.x is thoroughly unsupported.

The devices, libraries and tools that come with Roadshow will all work on a plain 68000 machine. A special 68020-060 version of "bsdsocket.library", which implements the TCP/IP stack, will be included.

That's about as many "limitations" as I can think of right now.

I own many Amigas, but I like my A500 in particular (even if at the moment I have no ethernet option on it).
Thanks!

Not sure how the A500 will be supported, if it doesn't have a dedicated networking interface. You could probably rig something up with "plip.device", "slip.device", "liana.device" or "ppp-serial.device" and the necessary cabling, but it probably won't be quite so much fun

[olsen]

Yes, one could implement something path MTU discovery-ish as a filter :p


Yes, and many of us have been promoting the liberation of AmigaOS sources since 1994, but nah - we still have to resort to hack&patch to fix things, and  anyone who _dare_ distributing prepatched binaries is officially to be treated as an outcast (yet everyone and their dogs happily share whatever on the zone over at EAB).

Light a candle instead of cursing the darkness...

And how long till Roadshow is dead? I don't see the big difference, really.

I intend to stick around for a while, been doing it for almost 23 years now.

Holger's not even posting to this forum. But I am

[olsen]

Will this be released in time for xmas?  

Actually, I haven't thought that far ahead. It's just that the work I put into the documentation, the installer script, etc. finally came together this weekend.

As far as I'm concerned the result is ready to ship right now. I likely won't be selling Roadshow 68k by myself, and there's a standing offer from one publisher to take care of it for me, on short notice. There's another offer from a different publisher to integrate Roadshow 68k with a GUI and sell this integrated product, but I haven't heard back from him yet.

Likely I'll wait until next week before I make a decision on how things will move ahead. It's possible that Roadshow 68k will indeed be available for sale before Christmas this year

[olsen]

Nice!
And regarding the GUI side, maybe someone will come up with a third party option for free on Aminet!    (since you documented how to control the stack well, right? It's all done by modifying some ASCII text files...)

I hope I've got everything covered. The printable documentation runs to about 112 A4-sized pages, and it describes the file formats and commands in great detail. Plus, the SDK has the source code of the individual configuration commands, for reference and tinkering.

One side note about future releases: do you plan to make them free for registered users?
Just little updates?
I know it sounds a bit ahead, but just to know your ideas...

BY!  

I strongly believe in free updates. But, just like with CygnusEd, I reserve the right to ship them as incremental patches. Which also makes for shorter distribution archives

[olsen]

To olsen:

Sounds good But I have some questions:

1) What are the advantages of Roadshow compared to MiamiDX (lack of Gui is not a concern)?

You can rely upon me to be a poor salesman. Here are the disadvantages:

- TCP/IP stack code is older than what Miami uses (Miami = NetBSD; Roadshow = 4.4BSD-Lite2)
- No built-in GUI
- Configuration works through text files
- No IPv6 support
- No built-in SSL support
- No ARexx interface

Here are some of the advantages of Roadshow:

- Significantly higher performance than Miami; according to my tests Roadshow is the fastest Amiga TCP/IP stack
- Uses far less memory once it's running than Miami, which means that you can run Roadshow on an extreme low-end configuration (Amiga 600HD with 2 MBytes of memory) and still have enough free memory available to run client software
- Controlled entirely through shell commands, which makes the whole thing scriptable
- Implemented a a single shared library, not as a big monolithic application
- Requires no assignments or shell paths to be set up, installs to your boot partition and acts as if it were part of the operating system
- Has a built-in DNS cache
- DNS client supports international domain names (ISO Latin 1 only, though), and transparently translates between the Punycode encoding and the human-readable form
- Built-in support for ZeroConf interface address assignment
- Comes with SANA-II drivers for PPP (modem/ISDN dialup) and PPPoE (ADSL)
- Supports the standard AmiTCP V4 API, plus a boatload of extensions which, among other things, allow for monitoring and manipulating traffic
- Source code for all configuration commands included in the SDK
- Developed and maintained by somebody who still answers questions and is likely to provide for support and bug fixes in the future

2) What kind of price do you have in mind (downloadable distribution)?

It's possible that this will be a downloadable archive which will have to be unpacked and copied to an installation medium. I don't know yet how it will come out, though, as I haven't signed with a publisher yet, and it's unlikely that I will publish the thing myself.

As for the price, I've asked around and the general consensus seems to be that you can't really charge more than 25€ per copy for this kind of software. Maybe add another 5€ for media costs and shipping. Maybe add some more if the package were to ship with a GUI.

So, I expect the end product price to be somewhere around 30€.

3) Will it be possible to pay by bank transfer?

If I sign with a publisher, this would be one option. I expect PayPal to be another option.

If those questions can be answered in a positive way, then you've got a customer right here

Well, some of the questions are still unanswered from my own perspective. I know where this project is going, but the definitive answers will still have to wait a bit...

[olsen]

Anything new about this?

Still waiting for one prospective publisher to respond. Should this fall through, I'll go with another one. The TCP/IP stack is still good to go, with a manual, installer script, SDK, everything.

[olsen]

Could you pay some attention to WHDload compaptibility?

Last time I checked, there was no sound approach to getting this worked out: you have to turn off the interrupt processing triggered by incoming packets, and the proper way to do that is to shut down the TCP/IP stack.

[olsen]

hah! get the lead out olaf! I want to get my hands on this before i'm too old and broken down to use a computer!..

All joking aside, i hope you find a way to release it soon.

mech

Newsflash: right this very minute I'm working on getting the publishing deal off the ground, to be concluded soonish, with hopefully the final product to become available within February.

[olsen]

Bump

I hear you... This is taking longer than I had expected. The release software and the demo version were delivered to the publisher more than two weeks ago. I thought we'd have a web site by now, and the product would be available for order. But stuff happens, and the whole thing has been delayed again

[olsen]

Why don't you just sell it yourself by paypal and email licence keys to people that buy it?

Two reasons. First, the product needs a web site and a public support forum. These things are not a luxury. For the kind of product Roadshow is, it's inevitable that questions will come up which need to be answered, and the answers ought to be available for everyone in one single place. I don't have a web site or a public support forum, and setting them up means paying for them. I'm not sure if selling Roadshow would even manage to pay for the cost of setting up a web server. Second, I signed a contract with a publisher who already has the infrastructure in place. I can't just walk away from that.

Yes, it has been a long journey since the Christmas holidays in the year 2000 when I started working on what became Roadshow. But will a few days more hurt? I hope not...

[olsen]

olsen

This was discussed months ago and it was ready months ago. What in the world could take so long?

There's ready and there's 80% ready. Roadshow was 80% ready when the DHCP client bug fix was implemented and tested. The remaining tasks were 1) to find a publisher or publish Roadshow myself, 2) write installation instructions, a tutorial and a reference manual, 3) compile the distribution files and write an installation script, and 4) set up a web site and payment system and make the product available.

All but the last task have been taken care of. I'd like to think that I used to be a wee bit faster at writing manuals and installation scripts than I am today, but that's probably just delusion But this stuff takes its time if you want to produce something that satisfies you.

For all the software I wrote by myself, I always attempted to make something that I would find useful. Hence the 112 page tutorial/reference manual, which has absolutely everything in it, and the installer script which not only installs the software, but can uninstall it again, too, and make backup copies of your configuration files.

Some may view this as gold plating, and there certainly is the danger here to go overboard and go from 80% ready to 90% ready, to 95%, to 97.5%, to 98.5%, to 99.7% and so forth in the Zeno school of product development. I hope that the end result will be more useful, and not just shinier as a consequence.

You are losing a lot of momentum.

Well, you'd have to thank mech for getting the ball rolling again, and far as I can tell the ball is still tumbling along. I'm going to see this through, even if it takes a bit longer. Part of the journey is getting there, but you might as well enjoy the journey itself, too

[olsen]

Any news?

I'm waiting, money in hand.

Sorry this has been taking so long. I was still on a roll in March, got the distribution archive ready, got the demo version ready, got the SDK ready, but then something happened

I burnt out and I am still recovering.

[olsen]

Sadly i talked with Olaf and last time he was busy with other projects and i "think" the problem was distributing roadshow with the people who he was working with. This was about a month ago i talked with him.

Let's say there were some problems beyond my control, since resolved, and the only thing that keeps the product from getting released is that the web page, etc. text needs to be written. I have been trying to do that for quite a while now, but I am having big trouble summoning the energy.

All this will pass, as it always will, but until it does, I hope the project will not be forgotten. It's 99.76% ready to go.