[smokeping-users] TCPPing probe doesn't generate data

[David Tomic]

G.W. Haywood wrote:
> Hi David,
>
> On Mon, 16 Jun 2008, David Tomic wrote:
>
>   
>> I've also made sure that all the relevant paths are correct.
>>     
>
> Are tcptraceroute and tcpping both in /usr/bin?
Yes.  To be really pedantic they're just symlinks in /usr/bin ... but
they're there, and they're working just fine.

>   What's the result of
> typing the commands
>
> which tcpping
>
> and
>
> which tcptraceroute
>
> ?
>   
david at david-desktop:~$ which tcpping
/usr/bin/tcpping
david at david-desktop:~$ which tcptraceroute
/usr/bin/tcptraceroute



> Does it say /usr/bin/tcpping in your 'Probes' configuration file?
>   

Yep.

*** Probes ***

+ TCPPing
binary = /usr/bin/tcpping
forks = 5
offset = 50%
step = 300
timeout = 15


> To be on the safe side I modified /usr/bin/tcpping so that the path
> /usr/bin/tcptraceroute is explicitly stated in the script and doesn't
> rely on some environment variable, which may or may not be set if you
> run the script automatically.
>   

Would that be in both the _checksite() & _testsite() sections?
>   
>>> Try commenting out all but the penultimate line there, so you have instead
>>>
>>> 8<----------------------------------------------------------------------
>>> #       if echo "${ttr}" | egrep "\[(open|closed)\]" >/dev/null 2>&1; then
>>> #               rtt=`echo "${ttr}" | awk '{print $5}'`
>>> #       else
>>>                 rtt=`echo "${ttr}" | awk '{print $4}'`
>>> #       fi
>>> 8<----------------------------------------------------------------------
>>>
>>>       
>> I've done that, but unfortunately it doesn't seem to have helped.
>>
>> Now when I execute tcpping myself, I'm not getting the latency figures
>> returned properly.
>>     
>
> That didn't work then.  But it proves that you're modifying the right file. :)
>   

I'll take that as a positive then! ;)
>   
>> There still doesn't seem to be any data being passed through to
>> smokeping either.  From 'smokeping --debug' I'm still just getting:
>>
>> 8<----------------------------------------------------------------------
>>
>> TCPPing: forks 5, timeout for each target 76
>> TCPPing: Executing /usr/bin/tcpping -C -x 5 203.16.214.17 80
>> TCPPing: Executing /usr/bin/tcpping -C -x 5 internode.on.net 80
>> TCPPing: 203.16.214.17: got
>> TCPPing: internode.on.net: got
>>
>> 8<----------------------------------------------------------------------
>>     
>
> It's just a matter of putting some debugging in there to see why the
> right information isn't going where it's supposed to go.
>
>   
>> I hope I'm correct in thinking that I shouldn't need to do anything
>> [beyond modifying tcpping] to actually have those changes take effect
>> within Smokeping.
>>     
>
> I'm sure you don't need to restart anything, this is just a bash script
> and it won't be cached anywhere like Perl scripts can be sometimes.
>   

Yes, that's what I thought.  I just wanted to make sure that I wasn't
doing something really simple/stupid that I should have been. ;)
>   
>> IE - Once I've modified/saved tcpping, then Smokeping should just
>> automatically pick up on the changes the next time it executes the
>> tcpping probe, correct?
>>     
>
> Yes, it will just execute the new script.  (Apparently it's doing
> that, because it fails in a different way, now. :)
>   
HOORAY! :P
>>> With these debug lines inserted, but without my modification (sorry,
>>> my nasty hack:), you'll see that the information you need moves from
>>> field to field, depending on how you specify the host to be pinged:
>>>
>>>       
>> ...
>> I've done that, and I'm getting the same sort of output as you, but [if
>> you'll pardon my ignorance] I'm still not really sure what that's
>> actually achieved?
>>     
>
> It's supposed to be telling you what the output from tcptraceroute
> looks like and which fields are which.  In my examples, fields 4 or 5
> might contain some number of milliseconds.  It's those numbers which
> we need to get back to Smokeping via tcpping.  Unfortunately, tcpping
> doesn't seem to be doing that.  It's supposed to decide whether to use
> field 4 or field 5 in the bit of code that was (mostly) commented out
> by my nasty hack.  We just need to know what's in the output from
> tcptraceroute, and if it looks right figure out why it isn't reaching
> Smokeping.
>   
What concerns me though, is that it appears that Smokeping doesn't seem
to be getting ANY information back.  If it was just a case of being sent
the *wrong* bit of information, then I could see how we'd have something
to work with.

The fact that it seems to be getting nothing at all though, has me just
a little bit worried.

> Let's step back a bit.
>
> Bash is a shell.  It's the thing you're using when you type commands.
> Probably.  You might be using a different shell, there are several to
> choose from.  Bash is very powerful.  You can write programs with it
> and run them from the command line.  A program written in the Bash
> 'scripting' language is called a script.  Bash scripts aren't very
> pretty.  I guess you know that by now. :)  Incidentally, when you run
> Bash itself you don't use the capital letter in its name.  Not 'Bash',
> but 'bash'.
>
> Bash scripts can call other scripts, system utilties, whatever they
> need to get the job done.  In general the user who invokes the script
> determines the permissions of the process(es) that execute, although
> there are ways around that.
>
> You have a Bash shell script called tcpping.  When you run it, it uses
> a utility called tcptraceroute to fetch some information.  It takes
> the output from tcptraceroute and parses it, that means it cuts out
> the bits that it wants (using a text processing utility called 'awk')
> and returns them to whatever program called it.  That program may be
> Smokeping, your command line shell, or whatever.
>   
That's fine ... I understand all of that! ;)

> There were two suggestions.
>
> The first was to make a modification to tcpping to cut out some of the
> code which parses the response from tcptraceroute.  That apparently
> failed because the problem you have is different from the problem I
> saw when I fetched the version of the tcptraceroute utility which
> Debian provides for Etch and used it with the tcpping that I have.
>
> The second suggestion was to put some print statements (the 'bash'
> shell print statement is called 'echo') into the tcpping script in an
> effort to find out what the script is seeing.  The bits of the script
> which contain the calls to awk are pulling out fields from the output
> from tcptraceroute.  Here are the debugging statements I used:
>
> echo "${ttr}"
>
> This first line prints a bash variable called ttr.  If you want to use
> the value of a bash variable you can wrap it in curly braces and put a
> dollar sign in front.  As I said, not pretty.  In the tcpping script,
> this variable has been set to the output from tcptraceroute, which is
> what we want to parse.  An example of the tcptraceroute output in my
> last mail is (excluding the quotes) "255 192.168.0.43 [open] 0.184 ms".
>
> echo ""
>
> This prints a blank line.  I just felt like it.
>
> echo "field 1 =" `echo "${ttr}" | awk '{print $1}'`
>
> Print the word "field" followed by the digit "1" and an equals sign
> followed by whatever happens when 'awk' pulls out the first field of
> its input, which in this case is whatever is in the variable ttr,
> which is 'piped' to awk (using the pipe character, '|').
>
> echo "field 2 =" `echo "${ttr}" | awk '{print $2}'`
> echo "field 3 =" `echo "${ttr}" | awk '{print $3}'`
> echo "field 4 =" `echo "${ttr}" | awk '{print $4}'`
> echo "field 5 =" `echo "${ttr}" | awk '{print $5}'`
> echo "field 6 =" `echo "${ttr}" | awk '{print $6}'`
>
> And so on, for five more fields.
>
> Why not post the output that you get?
>   
david at david-desktop:~$ /usr/bin/tcpping -C -x 5 internode.on.net 80
255  corp.internode.on.net (203.16.214.17) [open]  24.965 ms

field 1 = 255
field 2 = corp.internode.on.net
field 3 = (203.16.214.17)
field 4 = [open]
field 5 = 24.965
field 6 = ms
24.965255  corp.internode.on.net (203.16.214.17) [open]  24.291 ms

<and then repeat for the other 4 probes>

>   
>> I still don't seem to be getting any data sent through to smokeping?
>>     
>
> That's because it isn't fixed yet. :)
>   

Obviously ... HEHEHE :P

Thanks once again though.  That was a pretty herculean post you just
made! ;)