Moitor serial input and tcp utput

[Jens Grønfeldt]

Hi I'm still nubi with Linux.

Could you guide me in direktion of how I can monitor the input and the output of the Kplex.
So I don't have to wait to Marine Traffic turn my Anntenna Red :-(

Here is how my config looks

serial]
filename=/dev/ttyUSB0
direction=in
baud=38400
[tcp]
address=5.9.207.224
port=XXXX
persist=yes
direction=out
keepalive=yes
ofilter=+AIVDM:-all
[tcp]
mode=server
port=10110

Thanks in advance

Jens in Frederikshan Dk

[Keith Young]

If I misunderstood your question, please correct me :-)

With the configuration you have there, the simplest test to see whether data are coming into kplex is to connect to the  server you have defined in your configuration.  If you have the telnet command installed you can try this:

telnet localhost 10110

Hopefully you should see some data.

To exit telnet, hold down the CTRL key and hit the ] key, then at the telnet prompt type "quit" and it return.

Alternatively you can just use kplex from the command line:

kplex -f- file: tcp:address=localhost

That says don't use the config file ("-f-") use stdin/stdout as one interface (i.e. the terminal) and connect to a tcp server on the default port on the loopback interface.

This doesn't confirm you're connected to marine traffic though.  One way to do that is using the "netstat" command. 

netstat -an |grep 5.9.207.224

...should, if you have a connection, give you a line with "tcp" in the first column 5.9.207.224:XXXX (where "XXXX" is your port in the config file above) and ESTABLISHED in the last column.  To check whether there is data flowing you'd need to use wireshark or tcpdump...we can talk about that if you need to.

If you start kplex with the "-d3" option it should log a message to facility LOG_DAEMON when kelp attempts to reconnect a dropped persistent connection.  The file that ends up in depends on your configuration which often depends on the flavour of Linux. It's generally in /var/log nut might be "syslog", "messages" and/or "daemon.log".

One (minor) thought: If you add:

nodelay=no

to the definition of your interface to marine traffic you might fractionally cut down on your Internet data use. By default kplex turns off the Nagle algorithm which tcp uses to consolidate multiple short packets sent in quick succession into one. That improves latency on a LAN, but on a WAN minimising data use is normal preferable to minimising latency.

[Jens Grønfeldt]

 Thank for the answer !

kplex -f- file: tcp:address=localhost

when you refer to "file" is that kplex.conf?
How does telnet knows witch ip address localhost point to? On less you mean telnet on the rasberry, locally?

[Keith Young]

Once again forgive me if I'm telling you things you already know: Where I'm not sure what you mean I'm answering everything I think you *could* mean :-)

when you refer to "file" is that kplex.conf?

The "-f" command line argument tells kplex which configuration file to use. If you don't say "-f", it will use its standard locations (the .kplex.conf in your home directory if that exists, otherwise /etc/kplex.conf).  So if you said:

-f /etc/myotherfile

 Then kplex would look for /etc/myotherfile for its configuration and add everything else on the command line to that.

"-" is a special value for -f which means "don't use any config file".  So if you say "-f-" on the command line it says "don't use any configuration file, just use the arguments on the command line.

On the command line you specify each interface type, followed by a colon, followed by comma separated options. "file:" says use a "file" interface, but because there's no options after the ":", it means use all the defaults for this type.  The default "file:" interface is the terminal (standard in/out).  So this just says use the terminal as one "interface" (the tcp connection is the other).

How does telnet knows witch ip address localhost point to?

Because you didn't tell kplex *which* ip address to listen on, the tcp server will be listening on all your machine's network interfaces.  This includes the loopback interface which is on a special "internal" interface.  "localhost" is a hostname you'll find on many different operating systems configured in the hosts file (/etc/hosts on linux: have a look).  It resolves to an IPv4 address of 127.0.0.1 and, where configured, an IPv6 address of ::1.  These interfaces will exist as interfaces on the loopback network ("ifconfig -a" which lists all network interfaces will show you this as something like "lo" or "lo0" depending on OS).

On less you mean telnet on the rasberry, locally?

Yes.  Alternatively you could try to telnet to port 10110 on the pi (if that's where kplex is running) 

[Jens Grønfeldt]

Hi Keith

So far the Kplex is running ok.

Is there a way to force it to use Wlan0? As I'll like to palace it on the loft and don't have any lan connectios there only wireless.

regards
Jens

[Keith Young]

Is there a way to force it to use Wlan0? As I'll like to palace it on the loft and don't have any lan connectios there only wireless.

The answer is "yes" but with your configuration it shouldn't be necessary.  How you connect to marinetraffic  is determined by your computer's routing table.  If your computer is connected only via wifi on wlan0 then that should normally be your default route.  If you're connected via dhcp and you don't have a default route set, look at your dhcp settings ("routers" option). If you've configured wlan0 manually make sure you have a "gateway" configured for it in your interfaces file (assuming a debian-based linux).

You tcp server should be listening on all configured network interfaces unless you specify a particular interface.

Normally the only time you really need to specify an interface is if you're doing udp broadcast or multicast on the LAN side of a router or if you only want to allow connections on a particular interface.

[Jens Grønfeldt]

Hi Keith
here I go again.

I managed to get Kplex going and transmitting data to marinetraffic, at a point it stops transmitting, I can't figure out what stops it.
I've tried to monitor Kplex with "top","ps -el" and other commands, but no joy.
Any ideas? I'am still useing the kplex.conf below.

Regards
Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

I managed to get Kplex going and transmitting data to marinetraffic, at a point it stops transmitting, I can't figure out what stops it.
I've tried to monitor Kplex with "top","ps -el" and other commands, but no joy.

Does it stop transmitting to marine traffic, stop transmitting *anything* (including via the tcp server) or does it just die?

Anything in the log files?

[Jens Grønfeldt]

Hi Keith

When my marine antenna turns red I run the "netstat -an | igrep 5.9.204.224", to see if I sends. I also tried the "top" and "pidof kplex" to see if Kplex is running. What I found out is that kplex stops sending to 5.9.204.224 but is still activ acording to pidof kplex.
If I could do any thing to make a log file, I would be delighted to if you could direct me in that way.

Regards

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

If I could do any thing to make a log file, I would be delighted to if you could direct me in that way.

kplex logs to facility LOG_DAEMON.  I'm not near a raspberry pi at the moment to remind myself of where that goes to on a default Raspbian install.  Maybe /var/log/daemon.log?  It'll be something in /var/log.

Try running kplex with -d3 and when/if it stops sending to marine traffic grep for kplex in daemon.log (or wherever LOG_DAEMON gets logged to)

[Jens Grønfeldt]

Hi Keith

I've tired maney things with the pi get it running seedy with the kplex, sometimes it would be running for 24 hrs sometimes only 2 hrs!
I've started it with "kplex -d3 -f /etc/kplex.conf" and I attathed a logfile and the kplex.conf files
I've installed the openCPN to monitor local ais tracks, they are on openCPN when I start kplex, but after a while the diapers from the program. I get the following on the pi screen "Kplex debug: New TCP connectionrecived by(no name) from 192.168.1.31"
Then 2 timese "Kplex Debug: Cleaning up data for exitning interface(no name)"

Regards
Jens

    

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Jens Grønfeldt]

Ps. The Kplex DEBUG write some hex code, whith I don't remember later on, properly when stops sending to marine traffic you will get when it pops up :-((
jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Jens Grønfeldt]

I've installed the openCPN to monitor local ais tracks, they are on openCPN when I start kplex, but after a while the diapers from the program. I get the following on the pi screen "Kplex debug: New TCP connectionrecived by(no name) from 192.168.1.31"
Then 2 timese "Kplex Debug: Cleaning up data for exitning interface(no name)"

After some more "monitoring" the two lines above does not necessary occur when kplex stops sending to openCPN and marine traffic.

Regards
Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

Sorry not to give a full reply: a bit wiped out after spending a day in dentist's chair.

It would be helpful to name your interfaces so that we know which ones are exiting (instead of "noname")

under the serial definition in kplex.conf put:

name=serial

under the marine traffic interface put:

name=mtraffic

and under the server put something like:

name=tcpserv

I'm surprised that you got output to the terminal and that there's nothing in daemon.log unless you're running kplex in the foreground (are you?).  I'm not near a pi to check what the default syslog configuration is.

[Keith Young]

Having checked my copy...daemon.log is where kplex should normally syslog to so I'm guessing you're running kplex in the foreground?

It seems to be the case that at least some of the kplex interfaces are shutting down.  We need to find out which ones and why.  Note that kplex won't persist in trying network connections under all conditions.  If a required network device goes away completely (e.g. the cable to your USB hub is pulled out so a wireless interface vanishes) for instance, kplex will give up on that device.

[Jens Grønfeldt]

Hi Keith

Yesterday I made a new install of jessy and of cause reinstalled the kplex, got names in the kplex.conf
what should I do to make kplex run in the background?
I attatch some screen pictures

regards

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

Yesterday I made a new install of jessy and of cause reinstalled the kplex, got names in the kplex.conf
what should I do to make kplex run in the background?

 Thanks for the pics.  The "cleaning up..." messages are from connections to the kplex tcp server.  They come in pairs because the write side and the read side both report when they exit.  In the third picture you can see a message telling us that kplex managed to reconnect to marine traffic which means that (a) the connection was previously unconnected at some point and (b) that reconnection is still working.

The "dropped senblk" messages would be because kplex can't send on one of its interfaces (probably, but not necessarily, the marine traffic one) and it's backlog is overflowing.  If the marine traffic connection was the only problem you'd expect them to stop after the reconnection.  Sadly the debug message identifies them by an address rather than the interface name to which the queue applies: I'll have to change that.

You make kplex run in the background by giving it the "-o background" option.  This is given if you start it using the startup script which is installed with the .deb or  with the kplex.init file supplied with the source.

When run in the background debug data is logged using syslog, so we get a timestamp on it too

[Jens Grønfeldt]

Hi Keith

I tried to start kplex like this "kplex -d3 -f /etc/kplex.conf -o background"

And got this amswer "Badly formatted opttion background"

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

I tried to start kplex like this "kplex -d3 -f /etc/kplex.conf -o background"

My apologies.  That should have been "-o mode=background".  Sorry for the bad information.

This is how kplex is started if using the init script in the .deb. 

[Jens Grønfeldt]

Hi Keith

I'v have now some log files to trace...I don't know why but I have a felling that it is the serial to usb interface that makes the trouble. I have another serial that I could attach to the Pi, but there't a lot of places where you shall disable ttyAMA0 to make it work for kplex.

Season Greadings

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

In some (but not all) of these you seem to have a general problem with USB: serial and network interfaces seem to exit about the same time.  Have you got up-to-date firmware on your pi?  I used to have bad problems with USB hanging before I updated the firmware.  I don't see any reconnections to marine traffic which makes me think that something must have happened like the network interface you're using completely going away rather than just the connection being dropped.  I must improve the debugging here.  USB problems could cause that.

Is it deliberate that the same machine makes lots of short connections to the TCP server or is there some problem there?

there't a lot of places where you shall disable ttyAMA0 to make it work for kplex.

It's not that onerous.  Just two places: /boot/cmdline.txt and a quick edit of /etc/inittab

[Keith Young]

That's odd: I can't see anywhere that the Marine Traffic interface, if properly configured to be persistent, would exit with -d3 without printing a message (it was just a brief look so I could be wrong).

May I check which version of kplex you're using ("kplex -V" will tell you)

[Jens Grønfeldt]

HI Keith
My kplex says 1.3.1

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Jens Grønfeldt]

Hi Keith

Probem still perstsist, any good ideas? You can my marinetraffic Station id 825, Fredrikshavn Dk

I send some new logfiles.

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

Sorry for no updates for a while: not been doing much over the holiday.

I see a few places in the logs where the marine traffic interface fails and is then reconnecting.    That could be a problem in the path to marinetraffic and you'd expect data flow to be restored when it reconnected.

Looking at marinetraffic, it only seems to tell me when your connection has been up in the last 24 hours (am I looking at it wrong?).  I also note that I have no debugging in the kplex code to tell me when kplex is shutting down, and the "starting up" debugging message doesn't go to the same place as other messages.

Consequently I don't know when from these logs the times at which kplex started and stopped and when data was flowing or not flowing.

I've started putting some more debugging in.  Would you be able to pull code from github and compile it (when I've finished it, possibly tomorrow?).  We could then run that, possibly in parallel with a continuous ping of the marinetraffic server so we know when the network has obvious problems and when kplex is starting and stopping.

One more thing....with "persist=yes" kplex won't start up if your network connection is down.   If you specify "persist=fromstart" kplex won't give up trying if it can't make a tcp connection on startup

[Jens Grønfeldt]

Hi Keith

Just saw your answer now!

I put the "persist=fromstart" in the kplex.conf

I'll give the github  a try when the code is ready.

Jens

Den torsdag den 5. november 2015 kl. 18.33.24 UTC+1 skrev Jens Grønfeldt:

[Keith Young]

I'll give the github  a try when the code is ready.

There's a bit more debugging in the tcp code now and those dropped senblk messages I've raised to level 4 so at level 3 we should be able to get the important debugging without spurious dropped senblk messages.

Running some sort of script which prints the date (to tie things up with the syslog messages) and the result of ping -c1 5.9.207.224 to a file every few seconds might help us see if there's a significant network problem happening.

Today's coding performed with "Station to Station" as the soundtrack :-(

[Keith Young]

...in the develop branch if I didn't make that clear.  Let me know if you don't have the facilities to compile from git.

[Jens Grønfeldt]

Hi

Questions before I start compiling

1. Do I have to uninstall the present kplex? Or does the compiled one get a new name?
2. I tried the ping -c1 5.9.207.224 and got this: "ping: icmp open socket: Operation not permitted"What does that mean?

[Keith Young]

1. Do I have to uninstall the present kplex? Or does the compiled one get a new name?

You've got a few choices.  You can compile the binary but not install it (i.e. don't do "make install") and run it from a different directory (e.g. the one you compile it in using "./kplex" instead of "kplex").  You could move the existing /usr/bin/kplex to /usr/bin/kplex.orig before doing "make; sudo make install" (which would install a new /usr/bin/kplex) then later re-install the old version with "sudo mv /usr/bin/kplex.orig /usr/bin/kplex".  Or a couple of other possibilities (but those would be my top two).

2. I tried the ping -c1 5.9.207.224 and got this: "ping: icmp open socket: Operation not permitted"What does that mean?

The normal reason would be that the ping command isn't set userid root.  creation of an icmp socket is a privileged operation.  Normal users can't normally do that.  The ping command on most unixen is installed with permissions which allow the command to be run with root's privileges when invoked by a normal user.  Try:

ls -l `which ping`

the listing should start something like:

-rwsr-xr-x 1 root root

If the initial "-rws" is instead "-rwx" or the first "root" is something else, ping *may* be installed with the wrong permissions (which would then beg the question "why?")

Alternatively try "sudo ping -c1 5.9.207.224"  which will run the command with root privileges.

[Jens Grønfeldt]

I managed to compile the kplex and it is running, should I clear the log files?
I made a sudo ping -f 5.0.207.224 > output.txt
Jens

[Keith Young]

I managed to compile the kplex and it is running, should I clear the log files?

You could. Or you could note the time, grep out the kplex messages later and we'll only look at the ones after the start time

 

I made a sudo ping -f 5.0.207.224 > output.txt

Are you sure you want to do a flood ping (-f)?  Possibly not. The point of putting the repeated date in there was to get a timestamp after every ping 

[Jens Grønfeldt]

I am reading in my linux book about grep, what should I look for?
And how should I ping?

Jens

[Keith Young]

I am reading in my linux book about grep, what should I look for?

Ah.  Basic tool in the *nix armoury for extracting lines which match a particular pattern from a text file.  Type "man grep" on your linux box for a full explanation (but we can get to that later...)

And how should I ping?

write a script something like this:

#!/bin/sh

STATE=START

date +"START %D %T"

while /bin/true

do

    if ping -c 1 8.8.8.8 > /dev/null

    then

        [ "$STATE" = "UP" ] || date +"UP %D %T"

        STATE=UP

    else

        [ "$STATE" = "DOWN" ] || date +"DOWN %D %T"

        STATE=DOWN

    fi

    sleep 2

done 

Obviously adjust the sleep for a time which suits you. You might want less if you have an expensive GSM connection.

Did you figure out if your ping command is set uid root and if not why not?

[Jens Grønfeldt]

Hi

I did the ping script, called pping, should it have an extension name? when trying to execut I get "-bash: pping command not found" or should be in a different dir?

I did a sudo u+s which ping to get rid of sudo ping...  

[Keith Young]

I did the ping script, called pping, should it have an extension name? when trying to execut I get "-bash: pping command not found" or should be in a different dir?

No need for an extension.  Normally the current directory is not included in your search path as a security measure. If you've put execute permissions on the script file you can invoke it by calling:

./pping

If not you can invoke "sh" (which should be in your path) with the script as an argument:

sh pping

...But you might want to redirect the output to a file.  And you might want to run it in the background and disconnect from the terminal in case you want to log out of the terminal you're invoking it from.  e.g.:

nohup sh pping > /tmp/monitorfile 2>&1 &

 

[Jens Grønfeldt]

Hi still struck-ling with the ping script i send a copy of how it looks.

[Keith Young]

Hi still struck-ling with the ping script i send a copy of how it looks.

Instead of:

["$STATE = "DOWN" ] || date +"DOWN %D %T"

use

[ "$STATE" = "DOWN" ] || date +"DOWN %D %T"

The space between [ and " matters and the " needs a matching " after $STATE

[Jens Grønfeldt]

After correction the "" below I did  the "nohup sh pping > /tmp/monitorfile 2>&1 &" is only writhing one time in the monitorfile: "nohup: ignoring input new line START 01/25/16 16:54:33 new line UP 01/25/16 16:54:33

Shut I not expect more lines in monitorfile?
Jens

[Keith Young]

After correction the "" below I did  the "nohup sh pping > /tmp/monitorfile 2>&1 &" is only writhing one time in the monitorfile: "nohup: ignoring input new line START 01/25/16 16:54:33 new line UP 01/25/16 16:54:33

Shut I not expect more lines in monitorfile?

You could re-write it to put in a status check every 10 mins or so but as it stands it only writes something when the state changes (i.e. UP->DOWN or vice versa).  You can test it by turning off your router temporarily.

[Jens Grønfeldt]

How?

[Keith Young]

How?

 One way would be this:
define a period between "mark" points in seconds, so for 10 mins use 600.  Add the following after the initial #!/bin/sh line:
MARKINTERVAL=600
NOW=`date +%s`
MARKTIME=`expr $NOW + $MARKINTERVAL`

This sets "$NOW" to be the time in seconds since the epoch, and "$MARKTIME" (the time at which we will next print a message) to be NOW+10 mins (600 seconds).  After every ping we'll compare MARKTIME with the current time in seconds since the epoch.  If it's time to print a message we do so and calculate a new MARKTIME.  Insert the following just before the sleep statement in the old script:
    if [ $NOW -ge $MARKTIME ]
    then
        date +"MARK %D %T"
        MARKTIME=`expr $NOW + $MARKINTERVAL`
    fi

Well...that's one way to do it anyway (may contain typos :-)

[Keith Young]

MARKTIME=`expr $NOW + $MARKINTERVAL`

And yes yes shell arithmetic is much easier if you exploit bash rather than restricting yourself to the capabilities of the Bourne shell of 30 years ago...

[Jens Grønfeldt]

Hi Keith

I think the problem is solved it's been running for more a week whiteout hickups, I brought a new usb to serial wire. There are perhaps differences on these PL-2203 chips?

Thank you for you're patience's

Jens