oztoppy Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 2      1   2   Next
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #1 
I'm sorry to bother you again. I seem to be having a bad day.

Since this morning, when I regained network access to my 2460, it has been able to communicate with my 7160 through TMSClient only, not through TMSServer. What I mean by that is that the 2460 can read and play file on the 7160, but this is no longer possible in the other direction. The 7160 does not detect the server running on the 2460.

I have checked the settings in case they corrupted, and they are as I have always set them. The only difference I can see between the configurations of the two is that, for some reason, the RPC Port Mapper seems to be running twice on the 7160's list of servers.

Both units are currently accessible through all protocols, including HTTP and FTP.

Something to add, here: the log file shows that the 7160 actually is getting, and processing, packets from the 2460. However, there is no mount-point letting me access it, in any of the categories (recordings, media, etc.)


2017-12-16 12:42:07 Got 48 octets of data from socket {69} [0].
2017-12-16 12:42:07 Got 'Alive' from '000E9E07A226' (LoungeRoom2460). 1/6000 ticks since the last status.
2017-12-16 12:42:25 checkBroadcast(): Received 156 octets from '10.1.1.78'.
2017-12-16 12:42:25 checkBroadcast(): Packet is from TMSServer.
2017-12-16 12:42:25 My packet [10.1.1.78 = 10.1.1.78], ignoring.
2017-12-16 12:42:29 askAlive(): Asking server 'LoungeRoom2460' [0] {69} if it is still alive.
2017-12-16 12:42:29 readActiveServers()
2017-12-16 12:42:29 Got 48 octets of data from socket {69} [0].
2017-12-16 12:42:29 Got 'Alive' from '000E9E07A226' (LoungeRoom2460). 2210/6000 ticks since the last status.
2017-12-16 12:42:37 checkBroadcast(): Received 97 octets from '10.1.1.24'.
2017-12-16 12:42:37 checkBroadcast(): Packet is from TMSServer.
2017-12-16 12:42:37 Not my packet [10.1.1.78 != 10.1.1.24], processing!
2017-12-16 12:42:37 Server IniqueID = '000E9E07A226'.
2017-12-16 12:42:37 Searching for server ID '000E9E07A226'.
2017-12-16 12:42:37 Server ID '000E9E07A226' found in slot 0.
2017-12-16 12:42:37 readActiveServers()
2017-12-16 12:42:37 Got 48 octets of data from socket {69} [0].
2017-12-16 12:42:37 Got 'Alive' from '000E9E07A226' (LoungeRoom2460). 0/6000 ticks since the last status.

0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 258
Reply with quote  #2 
Make sure that TMSServer and TMSClient on both PVRs are using the same port number.

I'd turn the logging on and see what's written there.  TMSServer advertises its presence and TMClient receives these packets and connects to TMSServer automatically.  Having the logging on will show you the sequence of which PVR sends/receives which date.  If there are existing log files, delete/rename them so that you start with a clean log.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #3 
I have been watching the logs. The communication between packets seems normal.

However, I think I've found the problem (but not the solution). I noticed from the 7160 logs that there is no reference to an NFS service. On the 7160, the NFS server is always running, but on the 2460 there was a bypass file in place (which I didn't put there). I deleted the bypass file, and started the service, but it just shuts itself down again every time I do. This is probably a side-effect of the problems I was having earlier. How do I recover from this? Do I need to reinstall TMSServer?
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 258
Reply with quote  #4 
Re-installation sounds easier.  Before you do, check that RPC is running.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #5 
RPC is running. Do you mean to leave it running while I reinstall?
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 258
Reply with quote  #6 
No, running at the same time as NFS.

If you choose to re-install, stop the TAPs and then rename the directories or copy them to your PC as a backup.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #7 
This was a bit of a guess, but I deleted any .start.bypass files for every service, then replaced the ones I need. Actually, I'd forgotten about this, but I've had similar trouble for a long time with the alternate FTP and Telnet servers; I start them, and they stop themselves.

The connection seems two-way and stable again. Is it possible that the code lost track of where there were and weren't bypasses?
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #8 
Spoke too soon, as I often do. A bypass file for NFS keeps reappearing without my permission. I guess I'll need to try the reinstallation.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #9 
I've shut down and restarted about five times now, and the NFS server has run every time. I'm still having trouble with the FTP and Telnet services; it is very odd, because they seem to run independently of my commands. I put a bypass file in for the Busybox Telnet, and it starts automatically anyway; I click play on the FTP server, and it deletes its bypass file but refuses to run. I've been ignoring this problem so long I forgot I had it.

I'm going to leave out the reinstallation for awhile, and keep an eye on this. I'll let you know if anything new comes to light.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #10 
Does portmap need to be the first script loaded?
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 258
Reply with quote  #11 
Yes, you will notice in the default TMSServer installation that the script file controlling it is "000-portmap.control".  This is so that it is executed first.  NFS is controlled by 040-unfds.control".  TMSServer scripts are executed alphabetically.  You will also notice that the shutdown script for RPC is "zzz-portmp.shutdown", the very last service to be stopped.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #12 
Hmm. It was the zzz- script that tipped me off. I have one script that I really prefer to be at the top of the list, but it does not start automatically. I'm assuming it's OK to leave just that one alphabetically before the port mapper. However, I also have one more before it, so I'll move it now to see if that solves my problems.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #13 
Do the other supplied scripts depend on any particular order or sequence? The reason I ask is because it seems like whenever I activate FTP88 or Telnetd, not only do those scripts take on the wrong status, but they cause others (like NFS) to take on the wrong status, too. However, I've checked their code, in case I accidentally changed it, and none of them seem to be checking each other's PIDs, or anything silly like that.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 258
Reply with quote  #14 
From memory, only NFS relies on RPC, but I could be wrong.

If I understand correctly, you have made some modifications to existing scripts and/or added new scripts.  If this is the case, there are numerous users across the world for which the bundled scripts work without a problem.  The first step should be to return your installation to the default state and see if your problems still occur.  If there are no problems, you can introduce your changes one by one to see where the problem arises.

On the issue of scripts, ensure that they use the Linux EOL marker and not the DOS EOL markers.  I have see the PVR encounter difficulties running scripts with DOC EOL markers.
0
keith_leitch

Senior Member
Registered:
Posts: 546
Reply with quote  #15 
I've added new scripts. While I've peeked into the supplied scripts, I haven't made any changes to them... except for the possibility of that happening unintentionally, which is why I checked them over. No problem with the EOL marker. I am using an appropriate editor.

I agree that a reinstallation would probably resolve everything, and I will do that. Right now, I'm mostly curious. I've realised this:

Running a TAP can fool one of the control scripts into thinking a service is running, due to a similar PID. An example of this is when I run the TMSTelnetd TAP, as I usually do when working with scripts. The Busybox Telnet control script then finds a name like the one it is looking for in the PID list, and returns a "1" result. I've been scratching my head over this for a long time, so I'm glad to have checked it out.

I also discovered that one of my control scripts was exiting without returning a result. Once I fixed this, the behaviour was much more predictable.

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.