Roadshow vs AmiTCP/GENESiS

[stevelord]

Hi,


I have GENESiS from OS3.9 working with a Serial/PPP connection in my A4000 while I wait for the MNT ZZ9000 (which will be SANA-II).


I'm aware of the CPU overheads with using serial.device, but I was wondering if anyone's done any testing of GENSiS/AmiTCP vs Roadshow. Are there any compelling reasons to choose roadshow over AmiTCP if AmiTCP is working?

[nogginthenog]

For me the compelling reason to use Roadshow is that Olaf still develops and supports it!
You can try a replacement serial device. I seem to remember 8n1.device works well.

[Sir_Lucas]

It's the same for me if it comes to Roadshow. The fact that it is still developed is a very important factor.
It supports DHCP and it's a bit faster than AmiTCP.
Roadshow is also a lot easier to configure.

[gdonner]

Like nogginthenog and Sir_Lucas noted, it's newer, and has more up-to-date support for current Internet protocols, etc.

It also works very well, and is very efficient.

My only real wish for Roadshow (besides wanting it to have a long, well-updated life) is that it would have a small, but handy GUI for tweaking the few config items that need to be adjusted after installation.

Otherwise, it's very good, and well-worth the money.

One thing I've learned is that, starting with his 100%-Style Guide compliant "Term" program back in the early 90s, Olaf Barthel writes reliable, quality software.

[indigolemon]

Originally Posted by gdonner

My only real wish for Roadshow (besides wanting it to have a long, well-updated life) is that it would have a small, but handy GUI for tweaking the few config items that need to be adjusted after installation

It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

On Aminet here:http://aminet.net/package/comm/net/Roadie

Some screenshots:


The Main Window


Showing results of the ShowNetStatus command


Editing an Interface file

[utri007]

Originally Posted by stevelord

Hi,


I have GENESiS from OS3.9 working with a Serial/PPP connection in my A4000 while I wait for the MNT ZZ9000 (which will be SANA-II).


I'm aware of the CPU overheads with using serial.device, but I was wondering if anyone's done any testing of GENSiS/AmiTCP vs Roadshow. Are there any compelling reasons to choose roadshow over AmiTCP if AmiTCP is working?

I bought Roadshow but decided not to use it. Two reasons, I not happy how well DHCP client works and it doesn't have a GUI. So instead of manually configuring IP, I reverted back to Genesis.

I'm not regretting to buying Roadshow, I might found use for it latter.

[Olaf Barthel]

Originally Posted by nogginthenog

For me the compelling reason to use Roadshow is that Olaf still develops and supports it!

I am definitely working on it, but it's taking longer than I had expected to get the overdue update out the door

Summer's coming up, and there's one thing I learned during that long hot Summer of 2018: even if the heat is getting me down, I can still crank out perfectly working Amiga code and debug it, too. Just don't ask me how this works, it just does

So there's hope that I'll be getting the update ready this year.

[Olaf Barthel]

Originally Posted by utri007

I bought Roadshow but decided not to use it. Two reasons, I not happy how well DHCP client works and it doesn't have a GUI.

What can I do to make the DHCP client work better for you?

[Daedalus]

Originally Posted by Olaf Barthel

What can I do to make the DHCP client work better for you?

Disable it, apparently If Genesis works better with DHCP then there's something really strange going on with his network.

[Olaf Barthel]

Originally Posted by Daedalus

Disable it, apparently If Genesis works better with DHCP then there's something really strange going on with his network.

Either that, or limitations of the built-in Roadshow DHCP client make themselves felt.

Due to an oversight of mine the built-in DHCP client can only negotiate a lease extension but it cannot rerun the entire IPv4 address acquisition process. This should rarely be a problem, but if it is, you don't get a hint from Roadshow that you will need to use the ConfigureNetInterface command to get going again.

I need to fix this, but in the past few years I could not come up with a satisfying solution

The DHCP negotiation can fail, too (for various reasons). In order to diagnose the problem you need to be aware that the negotiation failed, then enable debug mode for the network interface in question and retry. Roadshow will open its debug console window and print progress (and failure) messages while it's trying to make the DHCP negotiation work. None of this in any way near obvious and reading the manual should not be a requirement for diagnosing network problems. Still, it's hard to make this sort of thing work well for both the user and the developer.

As to why DHCP negotiation may fail, there's a great variety of possible causes, ranging from hardware trouble (flaky cabling and connectors) to routing problems, to multiple "authoritative" DHCP servers fighting it out in the network, to DHCP servers running out of leases (to name a few of the less bizarre causes). There's very little joy in finding the cause of the problem, especially if the DHCP client fails to produce helpful debug output.

So I guess it's fair to ask what could be improved in order to solve the problem which utri007 mentioned.

[Daedalus]

Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.

[spudje]

Originally Posted by indigolemon

It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

http://www.indigolemon.co.uk/linkedi.../Roadie1.0.lha

Sounds cool! Any screenshots before I consider trying?

[Olaf Barthel]

Originally Posted by Daedalus

Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.

One you can depend upon (it never works), the other you cannot (it may not work as intended, but it's hard to predict under which circumstances). Sort of like the old saying that a stopped mechanical clock accurately tells the time twice a day whereas a working mechanical clock is never accurate

[indigolemon]

Originally Posted by spudje

Sounds cool! Any screenshots before I consider trying?

Have amended my post above

[utri007]

Originally Posted by Daedalus

Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.

Setting static IP with GUI is better than doing it with text editor.

Some times it fails to get IP and some times it negotiate a long time. It doesn't tell when it is online.


Problem is also in a AOS4, but that version of Roadshow has a GUI.

[Olaf Barthel]

Originally Posted by utri007

Setting static IP with GUI is better than doing it with text editor.

I totally agree to that. For example, the GUI can validate the IP address entered and refuse to accept invalid/unsuitable input (explaining why it is invalid/unsuitable). By the time Roadshow gets to look at the configuration file it cannot do much more than reject such input, which is made worse by the fact that during system startup it's difficult to even show an error message

Early input validation is crucial. While the Roadshow documentation states that familiarity with setting up the network configuration is required, I doubt that those users who run into difficulties will find this notion helpful, to say the least (who reads documentation anyway?).

Some times it fails to get IP and some times it negotiate a long time. It doesn't tell when it is online.

Again, this is a problem born out of how/when the interface address acquisition occurs It could be mitigated by moving this particular task to a later stage when the Workbench is already open and error messages are easier to display and to record.

Almost 19 years in, I haven't come up with a decent solution to this problem, which is in part caused by design decisions which sidelined error handling and reporting. AmigaOS lacks an error logging and reporting mechanism, which affects the entire early system startup process (with the boot shell executing the S:Startup-Sequence script). If anything goes wrong during S:Startup-Sequence execution it's very hard to figure out what happened, and it's worse for S:User-Startup execution which is likely to be immediately followed by LoadWB and EndShell: the boot shell window closes instantly after it has briefly shown any error messages.

If you want to have another look at the DHCP client doing its job and not getting anywhere fast, or failing, I would recommend editing the interface configuration file, changing the line #debug=yes to debug=yes, entering NetShutdown followed by AddNetInterface <name of your network interface>. That should cause Roadshow to start over, open a debug output window and display every step of the DHCP process. If the DHCP process fails for you, the debug output might help in tracking down the cause of the problem.

The DHCP negotiation takes a bit longer (60 seconds) because the client verifies that the IPv4 addresses it was offered are not currently in use. Thus, a timeout has to occur before Roadshow accepts it. You can change that timeout with the TIMEOUT parameter or icon tool type. The minimum are 10 seconds. Yikes, I seem to have (as usual) overengineered this one, neglecting the usability of the interface setup

Problem is also in a AOS4, but that version of Roadshow has a GUI.

Neither the AmigaOS4 nor the 68k version of Roadshow show the DHCP debug output by default, and the interface timeout (unless overridden) is set to 60 seconds, too...

[duga]

Originally Posted by indigolemon

It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

On Aminet here:http://aminet.net/package/comm/net/Roadie

Some screenshots:


The Main Window


Showing results of the ShowNetStatus command


Editing an Interface file

Good job!

[gdonner]

Yes, very nicely done! And v1.1 is now available, too:

https://aminet.net/comm/net/Roadie.lha

[utri007]

Originally Posted by Olaf Barthel

I totally agree to that. For example, the GUI can validate the IP address entered and refuse to accept invalid/unsuitable input (explaining why it is invalid/unsuitable). By the time Roadshow gets to look at the configuration file it cannot do much more than reject such input, which is made worse by the fact that during system startup it's difficult to even show an error message

Early input validation is crucial. While the Roadshow documentation states that familiarity with setting up the network configuration is required, I doubt that those users who run into difficulties will find this notion helpful, to say the least (who reads documentation anyway?).

Again, this is a problem born out of how/when the interface address acquisition occurs It could be mitigated by moving this particular task to a later stage when the Workbench is already open and error messages are easier to display and to record.

Almost 19 years in, I haven't come up with a decent solution to this problem, which is in part caused by design decisions which sidelined error handling and reporting. AmigaOS lacks an error logging and reporting mechanism, which affects the entire early system startup process (with the boot shell executing the S:Startup-Sequence script). If anything goes wrong during S:Startup-Sequence execution it's very hard to figure out what happened, and it's worse for S:User-Startup execution which is likely to be immediately followed by LoadWB and EndShell: the boot shell window closes instantly after it has briefly shown any error messages.

If you want to have another look at the DHCP client doing its job and not getting anywhere fast, or failing, I would recommend editing the interface configuration file, changing the line #debug=yes to debug=yes, entering NetShutdown followed by AddNetInterface <name of your network interface>. That should cause Roadshow to start over, open a debug output window and display every step of the DHCP process. If the DHCP process fails for you, the debug output might help in tracking down the cause of the problem.

The DHCP negotiation takes a bit longer (60 seconds) because the client verifies that the IPv4 addresses it was offered are not currently in use. Thus, a timeout has to occur before Roadshow accepts it. You can change that timeout with the TIMEOUT parameter or icon tool type. The minimum are 10 seconds. Yikes, I seem to have (as usual) overengineered this one, neglecting the usability of the interface setup



Neither the AmigaOS4 nor the 68k version of Roadshow show the DHCP debug output by default, and the interface timeout (unless overridden) is set to 60 seconds, too...

Tested Roadshow with Roadie GUI, it does what it promises.

Another option for a GUI, would be ask help from Chris Young. He is a author of Netsurf and most likely only person who has experience to backporting AOS4 Reaction GUI to OS3.5/9. That would be limited to OS3.5/9


How about starting Roadshow from WBstartup? Would it make status/error reporting easier?

[Olaf Barthel]

Originally Posted by utri007

Tested Roadshow with Roadie GUI, it does what it promises.

Another option for a GUI, would be ask help from Chris Young. He is a author of Netsurf and most likely only person who has experience to backporting AOS4 Reaction GUI to OS3.5/9. That would be limited to OS3.5/9

I've been so thoroughly burned by trying several times over to get a comprehensive GUI for all that Roadshow does off the ground, and failing, it's hard for me to even think about trying again now

How about starting Roadshow from WBstartup? Would it make status/error reporting easier?

It would make practically all the problematic aspects easier to deal with which the current approach suffers from. The downside is in that you could not leverage the early availability of the network in the S:User-Startup file, which can be really useful. For example, starting the network, followed by starting the smbfs file system is a common pattern.

Let's say I find a way to move the network startup procedure from S:User-Startup into the SYS:WBStartup drawer. Then I'd have to deal with services (such as smbfs or FACTS) which expect the network to be operational when they start up.

One way to approach this would be to introduce script execution to Roadshow, which means that interface state transitions (between online to offline) would cause script files to be executed. Script files would also be executed when Roadshow as a whole transitions between fully operational network and network operations unavailable states. This should be relatively easy to implement, with the complex part being detecting the state changes and figuring out how to deal with state changes which occur while the scripts are still being executed which were triggered by the previous state change. But it leaves out how to deal which are not commonly started from script files, e.g. FACTS. I would not like to reinvent the SYS:WBStartup drawer for Roadshow.

Error reporting in general would have to be improved, too. All the shell commands which are part of Roadshow are designed to print output to the console. A single startup procedure triggered by a program launched from the SYS:WBStartup drawer would have to reproduce the functionality of both AddNetInterface and give useful hints about the errors it encounters trying to bring up the network. That would take quite some work to make it do the job well. One major drawback of launching the network from S:User-Startup is that error messages can neither be displayed, nor saved for later inspection, you just observe that things didn't work if they didn't work

What do you think? Is this is in any way a useful path to follow? I would start by looking into how to make the state changes triggering script file execution work, since this is something which other programs could build upon. Opening up the closed parts of the design should be beneficial.