Roadshow 1.12 released

[Amiga_CDTV]

Ok, thanks Olaf. It's not really a problem but I have wondered why it does that.

I'll try to find out if I have anything running in the background that is using the network. Is there any easy way to log programs that have used the network?

[Rotzloeffel]

Originally Posted by Amiga_CDTV

Ok, thanks Olaf. It's not really a problem but I have wondered why it does that.

I'll try to find out if I have anything running in the background that is using the network. Is there any easy way to log programs that have used the network?

you can use scout from the aminet to show up all running Programs, processes and Tasks.... maybe you find out which one is the Problem

http://aminet.net/package/util/moni/Scout_os3

[idrougge]

AmiTCP has the "netstat" command; don't know if it works with Roadshow.

[Olaf Barthel]

Originally Posted by Amiga_CDTV

Ok, thanks Olaf. It's not really a problem but I have wondered why it does that.

I'll try to find out if I have anything running in the background that is using the network. Is there any easy way to log programs that have used the network?

No, I am afraid that there is no tool for logging this information yet. The "NetShutdown" command should be the logical, right place to show this information, I suppose. Maybe that could be added with a minimum off fuss.

Right now the interface between "NetShutdown" and the bsdsocket.library which allows the program to use the network, is very thin. "NetShutdown" can ask for the network to be shut down, and be notified when the last program to use the network has signed off, but it does not provide a useful list of programs which still have not quit yet.

[Olaf Barthel]

Originally Posted by idrougge

AmiTCP has the "netstat" command; don't know if it works with Roadshow.

It probably will not work with Roadshow. AmiTCP and Roadshow have a lot in common with regard to the TCP/IP stack code, which came from BSD Unix. But this only goes so far. AmiTCP is based upon BSD Unix networking code which is about 4-5 years older than what Roadshow uses.

How the AmiTCP commands, such as "netstat" and "route", access internal TCP/IP stack information or modify it, changed significantly by the time the TCP/IP stack used by Roadshow had become available.

[utri007]

Last night I installed roadshow to my CDTV.

Everything works just like it should. DHCP works, name resolution works and I can use AEXplorer to connect it. I have a Huawei 4g router wich shares WLAN to my house. Zyxel WLAN accesspoint connects to it and shares network with wire to it. CDTV has a plipbox device as a NIC.

One problems was that installer script installed a 68020 version of bsdsocket.library.

[Olaf Barthel]

Originally Posted by utri007

Last night I installed roadshow to my CDTV.

Everything works just like it should. DHCP works, name resolution works and I can use AEXplorer to connect it. I have a Huawei 4g router wich shares WLAN to my house. Zyxel WLAN accesspoint connects to it and shares network with wire to it. CDTV has a plipbox device as a NIC.

One problems was that installer script installed a 68020 version of bsdsocket.library.

Now that's weird.

You should have at least seen a prompt, to the effect whether you want to install the 68020 version or not.

Did you keep a log file? The installer creates this upon request.

[TuKo]

Hi,

Would it be possible to fix AddNetInterface to be really QUIET when using the QUIET parameter ?

It still outputs messages on error (for example: if my plipbox is not plugged in, it outputs something like [error]: Interface "plipbox" configuration failed).

Thanks in advance !

[Jope]

Originally Posted by TuKo

Would it be possible to fix AddNetInterface to be really QUIET when using the QUIET parameter ?

Did you try >nil: in the end?

[TuKo]

Originally Posted by Jope

Did you try >nil: in the end?

yes.

[Olaf Barthel]

Originally Posted by TuKo

Hi,

Would it be possible to fix AddNetInterface to be really QUIET when using the QUIET parameter ?

It still outputs messages on error (for example: if my plipbox is not plugged in, it outputs something like [error]: Interface "plipbox" configuration failed).

Thanks in advance !

This is a an error message which is produced by the part of Roadshow which deals with the actual interface configuration (it's in "bsdsocket.library").

The AddNetInterface command only tells "bsdsocket.library" to set up the network interface and then waits for it to conclude or fail. If it fails, then the error message is logged: a window opens which shows the message text.

You cannot keep that window from opening by telling AddNetInterface to keep quiet, as AddNetInterface is not the part of Roadshow which logs the message.

What can be done to keep the message from appearing is to start the NetLogViewer program before AddNetInterface is used (e.g. "Run >NIL: NetLogViewer CX_POPUP=NO"). Please give it a try

There's more information about logging these messages and how to deal with them in the manual, e.g. chapter 6, which covers troubleshooting.

[idrougge]

Olaf, do you have any hints regarding getting ch_nfsmount to work with the correct user/group under Roadshow?

[TuKo]

Originally Posted by Olaf Barthel

What can be done to keep the message from appearing is to start the NetLogViewer program before AddNetInterface is used (e.g. "Run >NIL: NetLogViewer CX_POPUP=NO"). Please give it a try

Worked like a charm ! Many thanks !

[Olaf Barthel]

Originally Posted by idrougge

Olaf, do you have any hints regarding getting ch_nfsmount to work with the correct user/group under Roadshow?

I admit that I haven't used "ch_nfsmount" in a very long time (must have been almost 20 years)... So please take the following with a grain of salt: it's based upon theory and not upon actual practice

There isn't much information which "ch_nfsmount" can wring out of the user/group API provided with Roadshow. The relevant file which everything hinges on should be "DEVS:Internet/users". Roadshow ships with the following file contents:

# $VER: users 1.1 (24.10.2010)
#
# This is the user database, which associates user names with
# numeric IDs, group numbers and a bunch of other information
# that is primarily of historic value.
#
# Each line in this file is read and parsed according to the
# following template:
#
# NAME/A,PASSWORD/K,UID/A/N,GID/A/N,GECOS,DIR,SHELL
#
# Note that this file is not strictly required for proper
# operation of the TCP/IP stack.
NAME=root UID=0 GID=0
NAME=nobody UID=65534 GID=65534

If I remember correctly, you'll need to tell the NFS server who you are (or pretend to be), along with the matching password, and which user and group ID values should be associated with the files/directories you may create or are permitted to access.

You need to find out which user and group ID values are associated with your NFS access. These are probably identical to your login information on the same server. The "id" shell command should tell you what to use, e.g.:

$ id
uid=1229(yourname) gid=1147(yourgroup) groups=1147(yourgroup)

Now plug that information into the "DEVS:Internet/users" file, adding another line at the end, like so:

NAME=yourname UID=1229 GID=1147

Save these changes back to disk, please.

The part of Roadshow which "ch_nfsmount" uses to figure out what user credentials to send to the remote NFS server has to know that it should be transmitting the data stored with the "NAME=yourname UID=1229 GID=1147" record. This is accomplished by setting an environment variable in the Amiga shell:

4.System:> SetEnv USER yourname

To make sure that the environment variable survives a reboot, follow this up with a copy command:

4.System:> Copy ENV:USER ENVARC:

You may want to restart your system now, because "ch_nfsmount" might be unable to pick up the user name you just configured from the part of Roadshow which manages it (there may still be stale information in memory, and restarting will take care of it).

Once the system has restarted and Roadshow is active again, check if the "USER" environment variable has stuck around:

4.System:> SetEnv
Kickstart
Workbench
USER
4.System:> Echo $USER
yourname

Now's the time when "ch_nfsmount" might actually work (if it didn't work before). Please give it a try

[idrougge]

@olsen:
That new DHCPUNICAST switch solved my problems getting a lease from the Cisco routers on my ISP (Bredbandsbolaget), but while DHCPUNICAST=YES works in the interface config file, it doesn't work with ConfigureNetInterface, because YES is not a valid key.

[ancalimon]

Where can I buy Roadshow with a credit card. I no longer have access to paypal and bank transfer costs around at least 50 Euros from Turkey.

[Sir_Lucas]

Originally Posted by ancalimon

Where can I buy Roadshow with a credit card. I no longer have access to paypal and bank transfer costs around at least 50 Euros from Turkey.

The only place that you can buy Roadshow from is here:
http://roadshow.apc-tcp.de/index-en.php

http://www.amigashop.org/product_inf...00&language=en

Simply write to them and ask if it's possible to pay by credit card.

[Olaf Barthel]

Originally Posted by idrougge

@olsen:
That new DHCPUNICAST switch solved my problems getting a lease from the Cisco routers on my ISP (Bredbandsbolaget), but while DHCPUNICAST=YES works in the interface config file, it doesn't work with ConfigureNetInterface, because YES is not a valid key.

Thank you, you are correct. There is a bug in the ConfigureNetInterface code caused by one of those ever popular "copy & paste" errors: instead of checking the "dhcpunicast" parameter, it checks the "debug" parameter

I'll fix it as soon as possible. A small update for Roadshow has been in the pipeline since late December last year. Just maybe I'll be able to make it happen before all the snow has melted

[idrougge]

Oh, I was just going to ask for a debug parameter as well. =)

BTW, shouldn't DHCPUNICAST be /S instead of /K?

[Olaf Barthel]

Originally Posted by idrougge

Oh, I was just going to ask for a debug parameter as well. =)

The DEBUG switch has been around for a while, but please do not expect a lot of useful information to come forth by enabling it. It merely switches the debug flag of the network interface on or off, and the results of that flag being enabled largely affect only how much "debug information" the TCP/IP stack kernel authors wanted to share, back in 1994.

The exception is the DHCP negotiation, which, with the debug flag enabled, will produce information on how the negotiation proceeds. I added this bit, and I do hope that it is actually useful

BTW, shouldn't DHCPUNICAST be /S instead of /K?

Yes, but then I probably would have named it "ENABLEDHCPUNICAST", which is a bit longer and doesn't exactly roll off your tongue

I tried to maintain consistency between the command line parameters and the icon tool types, for those few Roadshow commands which can be used both in the shell and as Workbench tools.

In my opinion it is easier get a good idea of what effect an option will have which reads as "DHCPUNICAST=ON" than of a single "DHCPUNICAST" keyword. For shell commands you can obtain the necessary context of what the single keyword does by entering "ConfigureNetInterface ?", but the same is not possible with icon tool types. Some people may check the manual, but as a rule, they tend to spend their time elsewhere, probably dissatisfied with the general usability of Roadshow

The shell is supposed to support "ON" and "OFF" flags with the /T option, but it did not work robustly in Kickstart 2.04. This is the other reason why it's DHCPUNICAST/K, and neither DHCPUNICAST/S nor DHCPUNICAST/T.