Roadshow 1.13 released

[AndreasM]

The Roadshow TCP/IP stack for the Amiga has been updated to version 1.13 and is available immediately. An updated demonstration version is available, too, as well as the updated software development kit.

A free update is available for customers who are using Roadshow version 1.12, upgrading it to version 1.13. Note: if you are still using Roadshow versions 1.8 or 1.11 then you will need to upgrade to version 1.12 first before you can upgrade it to version 1.13.

The changes in Roadshow 1.13 are as follows:

1. Polish localization files were contributed by Tomasz Potrykus,
which can be installed as part of the update process.

2. The "ping" command has been updated to support new options, which can
be used limit the number of test packets sent, either by
time or count. The time interval measurements taken and displayed
were upgraded and are now much more accurate than they were before.

3. The "traceroute" command shares the same time interval measurement
improvements with the "ping" command.

4. The "wget" command no longer crashes if too little stack memory
is available in the shell. Also, the data throughput rate calculation
now works correctly, which both affects the display of the estimated
remaining transmission time and the data rate limiting feature of
the "wget" command. Finally, the short form command line options (e.g.
"-q" for "--quiet") never worked correctly. This has been fixed.

5. Several related bugs were fixed within "bsdsocket.library",
the "SampleNetSpeed" and "ppp_sample" programs, which could
lead to memory corruption or seemingly random crashes.

6. The "ConfigureNetInterface" did not process the DHCPUNICAST
parameter correctly. This has been fixed.

7. The specially optimized versions of "bsdsocket.library",
"ppp-serial.device" and "ppp-ethernet.device" for use on Amigas with
CPUs other than the MC68000 and MC68010 can no longer result in crashes
if they are used on systems for which they are not suited.

8. The "TCP:" handler leaked memory whenever it was opened. This
has been fixed.

9. How much memory "bsdsocket.library" will use for incoming network traffic
can now be tweaked. This is helpful for applications which keep
running for day or weeks on end. Previously, "bsdsocket.library" could
end up allocating much more memory than strictly necessary, causing other
active software to run out of free memory. Because the choice to
spend as little memory as possible comes with a cost (slightly lower
data throughput), this option is not enabled by default.

10. The software development kit has been updated, fixing bugs in the example
source code, the "wget" command, as well as replacing the inline header
files for the GCC 68k compiler.

11. The reference documentation has been updated.

The "ReadMe" file of the "Roadshow" update archive contains more detailed information about the contributors who helped to make this update possible, as well as more detailed descriptions of the changes.

The update archive does not contain the updated documentation or source code. Please download the demonstration version and/or the software development kit, respectively, to find the new material.

http://roadshow.apc-tcp.de
http://www.apc-tcp.de

[indigolemon]

Excellent! Will grab the update tonight

[Sir_Lucas]

Great news!!

[funK]

AndreasM: Any plan to do a physical release? Would buy one copy in a heartbeat!

[Magic]

Thank you for the update

[nogginthenog]

Great news! RoadShow is by far the the best Amiga TCP/IP stack.

[jayminer]

Yay, new Roadshow! Great news!

A problem I had though - the installer should probably say something if ced-patch fails on patching a file. For some reason on one of my A4000:s the updater failed to update wget and bsdsocket.library, but it looked like everything suceeded. I only noticed by doing version on bsdsocket.library - it was still the old version. I then looked at the installerscript and ran ced-patch manually and noticed that it complained about a wrong CRC for some reason.

[Estrayk]

Thanks for the update!

[Retrofan]

Thanks for improving it, it's the best of course

[klx300r]

awesome! Roadshow is hands down quicker than any other TCP/IP stack I've ever tried on my miggies and much easier to setup

[HelloBeautiful]

Brilliant, thanks!

[indigolemon]

Is anyone else having issues with the ping command after this update? The update seemed to go smoothly (I've since removed roadshow, reinstalled 1.12 and run the update again - once more it went smoothly) but it crashes for me after sending the first packet.

I backed up the old ping before running the update second time round, and it's still working fine - so wondering if it's just me

Broken: 4.11 (crashes hard after first packet is sent)
Working: 4.7 (sends packets merrily all day)

[patrik]

Originally Posted by indigolemon

I backed up the old ping before running the update second time round, and it's still working fine - so wondering if it's just me

No it's not just you. It is an issue and has been reported.

[Olaf Barthel]

Originally Posted by indigolemon

Is anyone else having issues with the ping command after this update? The update seemed to go smoothly (I've since removed roadshow, reinstalled 1.12 and run the update again - once more it went smoothly) but it crashes for me after sending the first packet.

I backed up the old ping before running the update second time round, and it's still working fine - so wondering if it's just me

Broken: 4.11 (crashes hard after first packet is sent)
Working: 4.7 (sends packets merrily all day)

I am sorry, I broke the "ping" command when I added the "timeout" option

Until the fixed version is available, you might be able to work around the problem by specifying a long timeout, e.g. "ping timeout=1000000 www.example.com" (that's about 11 days and a bit in case you're wondering).

The current plan to provide an updated "Ping" command is to update both the demo and retail version archives first, and then the update archive.

When I finished (or so I thought) work on the 1.13 update I proceeded to spend some more time on writing a new "rsh" command (requested by Kolla), which will also be part of the updated demo/retail archives. While looking for the bug in the "ping" command (reported by patrik), I cleaned up the source code, which up until then had been almost unchanged since the year 2002. In preparation for coming attractions in the next "bsdsocket.library" version (haven't started working on those changes yet) I wrote new "online" and "offline" commands, which will be in the updated demo/retail archives, too.

All the source code for the "online", "offline" and "rsh" commands, as well as the cleaned up "arp", "ping" and "traceroute" commands, will be in the updated SDK. I'm still pondering adding the "ftp" client source code, but it's so old and in rough shape that it does not make for a decent example to build upon.

[indigolemon]

Originally Posted by patrik

No it's not just you. It is an issue and has been reported.

Ah good, I'm not always sure if it's a real bug, or several system patches colliding!

Originally Posted by Olaf Barthel

I am sorry, I broke the "ping" command when I added the "timeout" option

If my biggest problem with Roadshow is having to use an older ping command, I definitely consider myself winning! Thank you for the time and effort you put into this, it really is a great package - coming from a Linux background, I found this easier to set up than most GUI based stacks

I'm sure I'll survive until a fix is released - as said, just wanted to makes sure it wasn't something I'd done

[Olaf Barthel]

Originally Posted by indigolemon

Ah good, I'm not always sure if it's a real bug, or several system patches colliding!

I understand only too well (and painfully, too) what you mean

If my biggest problem with Roadshow is having to use an older ping command, I definitely consider myself winning!

As long as the remainder of the update works well... It all goes to show that I lack the support of testers who can verify that the update does what it's intended to, before the update is deployed. Some things you just can't do all by yourself, given the complexity of the product.

Thank you for the time and effort you put into this, it really is a great package - coming from a Linux background, I found this easier to set up than most GUI based stacks

Coming from a Linux background, that's probably to be expected I suppose we can all consider ourselves lucky that Roadshow is IPv4 only. Things would be even harder with fully baked IPv6 support.

I'm sure I'll survive until a fix is released - as said, just wanted to makes sure it wasn't something I'd done

You can blame only me for not testing the "-t" (timeout) "and "-o" (onereply) features on my Amiga 3000UX on which MuForce would have reported the problem immediately

[indigolemon]

Originally Posted by Olaf Barthel

As long as the remainder of the update works well... It all goes to show that I lack the support of testers who can verify that the update does what it's intended to, before the update is deployed. Some things you just can't do all by yourself, given the complexity of the product.

If you want I'd happily help out here? I've taken to backing up my OS partition before installing anything anyway - as you say, it can be painful otherwise!

Originally Posted by Olaf Barthel

Coming from a Linux background, that's probably to be expected I suppose we can all consider ourselves lucky that Roadshow is IPv4 only. Things would be even harder with fully baked IPv6 support.

Yes, I've fought that fight a few times. IPv6 is not fully sinking in yet to be honest, I assume I'll get there at some point. Likely when I really have to because I've no option to avoid it.

Originally Posted by Olaf Barthel

You can blame only me for not testing the "-t" (timeout) "and "-o" (onereply) features on my Amiga 3000UX on which MuForce would have reported the problem immediately

Hindsight is always there, I've just spent a morning unpicking a mistake I made. The mistake took under ten seconds, the fix was near two hours The joys of software development

[idrougge]

Originally Posted by Olaf Barthel

I cleaned up the source code, which up until then had been almost unchanged since the year 2002. In preparation for coming attractions in the next "bsdsocket.library" version (haven't started working on those changes yet) I wrote new "online" and "offline" commands, which will be in the updated demo/retail archives, too.

How do those work as opposed to NetShutDown?

[Olaf Barthel]

Originally Posted by idrougge

How do those work as opposed to NetShutDown?

They serve very different purposes.

NetShutdown tries to shut down the network input/output operations performed by the TCP/IP stack without bothering to tell the network device drivers to also change their online/offline state.

Online/Offline talk to the network device drivers (link layer, OSI layer 2, etc.) only; you can have the TCP/IP stack running while the low level drivers are in offline mode.

Software which uses these network drivers, such as AmiTCP, Envoy and even Roadshow may request to be notified when the online status of the driver changes, so that they can react accordingly.

I rewrote the Online/Offline commands from scratch because no source code was available for the old versions, and the old versions weren't particularly nice in figuring out how to open the driver requested, and how errors were reported. Also, the old versions basically just sent the "driver, go offline" (and its counterpart) commands without waiting for the driver to either say "I'm already offline" or to confirm that the driver online status had changed.

[idrougge]

That's great, I've been hoping for such a command (as in AmiTCP) for temporarily disabling the network when running WHDload.