A failure to communicate [Closed]

[rodgoslin]

I'm sure that this is something simple, but, it's certainly aggravating me. I have two desktop machines, in most respects they're identical. I built the second after a calamitous disk failure, and decided to make it, as far as possible, duplicate the first. Since time has moved on since building the first machine, I decided to set the second machine with a GPT disk. That didn't work out (See the thread on booting from GPT). So, the second machine now has the OS installed on a 500MB drive and /home on the GPT drive, and all works very well. In fact, until the GPT thing I was busy populating up using Unison, slow but sure
Now the problem. Neither machine will nowtalk to the other by the usual protocols. Let us call the two machines 'up' and 'down'. Using Filezilla, up returns an attempt to connect with down with ""Could not connect to server", down's answer is the same. Connecting to down from up with SSH returns "No route to host" to up. From down, the return is "Timed out". Ping from up to down, "Host unreachable". From down to up, nothing. On both machines, in services from the Control Centre, proftpd and sshd are enabled and running. In 'Security' , on both, SSH,FTP,Ping servers options are ticked.
I've never had this problem before, from installation, generally, communications have run smoothly. My learning in the field when I had to do this for a living, is, in general, still in the days of hosts.allow, etc, and security was attained by not connecting to anything not in the office environment

[boombaby]

Hello, rodgoslin...

Others better at networks than me will respond soon, I guess - but some initial thoughts are:

* Are you talking about (fantastic) Mageia? (I assume - from the "Control Centre" reference - you are.)
* Is firewall running? Shut down the firewall for now. (Disconnect your cabes from Net first of course.)
* Are you connecting PC's through a switch? Basic or Managed? (My initial thought was a cable/socket/device issue.)
* Make sure in MCC (Mageia Control Centre) the firewall is off, and doublecheck that any appropriate net services are running.
* Double check your IP settings/route.

That's where I would start, based on what you "communicated".

Sorry; that's all I've got now.
boombaby.

[wintpe]

OK as boombaby has alread suggested start with dropping firewall, we can bring it back up later.

all systems talk to one another via the router or default gateway, if they are not on the same network.

how do they know they are on the same network, the ipaddress combined with the netmask.

so usualy at home we use 192.168.1.1-192.168.1.254 for hosts on our network, thats very common.

for two hosts on that network to see each other in that range they have to have a netmask of 255.255.255.0 or /24 as some people
use.
this means that the 0 represents the segment that is hosts, and the 255 triplet which part is the network.

similarly a 255.255.254.0 would mean 192.168.1.1-192.168.2.254

and 255.255.255.128 would mean 1 network 192.168.1.1 - 192.168.1.127 and another at 192.168.1.128 - 192.168.1.254.

anyhow just a little off topic to understand the network setup parts and the importance of them.

the command traceroute uses icmp to trace the hops between hosts to show how it got there.

it does this by starting with a really low time to live and keep on trying to get to the destination, increasing the time to live each time, and each time the time to live expires reporting how far it got, until finaly the ttl is long enough to let it get to the detination.

so traceroute 192.168.1.25 from 192.168.1.24 should only show one host.

if it does not check what your default route is set to.

netstat -rn will report that.

then the systems that you are talking to once you have established that they can ping each other (ping also uses icmp like traceroute) need to be running the service that you want to connect on, and by default mageia does not install sshd, the server component to ssh.

urpmi sshd

systemctl enable sshd

systemctl start sshd

ps -ef|grep sshd.

hope thats enough of a refresher to enable you to solve this problem

and then allow it via the firewall when configuring the firewall.

regards peter

[morgano]

Restarted the router? ( i need to do that here a couple times a year...)
Changed cables? ( i once scrapped a working printer, to next month realise the new also did not work - until i used a new cable...)
Can you browse to the routers administration page from both machines?

[rodgoslin]

Phew, Thanks for the prompt response. I should point out that the hardware is unchanged from the time when it worked fine. The only change has been to re-build the up machine. As a pair of PC's they work fine at all normal things, browsing, printing, access as an SMB share with my Drobo-fs server (at least, for reading, on up, I've not yet tried to write files to it) I can ping the gateway, printers, etc. The problem is getting the two machines to accept the other. I suppose I could boot up the Thinkpad laptop and make it a threesome, for added complication!

[doktor5000]

The only change has been to re-build the up machine.

Which is a substantial change, you might have forgotten a few small changes here and there. Like name resolution, DHCP / IP configuration, routing and last but not least firewall configuration.

Apart from that, Peter gave quite a lot of suggestions, but you didn't seem to follow up and post details on any of those so far - there's just so much others can do remotely without proper information ...

[rodgoslin]

I thought that I had added sufficient information. I pointed out that each machine was completely normal to most things, i.e. I could access the internet from each, print to either of my LAN connected printers, access the Drobo-fs, so both had to be on the same LAN. I can ping the obvious destinations, gateway, printers, DNS, Drobo-fs from both. Again both machines are on the same LAN. IP configuration, naturally is OK. I did point out the salient points of security settings, in the Control Centre. The hosts file for both machines accords, and is up to date. In any case addressing by IP fails too.. I think that that pretty well covers name resolution, DHCP/IP configuration, and firewall configuration. Routing I've never had reason to configure, when things went well. If I had the information to solve the problem, then it probably would not be a problem. Since I do not know the required information, I would expect to be asked for it.

[morgano]

Try something simple: set firewall off in both machines, set static IP, reboot them and see if they can ping each other.

[rodgoslin]

I tried that. The result was exactly the same. In fact, I tried FTP and SSH, too and they still do not work, up to down and down to up. One minor point, I'll throw in. On booting up, I hit 'escape' during the boot, to see if anything strange was happening during the boot sequence. There was one item. starting the network manager failed, due to dependency failure, but I can't see this affecting anything, since all other network functions on printers, router, internet access, Drobo NAT all work. I think the next thing to do is to scrub the OS and start again. I'm getting quite used to this. I must have installed Mga5 about twenty times, on various machines, since it came out.

[wintpe]

Rod
your doing something wrong if you need to re-install 20 times, i install mine just once, every two years and it works 100%
I think you need to start sharing with us the output of some commands to help you.

we all run inside a NAT private lan so all our lans look exactly the same.

theres nothing you share that will expose your internals we can all guess them.

on each host open a terminal, su to root and run the following

ifconfig -a

netstat -rn

make sure the hosts firewall is set to allow everything for now

run iptables -L to prove thats the case.

and ps -ef|grep sshd

and netstat -a|grep sshd

and from one host to another

traceroute the other

regards peter

[rodgoslin]

Peter, this for up to down. I noticed that the install had not installed sshd (apache-sshd), so instaleld it. It made no change to the situation, however. As you requested responses to commands, follows.

Code: Select all

[root@up rod]# ifconfig -a
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.202  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::f279:59ff:fe5e:5b2d  prefixlen 64  scopeid 0x20<link>
        ether f0:79:59:5e:5b:2d  txqueuelen 1000  (Ethernet)
        RX packets 3333  bytes 2599516 (2.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2739  bytes 448179 (437.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 310  bytes 97927 (95.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 310  bytes 97927 (95.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp0s19f2u1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:e0:4c:be:cd:8a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 35  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



Code: Select all

[root@up rod]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.150   0.0.0.0         UG        0 0          0 enp3s0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 enp3s0
[root@up rod]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination     

Code: Select all

[root@up rod]# ps -ef|grep sshd
root      1397     1  0 00:35 ?        00:00:00 /usr/sbin/sshd -D
root      6541  5101  0 01:29 pts/1    00:00:00 grep --color sshd


Code: Select all

[root@up rod]# netstat -a | grep sshd

There was no response to this command although services and daemons indicates that sshd is running, as shown above

Code: Select all

[root@up rod]# traceroute 192.168.1.200
traceroute to 192.168.1.200 (192.168.1.200), 30 hops max, 60 byte packets
 1  up.local (192.168.1.202)  3005.817 ms !H  3005.770 ms !H  3005.764 ms !H


Twenty (odd) installs isn't all that bad. Down is my main machine, whilst up was used for trying out other new releases, other distros, updates, etc. In addition there's another machine, an Acer, which I bought when I had a catastrophic disk failure, which has turned out to be such a pile of junk, that it sits in the spare bedroom gathering dust. Then in the past two years there have been a couple of Thinkpads. One of venerable age and the other less so. Too, there are a couple of ASUS netbooks, too nice to throw away. It, too has not been a good year. I fitted a new motherboard to one of the machines, to replace an old one, of a higher spec, only to see the other machines mobo fail. Then there have been two disk failures. Of late I've had a couple of lockups which seem to stem from VLC, which leave the machine totally locked up. Even the screen clock stops. After the forcible power down, fsck has been unable to restore the machine to a bootable state. And then there was the amusing occasion, on a re-build when I discovered that I'd accidentally used a 32 bit version of Mageia, instead of the 64 bit install disk, that I'd intended.

I'll do down some time later, in the same fashion. I submitted a bug report on the failure to boot from a GPT disk, which has now been resolved. It would appear that Mageia is one of the systems that requires a separate boot partition to function properly, and I'm toying with going back and doing the job properly.

Rod

[rodgoslin]

Peter, dunno why it slipped my memory. In respect of 'up' both openssh-clients and openssh-server are installed but in services there was no option for sshd until I installed apache ssh.

Rod

[rodgoslin]

Peter, this is the other half of the duo, down.

Code: Select all

[root@down rod]# ifconfig -a
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.200  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::2e56:dcff:fed3:6fa3  prefixlen 64  scopeid 0x20<link>
        ether 2c:56:dc:d3:6f:a3  txqueuelen 1000  (Ethernet)
        RX packets 11359833  bytes 2710150380 (2.5 GiB)
        RX errors 0  dropped 10  overruns 0  frame 0
        TX packets 15271139  bytes 13221149048 (12.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 25282  bytes 7804205 (7.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25282  bytes 7804205 (7.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.150   0.0.0.0         UG        0 0          0 enp4s0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp4s0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 enp4s0


Code: Select all

[root@down rod]# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Code: Select all

[root@down rod]# ps -ef|grep sshd
root       642   356  0 19:27 pts/1    00:00:00 grep --color sshd
root      1502     1  0 Jul31 ?        00:00:00 /usr/sbin/sshd -D

Code: Select all

[root@down rod]# netstat -a|grep sshd

As with up, there was no response to this command

Code: Select all

[root@down rod]# traceroute up
traceroute to up (192.168.1.202), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C


Hope this helps.

Rod

[doktor5000]

Please show the output as root of

Code: Select all

systemctl status sshd.service -al -n150
journalctl -ab|grep -i ssh

If this is a fresh install, did you check the hostkeys? Maybe https://bugs.mageia.org/show_bug.cgi?id=20618 is still present in some form ?

[rodgoslin]

Doktor, Yes. This is a fresh install on 'up'

Code: Select all

[root@up rod]# systemctl status sshd.service -al -n150
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Wed 2017-08-02 00:35:29 BST; 22h ago
 Main PID: 1397 (sshd)
   CGroup: /system.slice/sshd.service
           └─1397 /usr/sbin/sshd -D

Aug 02 00:35:30 up sshd[1397]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Aug 02 00:35:30 up sshd[1397]: Server listening on :: port 22.
[root@up rod]# journalctl -ab|grep -i ssh
Aug 02 00:26:46 up avahi-daemon[806]: Loading service file /services/openssh.service.
Aug 02 00:26:46 up avahi-daemon[806]: Loading service file /services/ssh.service.
Aug 02 00:26:47 up avahi-daemon[806]: Service "up" (/services/ssh.service) successfully established.
Aug 02 00:26:47 up avahi-daemon[806]: Service "Remote Access on up" (/services/openssh.service) successfully established.
Aug 02 00:35:29 up xinetd[1352]: Reading included configuration file: /etc/xinetd.d/sshd-xinetd [file=/etc/xinetd.d/sshd-xinetd] [line=16]
Aug 02 00:35:30 up sshd[1397]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Aug 02 00:35:30 up sshd[1397]: Server listening on :: port 22.
Aug 02 00:35:31 up systemd[1]: Failed to start Dropbear SSH Server Daemon.
                                        apache apache-mod_perl boa lighttpd thttpd bind dnsmasq mydsn openssh-server ftp-server-krb5 wu-ftpd proftpd pure-ftpd dhcp-server udhcpd sendmail postfix qmail exim imap courier-imap-pop telnet-server-krb5 nfs-utils nfs-utils-clients samba-server bacula-fd bacula-sd bacula-dir-common rsyslog syslog-ng cups mysql postgresql8.2 postgresql8.3 avahi cups openslp bittorrent deluge ktorrent transmission vuze rtorrent ctorrent synce-hal
Aug 02 01:13:19 up drakfirewall[4538]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 01:13:28 up drakfirewall[4538]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 01:21:21 up drakxservices[5440]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 01:21:22 up drakxservices[5440]: running: /bin/systemctl --quiet is-active sshd.service
Aug 02 01:24:54 up [RPM][5835]: install apache-sshd-0.11.0-3.mga5.noarch: success
Aug 02 01:25:18 up drakxservices[5962]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 01:25:19 up drakxservices[5962]: running: /bin/systemctl --quiet is-active sshd.service
Aug 02 01:51:31 up drakxservices[7546]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 01:51:32 up drakxservices[7546]: running: /bin/systemctl --quiet is-active sshd.service
                                        apache apache-mod_perl boa lighttpd thttpd bind dnsmasq mydsn openssh-server ftp-server-krb5 wu-ftpd proftpd pure-ftpd dhcp-server udhcpd sendmail postfix qmail exim imap courier-imap-pop telnet-server-krb5 nfs-utils nfs-utils-clients samba-server bacula-fd bacula-sd bacula-dir-common rsyslog syslog-ng cups mysql postgresql8.2 postgresql8.3 avahi cups openslp bittorrent deluge ktorrent transmission vuze rtorrent ctorrent synce-hal
Aug 02 02:31:23 up drakfirewall[9455]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 02:31:31 up drakfirewall[9455]: running: /bin/systemctl --quiet is-enabled sshd.service
Aug 02 04:02:10 up msec[15149]: tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      xinetd
Aug 02 04:02:10 up msec[15162]: tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      sshd
Aug 02 04:02:10 up msec[15228]: -   Added processes with open network ports : tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      sshd
Aug 02 04:02:10 up msec[15255]: - Removed processes with open network ports : tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      dropbear


[doktor5000]

Aug 02 00:35:30 up sshd[1397]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Aug 02 00:35:30 up sshd[1397]: Server listening on :: port 22.

[...]

Aug 02 00:35:31 up systemd[1]: Failed to start Dropbear SSH Server Daemon.

Well, this is pretty obvious, isn't it ? sshd is only listenting on your IPv6 loopback, and you're running a second sshd server (dropbear) which also fails to start.
Check what's using port 22, and disable dropbear + maybe stop xinetd for now.

[rodgoslin]

Before we go too far in establishing that ssh does not work, and why. It does work, but not between these two machines From another machines ssh is fine in either direction, to and from up. At least, in so far as logging in and establishing that I am actually connected to the machine I intended to connect to.

[wintpe]

the netstat -a|grep sshd, maybe should have been

netstat -a|grep ssh

just checked /etc/services, minor mistake of mine.

the use of a default gateway of 192.168.1.150 is while not wrong, odd.

are you sure thats your adsl hub, only most people put it on 192.168.1.1 or 254

your routing tables look OK ie normal

the traceroute of down from up is good 192.168.1.200

the traceroute of up from down is bad, so that means even with 5 increases in TTL it still did not find a host thats on the same network.

thats a bit damming.

I see the output from iptables is different on each host, even though they suggest that its allowing inp

so down still has a policy in place of drop, thats not what i asked you to try.

whereas up has a disabled firewall.

make sure the firewall is disabled on both.

otherwise we get skewed results.

regards peter

[rodgoslin]

Sorry Peter. Do you want me to repeat the commands with BOTH set at DMZ?
The command netstat -a|grep ssh returns:-

Code: Select all

[root@down rod]# netstat -a |grep ssh
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
[root@down rod]# netstat -a |grep sshd
[root@down rod]#


This from down to up (with both at DMZ).

The gateway address is a bit odd, but it's been that for years. The whole subnet used to be a lot odder. I had an old print server which we'd thrown out at work, which no-one could remember what password had been applied to it. So the network had to have the same subnet address as the print server! 192.0.0.x as I remember. It stayed that way, long after the print server had died, until I bought something which had an unchangeable subnet address. So I'm back with everybody else.

Rod

[wintpe]

i did not understand what you meant with both set at dmz.

what i was suggesting is one of them, you have not totally disabled iptables and that might be skewing the result.

anyway your ssh daemons look fine, its the fact you cant traceroute that's the issue we need to focus on.

please make sure both iptables are off.

on down it is still in play the other is not.

regards peter

[arnesp]

the traceroute of down from up is good 192.168.1.200

That's what I thought at first glance, but actually it shows "up" (192.168.1.202) as first hop while it should have been the destination: "down" (192.168.1.200).
Does the traceroute finish after outputting only the first hop line ?

The turnaround time of almost exactly 3 seconds is also strange.

Since the destination is on same IP subnet, "up" should just determine the MAC address of "down" (by looking it up in the ARP table or performing Address Resolution, if not found there), and then forward the IP package package to the determined address.

What is the output of the arp command on "up", just after execution of the traceroute command?
There should be just one line containing IP address 192.168.1.200, and which should associate it with the MAC address of "down" (2c:56:dc:d3:6f:a3)

/Arne

[rodgoslin]

Sorry, arnesp, for the delay in replying. had lots of things on for the last few days. arp is new to me. From this machine, 'down' to up the following comes up:-

Code: Select all

[root@down rod]# traceroute up
traceroute to up (192.168.1.202), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@down rod]# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
Transporter              ether   fc:2a:54:00:39:d1   C                     enp4s0
drobo-fs                 ether   00:1a:62:03:4a:ad   C                     enp4s0
up                       ether   f0:79:59:5e:5b:2d   C                     enp4s0
router                   ether   20:0c:c8:28:fe:6c   C                     enp4s0
192.168.1.250            ether   02:0f:b5:22:d2:92   C                     enp4s0


. Up is still only partly built. ping, ssh and ftp are not it's only problems.It refuses to boot in the normal way. There's another thread on that, and a bugzilla report.The upshot of that is that under uefi, it seems for some builds that a separate boot partition is required. Something I gave up as wasted space, long ago. So I rebuilt it as a single 4TB drive and created a boot partition. With the result that nothing has changed, it still will not boot. It can be booted, but only by putting in the installer disk and taking the option to boot from the hard drive. at that it boots beautifully, but other things intruded, including a failed drive on one of my Drobo's. Not much of a problem until I looked for a disk of the appropriate size. Anyway 'up' is up, but a bit short of software, yet. But lo and behold both ping and ssh work. At least they work with down as the target. But not down to up, but that may be the problem with daemons not being enabled (hopefully). My main attention at the mo' is with a part complete fttp installation. Hey, it's only been four and a half years, since the exchange was fibre enabled, and only recently has the fibre crept over the last mile to the village. At the present stage, the installers have claimed a total outdoor installation and an acceptable light signal, despite the device at which the test is conducted, the Customer Splice Point has not been installed, the cable (it's an overhead installation) still dangling in the breeze. It's not helping when my ISP contact is unaware of the difference between a ADSL modem and an ONT (Optical Network Terminal). I'll try to get back into sorting out the recent semi-install.

Cheers, Rod Goslin

[rodgoslin]

I'm closing this thread, since the problem has gone away! I've no idea what caused it, and what was the solution.. I tried pretty well all the suggestions, but nothing pointed to the cause. In the end, I simply blew away the entire OS, and rebuilt from scratch. I've done it so often in the past that I now have a tick list of what needs to be done and what settings are required. And it was an instant solution. Ping, ftp and ssh all work to all destinations,out of the box, as it were, in both directions. I would have liked to know where the problem lay, but a working setup is the next best thing. Thanks, everyone for the help and advice.

Cheers, Rod Goslin