Roadshow 1.12 released

[AndreasM]

The Roadshow TCP/IP stack for the Amiga has been updated to version 1.12 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 1.11, upgrading it to version 1.12. Note: if you are still using Roadshow 1.8 you need to upgrade to version 1.11 first before you can upgrade it to version 1.12.

The changes in Roadshow 1.12 are as follows:

1. A buffer overflow bug has been fixed which could occur when
querying network interface hardware addresses. This bug could
cause the "ShowNetStatus" command to crash.

2. The ftp command has been reworked, fixing bugs which had been
present for years (buffer overflows, etc.).

3. Overlapping name resolution operations can no longer collide
with each other so easily and produce corrupt query data. This
problem could occur only very rarely.

4. New API functions for name resolution have been added, which are
common in the Unix world, for which no alternatives had been
available before. These enhancements are new for Amiga
TCP/IP software in general.

5. If Roadshow sets up a network interface using the DHCP protocol
it can now request that the DHCP server sends its responses
directly to Roadshow (unicast) instead of broadcasting them to
the local network.

6. Changing the system clock time (e.g. during daylight saving
time transitions) no longer affect Roadshow's internal
time keeping.

7. A new ready-made network configuration file for PCMCIA cards
using the "cnet16.device" driver is provided under
"Storage/NetInterfaces/CNet16").

8. The reference documentation has been updated.

More detailed descriptions of the changes can be found in the "ReadMe" file of the Roadshow archive, and the SDK archive.

http://roadshow.apc-tcp.de

[Locutus]

I just installed the Demo and noticed that the included `wget` is a bit b0rked. Minor bug and doesn't affect functionality but it might lead someone quickly trying out the demo to conclude its not working right.

See this screenshot:

[Sir_Lucas]

That's great news. One question. How to check which version I am using now? Is there a command to do so?

[Olaf Barthel]

Originally Posted by Locutus

I just installed the Demo and noticed that the included `wget` is a bit b0rked. Minor bug and doesn't affect functionality but it might lead someone quickly trying out the demo to conclude its not working right.

Could you be more specific as to what would need to be addressed?

The wget version included with Roadshow is a bit long in the tooth. Its purpose is, along with the ftp command, to allow for better versions of the wget and ftp commands to be installed by downloading these from AmiNet, for example. They are for "bootstrapping" the network installation, if you will.

As such, both commands are free of dependencies on libraries other than bsdsocket.library, of course. I believe the latest 68k port of the wget command does need ixemul.library to work, which is what I wanted to avoid. Roadshow is (as best as I could make it) self-contained.

[Olaf Barthel]

Originally Posted by Sir_Lucas

That's great news. One question. How to check which version I am using now? Is there a command to do so?

The "Version" command should do fine:

7.Build:net/roadshow> version c:wget full
wget 1.1 (04.12.2005)
Based upon GNU wget 1.10.1

[Locutus]

Originally Posted by Olaf Barthel

Could you be more specific as to what would need to be addressed?

The wget version included with Roadshow is a bit long in the tooth. Its purpose is, along with the ftp command, to allow for better versions of the wget and ftp commands to be installed by downloading these from AmiNet, for example. They are for "bootstrapping" the network installation, if you will.

As such, both commands are free of dependencies on libraries other than bsdsocket.library, of course. I believe the latest 68k port of the wget command does need ixemul.library to work, which is what I wanted to avoid. Roadshow is (as best as I could make it) self-contained.

Hi Olaf, the only thing wrong is the speed indicator. The actual transfer speed is fine. (shows 140B/s, while the real rate is ~600KB/s)

As i said tiny issue, but to a user it might look misleading when evaluating the demo. The first thing users will do is test speed after all :-)

[Olaf Barthel]

Originally Posted by Locutus

Hi Olaf, the only thing wrong is the speed indicator. The actual transfer speed is fine. (shows 140B/s, while the real rate is ~600KB/s)

As i said tiny issue, but to a user it might look misleading when evaluating the demo. The first thing users will do is test speed after all :-)

Thank you! I believe I may have found the cause of the problem: the timer resolution which the speed indicator uses is very coarse.

This wget version falls back onto using the time() function (in "ptimer.c") if it cannot use an operation system function which would deliver millisecond resolution.

I made a note to update the code.

[utri007]

Olaf: Could you say something about my problem. Some time ago, I changed my home router. After that all my amigas turn invisible to Network. Internet / name resolution etc. works, but I can't connect to my amigas, with AExplorer, Netmount, etc. All these worked before router change. There is no firewall on my router, just plain NAT. Situation is same with Ami TCP and Roadshow.

All Windows machines are OK.

[Sir_Lucas]

Originally Posted by Olaf Barthel

The "Version" command should do fine:

7.Build:net/roadshow> version c:wget full
wget 1.1 (04.12.2005)
Based upon GNU wget 1.10.1

Ahh, great!! Thanks for the quick info.

[Retrofan]

Many thanks for the update

[Olaf Barthel]

Originally Posted by utri007

Olaf: Could you say something about my problem. Some time ago, I changed my home router. After that all my amigas turn invisible to Network. Internet / name resolution etc. works, but I can't connect to my amigas, with AExplorer, Netmount, etc. All these worked before router change. There is no firewall on my router, just plain NAT. Situation is same with Ami TCP and Roadshow.

All Windows machines are OK.

I believe you already asked for assistance in different Amiga forums, concerning this problem. While I read it, I could not make head or tail of the situation, as you described it. Changing the home router all by itself should not lead to "segregation" of the network members.

This promises to be a hairy issue to get to the bottom of. Not that I'm shy to dive into this kind of situation (see my "smbfs" port, for example), but I'm a little reluctant to offer you advice without knowlege of a whole lot of ugly details about your network configuration.

Let's start with what exactly you mean by "Amigas turn invisible". The next question would be what Windows versions are involved. And the next one would be how much control you have over the home router, i.e. can you view the configuration in detail, make changes, etc?

[Olaf Barthel]

Originally Posted by Retrofan

Many thanks for the update

You're welcome If only it had not taken almost three years to get there...

[S0ulA55a551n]

Originally Posted by utri007

Olaf: Could you say something about my problem. Some time ago, I changed my home router. After that all my amigas turn invisible to Network. Internet / name resolution etc. works, but I can't connect to my amigas, with AExplorer, Netmount, etc. All these worked before router change. There is no firewall on my router, just plain NAT. Situation is same with Ami TCP and Roadshow.

All Windows machines are OK.

Do you mean you cannot connect to them via their IP addresss or their PC-names ?

[utri007]

Originally Posted by S0ulA55a551n

Do you mean you cannot connect to them via their IP addresss or their PC-names ?

AExplorer and netmount uses IP

Radmin's Advanced lan scanner doesn't found them. It found every other machine on my home lan. NAS, several windows machines and HP laserjet. Amigas, NAS and Laserjet uses static IP, others get IP from router's dhcp.

As I said, internet works, so no wrong subnet mask, no wrong gateway etc.

[Olaf Barthel]

Originally Posted by utri007

AExplorer and netmount uses IP

Radmin's Advanced lan scanner doesn't found them.

As far as I can tell, that program only looks for devices which use the same subnet as the Windows machine it is running on. Put another way, it cannot see devices in other subnets.

What the LAN scanner program does is quite straightforward. It sends a query to each server in the subnet, asking for the server's Ethernet hardware address to be provided for its IPv4 address (it sends ARP requests and briefly waits for responses to arrive). Once a response has arrived, it proceeds to connect to a select number of TCP ports on the server whose IPv4 address it just learned might be interesting. Which of these ports are currently accepting connection requests is reported, as well as which ports refused connection requests.

That's pretty much it. If a server on the same network as the Windows machine which performs these queries is up and running, then it might at least show up in the server list which the program shows. Even if no TCP ports accept connections, it would still be listed.

It found every other machine on my home lan. NAS, several windows machines and HP laserjet. Amigas, NAS and Laserjet uses static IP, others get IP from router's dhcp.

As I said, internet works, so no wrong subnet mask, no wrong gateway etc.

I doubt that this is the whole story. Given how the scanner program works, it appears likely to me that it does not report the Amigas because it really cannot find them. The reason why it cannot find them might be because they use a different IPv4 subnet. I am assuming that the missing Amigas are powered up, the TCP/IP stack is operational on each of them, and the networking hardware is connected to a switch where it can be expected to see the Windows machines.

Say, do you have Roadshow installed on at least one of those Amigas? Then you might be able to perform a test using the "tcpdump" command. This will work both for the demo version and the commercial version.

Begin by starting your Amiga, and make sure that the network is operational, using Roadshow. Then enter the following command in the shell:

tcpdump -D

It should print something like this, which are the network interface names it knows:

1.Ariadne
2.loopback

Please ignore the line which includes "loopback". Remember the name listed in the other entry, this being "Ariadne" in this example. You will probably see a different network interface name in its place.

Now enter the following command, replacing "Ariadne" with the network interface name which "tcpdump" just reported to you (see above):

tcpdump -i Ariadne -s 0 -e -vvv

Now start your network scan program and watch what happens on the Amiga which currently runs the "tcpdump" program. Something should be happening if the Amiga and your Windows computer are sharing the same IPv4 subnet.

These "tcpdump" command parameters do the following:

• "-i Ariadne" selects the network interface to listen to.
• "-s 0" tells the "tcpdump" command to capture each complete packet, and not just the first few bytes.
• "-e" requests that the Ethernet hardware address should be captured, too.
• "-vvv" enables maximum verbosity and most detailed output.

While the network scan is in progress, the very least you should be able to see would be lines which include "Broadcast, ethertype ARP (0x0806)" and "Request who-has".

If you cannot see even a single line with these keywords, then something's not configured configured correctly.

[TuKo]

Many thanks for the update ! Roadshow is imho the best TCP/IP stack today on 68k.

[utri007]

Originally Posted by Olaf Barthel

As far as I can tell, that program only looks for devices which use the same subnet as the Windows machine it is running on. Put another way, it cannot see devices in other subnets.

What the LAN scanner program does is quite straightforward. It sends a query to each server in the subnet, asking for the server's Ethernet hardware address to be provided for its IPv4 address (it sends ARP requests and briefly waits for responses to arrive). Once a response has arrived, it proceeds to connect to a select number of TCP ports on the server whose IPv4 address it just learned might be interesting. Which of these ports are currently accepting connection requests is reported, as well as which ports refused connection requests.

That's pretty much it. If a server on the same network as the Windows machine which performs these queries is up and running, then it might at least show up in the server list which the program shows. Even if no TCP ports accept connections, it would still be listed.

I doubt that this is the whole story. Given how the scanner program works, it appears likely to me that it does not report the Amigas because it really cannot find them. The reason why it cannot find them might be because they use a different IPv4 subnet. I am assuming that the missing Amigas are powered up, the TCP/IP stack is operational on each of them, and the networking hardware is connected to a switch where it can be expected to see the Windows machines.

LAN is 192.168.11.0/24
Subnet mask is 255.255.255.0
GW is 192.168.11.1
DHCP pool is 192.168.11.100-199
Amigas are .41 and .42

I do use your samba port all my networked amigas. Two 68k/OS3.9 and one PPC/OS4

Note everything worked before router change. I just got one theory, would i be possible, that router requires it to be used as a dns? Amigas use google public dns servers.? Need to test it.

Say, do you have Roadshow installed on at least one of those Amigas? Then you might be able to perform a test using the "tcpdump" command. This will work both for the demo version and the commercial version.

Begin by starting your Amiga, and make sure that the network is operational, using Roadshow. Then enter the following command in the shell:

tcpdump -D

It should print something like this, which are the network interface names it knows:

1.Ariadne
2.loopback

Please ignore the line which includes "loopback". Remember the name listed in the other entry, this being "Ariadne" in this example. You will probably see a different network interface name in its place.

Now enter the following command, replacing "Ariadne" with the network interface name which "tcpdump" just reported to you (see above):

tcpdump -i Ariadne -s 0 -e -vvv

Now start your network scan program and watch what happens on the Amiga which currently runs the "tcpdump" program. Something should be happening if the Amiga and your Windows computer are sharing the same IPv4 subnet.

These "tcpdump" command parameters do the following:

• "-i Ariadne" selects the network interface to listen to.
• "-s 0" tells the "tcpdump" command to capture each complete packet, and not just the first few bytes.
• "-e" requests that the Ethernet hardware address should be captured, too.
• "-vvv" enables maximum verbosity and most detailed output.

While the network scan is in progress, the very least you should be able to see would be lines which include "Broadcast, ethertype ARP (0x0806)" and "Request who-has".

If you cannot see even a single line with these keywords, then something's not configured configured correctly.

I used Roadshow some days and then reverted back to Genesis. Bought it mostly for support reasons. GUI just makes things easier.

I can reinstall it, or is so that I just removed it from DEVS?

[wXR]

Hi Olaf,

I never tried a TCP/IP stack on the Amiga before, and this looks like a good opportunity. Thanks for your efforts. One question though, where is the source repository for Roadshow? I didn't find it linked from your web site.

[Olaf Barthel]

Originally Posted by utri007

LAN is 192.168.11.0/24
Subnet mask is 255.255.255.0
GW is 192.168.11.1
DHCP pool is 192.168.11.100-199
Amigas are .41 and .42

I do use your samba port all my networked amigas. Two 68k/OS3.9 and one PPC/OS4

Note everything worked before router change. I just got one theory, would i be possible, that router requires it to be used as a dns? Amigas use google public dns servers.? Need to test it.

I consider this unlikely. You stated that the LAN scanner program could not find the Amigas, and all of this without resorting to DNS-based name resolution in the first place. Samba conveniently side-steps the DNS issue because it uses its own NetBIOS-based name resolution process.

I used Roadshow some days and then reverted back to Genesis. Bought it mostly for support reasons. GUI just makes things easier.

I can reinstall it, or is so that I just removed it from DEVS?

You may reinstall and try it as many times as you like. There are no hidden pitfalls (and none in plain sight either). The only limitation which the demonstration version has is in that it will shut down operations after having been active for a while.

As for removing the demonstration version: the installation script can be used to uninstall the software cleanly (save for the stub added to the "S:User-Startup" script, but that could be done manually with little effort).

[Olaf Barthel]

Originally Posted by wXR

Hi Olaf,

I never tried a TCP/IP stack on the Amiga before, and this looks like a good opportunity. Thanks for your efforts. One question though, where is the source repository for Roadshow? I didn't find it linked from your web site.

The source code repository for Roadshow resides on a private server which I maintain all by myself. Although the code is built upon the open source 4.4BSD-Lite2 TCP/IP stack, Roadshow and its parts are a commercial, closed source project. It's probably one of the last few Amiga software projects of its kind.

Some source code is available in the form of the Roadshow SDK, which includes (among other material) the Amiga-specific header files for 'C' language software development, as well as the full Amiga-specific source code for the utilities that ship with Roadshow. As required by the GPLv2 license, full source code for the Amiga ports of "wget" and "libpcap" & "tcpdump" is included, too. I chose not to include the "ftp" client command source code (which is derived from the same 4.4BSD-Lite2 code as the TCP/IP stack), because it's so ugly and old that probably the only purpose it could serve today would be to discourage developing "ftp" client commands in 'C'