Roadshow 1.12 released

[olsen]

Does this work with ioblix ethernet? Dont see any config file

I do not know if it works, but a configuration file would look something like this (save the contents as a text file by the name of "IOBlix" and move that file into the "DEVS:NetInterface" drawer, then restart your Amiga):

# $VER: IOBlix 1.1 (12.10.2016)
#
# Configuration for the optional Ethernet hardware add-on
# for the IOBlix serial/parallel card, using the
# "ioblixether.device" driver (http://aminet.net/driver/other/IOBlixUsr.lha)

# The device name is mandatory
device=ioblixether.device

# If not provided, unit number 0 will be used. You may
# have to change this if there are multiple cards of the
# same type installed in your machine, or if your network
# hardware supports several independent connections
#unit=0

# You must either pick a fixed (static) IPv4 address and
# a corresponding subnet mask, or request DHCP (dynamic)
# network address configuration.
# You can combine address/netmask/dhcp, which has the effect
# of asking the DHCP server to assign the requested IPv4
# address and subnet mask to this interface, if possible.
#address=192.168.0.1
#netmask=255.255.255.0
configure=dhcp

# If no DHCP server is present in your network, you can
# use automatic interface IPv4 address assignment through
# the ZeroConf protocol. Note that this will not set up
# default route and DNS servers for you, only the interface
# address is configured.
#configure=auto

# This variant of automatic IPv4 address assignment should
# be used in a wireless network instead of 'configure=auto'
#configure=fastauto

# You can enable diagnostic messages which can be helpful in
# tracking down configuration errors.
#debug=yes

# You can choose how much memory will be used when handling
# incoming and outgoing network traffic for this device.
# The default is to reserve 32 buffers of 1500 byte each, both
# inbound and outbound traffic. Larger values may provide
# better performance.
#iprequests=32
#writerequests=32

# For diagnostic and monitoring purposes it can be helpful to
# capture network traffic that flows through this interface.
# To enable this option, select one of filter=local,
# filter=ipandarp or filter=everything
#filter=local
#filter=ipandarp
#filter=everything

# This option disables a workaround required for the Ariadne
# network hardware, which, if enabled, would otherwise cause
# the interface setup procedure to take longer than really
# necessary.
requiresinitdelay=no

[olsen]

I'm just now planning on updating my 1.9 version from 2013. I can find a 1.11 update and 1.12 update, but no 1.10 update. Is there such a thing?

Also, am I correct in assuming I need to run the updates in order? I didn't want to update to 1.11 before I receive confirmation that there's no 1.10 update.

Thanks.

Unless I made a very embarrassing mistake (wouldn't be the first time, mind you), you should be fine applying first the 1.11 update, and then the 1.12 update. Note: you cannot directly apply the 1.12 update to the 1.9 installation and must apply the 1.11 update before the 1.12 update can be used.

The 1.11 patch files modify the ftp command and bsdsocket.library (well, there's a set of patches for the ppp ethernet/serial device drivers, but I reckon you aren't using them - hardly anybody does).

The 1.12 patch contains another update for the ftp command and bsdsocket.library, with new patches thrown in for the AddNetInterface and ConfigureNetInterface commands.

You might want to make backups of these files before you use the upgrades. The commands can be found in "C:", and the library is stored in "LIBS:".

The patch process might not report failed upgrade attempts well. After applying the 1.11 patch, please check if the files I mentioned have indeed been modified (look at the respective file modification times first, but you can also use "version c:ftp full" and "version libs:bsdsocket.library file full").

[olsen]

Well, I am - serial port is still the most universally available option for all Amiga systems, and these days I build ARM systems (pi zero) inside all my Amiga computers, Roadshow works great with PPP over serial

I'm glad that the PPP drivers are still useful

Writing them turned out to be both easier and harder than expected. The PPP design is well-documented, but in the early 2000's so many different "server-side" PPP implementations were in use that you were in for a lot of surprises writing an implementation from scratch.

I bought James Carlson's book "PPP design, implementation and debugging" in November 2001 because it seemed to be the right thing to do, and it was: it shows in painful detail how many PPP implementation options were deployed and discarded during the IETF standardization process. Features which were only briefly used in-house, or showed up in an RFC which was quickly "obsoleted" by a newer RFC document were still in use around 2001-2002. PPP "client-side" code had to be aware of these "quirks".

It is not at all obvious what version of bsdsocket.library etc that belong to what version of Roadshow - it would be nice if all files, in addition to their own revisions numbers, could have "version full" strings that say something about version of Roadshow they belong to.

Good point. Roadshow is still very much what it was (except with fewer bugs) when it became a stand-alone product in 2013.

The library version of "bsdsocket.library" as the central core of the TCP/IP stack cannot be conveniently changed during each Roadshow release, with each Roadshow file (commands, scripts, configuration files) then getting bumped to use the same version. This worked for Commodore (V37 = Workbench/Kickstart 2.04, V38 = Workbench 2.1, V39 = Workbench/Kickstart 3.0, V40 = Workbench/Kickstart 3.1), but I can't use the same approach.

I'll likely have to go with adding extra information to the version text embedded in each file.