bug binkd/2 "incoming from" line

[mark lewis]

Binkd 1.1a-49 (Feb 3 2014 01:00:12/OS2)
Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound,
bwlim.
Facilities: fsp1035 rfc2553emu


while working with a perl log analyzer script that just would not run (the
output was all zeros) on my OS/2 system, i discovered that it was looking at
the "incoming from" log lines for the IP number in ()s...

- 07:17 [191] incoming from 76.188.39.96 (1604)
- 07:23 [191] incoming from 24.74.103.142 (50765)
- 07:29 [191] incoming from 71.68.29.241 (1474)

on linux and windows, the above lines look like

- 07:17 [191] incoming from 76.188.39.96 (76.188.39.96)
- 07:23 [191] incoming from 24.74.103.142 (24.74.103.142)
- 07:29 [191] incoming from 71.68.29.241 (71.68.29.241)

the problem is the random number in the ()s instead of the IP... i checked and
i cannot find any relationship between the numbers and the IPs... the numbers
are never the same for the same IP, either... i have backresolve disabled and
enabling it does not change the output in the ()s... backresolv appears to
affect only the "incoming session with" lines as well as reducing DNS
lookups...

i would not have discovered this bug if i had not been determined to figure out
why the script wasn't working... a quick hack to the script for it pull the IP
from the first location in the line immediately resulted in the script working
as desired and displaying sensible statistics instead of all zeros...

can someone please take a look at this bug and repair it?

thanks for your time! ;)

)\/(ark

[Wilfred van Velzen]

Hi mark,

On 2014-03-14 07:22:21, you wrote to all:

ml> Binkd 1.1a-49 (Feb 3 2014 01:00:12/OS2)
ml> Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm,
ml> amiga_4d_outbound, bwlim.
ml> Facilities: fsp1035 rfc2553emu

ml> while working with a perl log analyzer script that just would not run
ml> (the output was all zeros) on my OS/2 system, i discovered that it was
ml> looking at the "incoming from" log lines for the IP number in ()s...

ml> - 07:17 [191] incoming from 76.188.39.96 (1604)
ml> - 07:23 [191] incoming from 24.74.103.142 (50765)
ml> - 07:29 [191] incoming from 71.68.29.241 (1474)

ml> on linux and windows, the above lines look like

ml> - 07:17 [191] incoming from 76.188.39.96 (76.188.39.96)
ml> - 07:23 [191] incoming from 24.74.103.142 (24.74.103.142)
ml> - 07:29 [191] incoming from 71.68.29.241 (71.68.29.241)

ml> the problem is the random number in the ()s instead of the IP... i checked
ml> and i cannot find any relationship between the numbers and the IPs... the
ml> numbers are never the same for the same IP, either... i have backresolve
ml> disabled and enabling it does not change the output in the ()s...
ml> backresolv appears to affect only the "incoming session with" lines as
ml> well
ml> as reducing DNS lookups...

My linux version (which is the same as your os/2 version), has the same log
lines as your os/2 version.

I suspect the number is the source's port number.

With what linux and windows versions did you test this? It seems strange to
repeat between () what is already there in the log line.
So this might be behaviour that has changed (=fixed) in recent binkd versions?

ml> i would not have discovered this bug if i had not been determined to
ml> figure out why the script wasn't working... a quick hack to the script
ml> for it pull the IP from the first location in the line immediately
ml> resulted in the script working as desired and displaying sensible
ml> statistics instead of all zeros...

It might not be a bug, but a new feature ... ;)

ml> can someone please take a look at this bug and repair it?

... So it doesn't necessarily need repair.


Bye, Wilfred.

[Wilfred van Velzen]

Hi mark,

On 2014-03-14 13:26:11, I wrote to you:

ml>> Binkd 1.1a-49 (Feb 3 2014 01:00:12/OS2)
ml>> Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm,
ml>> amiga_4d_outbound, bwlim.
ml>> Facilities: fsp1035 rfc2553emu

ml>> while working with a perl log analyzer script that just would not run
ml>> (the output was all zeros) on my OS/2 system, i discovered that it was
ml>> looking at the "incoming from" log lines for the IP number in ()s...

ml>> - 07:17 [191] incoming from 76.188.39.96 (1604)
ml>> - 07:23 [191] incoming from 24.74.103.142 (50765)
ml>> - 07:29 [191] incoming from 71.68.29.241 (1474)

ml>> on linux and windows, the above lines look like

ml>> - 07:17 [191] incoming from 76.188.39.96 (76.188.39.96)
ml>> - 07:23 [191] incoming from 24.74.103.142 (24.74.103.142)
ml>> - 07:29 [191] incoming from 71.68.29.241 (71.68.29.241)

ml>> the problem is the random number in the ()s instead of the IP... i
ml>> checked and i cannot find any relationship between the numbers and the
ml>> IPs... the numbers are never the same for the same IP, either... i
ml>> have backresolve disabled and enabling it does not change the output
ml>> in the ()s... backresolv appears to affect only the "incoming session
ml>> with" lines as well as reducing DNS lookups...

WvV> My linux version (which is the same as your os/2 version), has the same
WvV> log
WvV> lines as your os/2 version.

WvV> I suspect the number is the source's port number.

WvV> With what linux and windows versions did you test this? It seems strange
WvV> to
WvV> repeat between () what is already there in the log line. So this might be
WvV> behaviour that has changed (=fixed) in recent binkd versions?

ml>> i would not have discovered this bug if i had not been determined to
ml>> figure out why the script wasn't working... a quick hack to the script
ml>> for it pull the IP from the first location in the line immediately
ml>> resulted in the script working as desired and displaying sensible
ml>> statistics instead of all zeros...

WvV> It might not be a bug, but a new feature ... ;)

ml>> can someone please take a look at this bug and repair it?

WvV> ... So it doesn't necessarily need repair.

I dug a little bit deeper and investigated the code that generates this line.
It seemed to have changed a lot the last couple of years, here are a few
iterations:


* $Id: server.c,v 2.43 2009/05/31 07:16:17 gul Exp $

get_hostname(&client_addr, host, sizeof(host), config->backresolv);
lockhostsem();
Log (3, "incoming from %s (%s)", host,
inet_ntoa (client_addr.sin_addr));
releasehostsem();


* $Id: server.c,v 2.44 2012/01/03 17:25:32 green Exp $

getnameinfo((struct sockaddr *)&client_addr, client_addr_len,
host, sizeof(host), service, sizeof(service),
NI_NUMERICSERV | (config->backresolv ? 0 : NI_NUMERICHOST));
Log (3, "incoming from %s (%s)", host, service);


* $Id: server.c,v 2.53 2012/01/08 19:18:03 green Exp $
...
* $Id: server.c,v 2.58 2014/02/02 07:46:47 gul Exp $

/* never resolve name in here, will be done during session */
aiErr = getnameinfo((struct sockaddr *)&client_addr, client_addr_len,
host, sizeof(host), service, sizeof(service),
NI_NUMERICHOST | NI_NUMERICSERV);
if (aiErr == 0)
Log (3, "incoming from %s (%s)", host, service);


So my suspicion about it being the sources portnumber is correct in the latest
version. But indeed the behaviour changed. But this seems intentional and not a
bug...


Bye, Wilfred.

[mark lewis]

On Fri, 14 Mar 2014, Wilfred van Velzen wrote to mark lewis:

ml>> can someone please take a look at this bug and repair it?

WvV> ... So it doesn't necessarily need repair.

WvV> I dug a little bit deeper and investigated the code that generates
WvV> this line. It seemed to have changed a lot the last couple of
WvV> years, here are a few iterations:

[trim]

THANKS!! i don't know where yuo found it but thanks muchly for doing the
digging and leg work :)

WvV> So my suspicion about it being the sources portnumber is correct
WvV> in the latest version. But indeed the behaviour changed. But this
WvV> seems intentional and not a bug...

good deal! now i feel better knowing that my hacking on the script is not in
vain and i don't have to worry about remembering to restore the previous
behavoir when a new version of binkd/2 comes out ;)

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Wilfred van Velzen]

Hi,

On 2014-03-14 13:38:51, mark lewis wrote to Wilfred van Velzen:
about: "bug binkd/2 "incoming from" line":

WvV>> I dug a little bit deeper and investigated the code that generates
WvV>> this line. It seemed to have changed a lot the last couple of
WvV>> years, here are a few iterations:

ml> [trim]

ml> THANKS!! i don't know where yuo found it but thanks muchly for doing the
ml> digging and leg work :)

It wasn't difficult at all. I have the binkd code already checked out from the
cvs repository on my machine, the only thing I did, was another checkout to get
the latest.
Then I did a search on "incoming from" in all the source files, and found the
spot in server.c right away. After that it was just going through the history
for those lines in that file from cvs, and copy paste what I found to the
message I was writing to you... ;)

This was on a windows (7) machine. The tools I used are:
TortoiseCVS for accessing the cvs repository and selecting versions of server.c
from the cvs history.
TotalCommanders text search function.
WinMerge (integrated into TortoiseCVS) for doing text file compares.

WvV>> So my suspicion about it being the sources portnumber is correct
WvV>> in the latest version. But indeed the behaviour changed. But this
WvV>> seems intentional and not a bug...

ml> good deal! now i feel better knowing that my hacking on the script is not
ml> in vain and i don't have to worry about remembering to restore the
ml> previous
ml> behavoir when a new version of binkd/2 comes out ;)

Indeed, the best way to fix this is, update the script to the newer binkd
behaviour... Which you already did. ;)

Bye, Wilfred.

[mark lewis]

On Fri, 14 Mar 2014, Wilfred van Velzen wrote to mark lewis:

ml> the problem is the random number in the ()s instead of the IP... i
ml> checked and i cannot find any relationship between the numbers and
ml> the IPs... the numbers are never the same for the same IP,
ml> either... i have backresolve disabled and enabling it does not
ml> change the output in the ()s... backresolv appears to affect only
ml> the "incoming session with" lines as well as reducing DNS
ml> lookups...

WvV> My linux version (which is the same as your os/2 version), has the
WvV> same log lines as your os/2 version.

interesting...

WvV> I suspect the number is the source's port number.

i hadn't considered that... i will look into it and see if that is what it
is... thanks for the idea!

WvV> With what linux and windows versions did you test this?

binkd/1.0a-521/Win32
binkd/0.9.9-stable/Linux

WvV> It seems strange to repeat between () what is already there in
WvV> the log line.

agreed to a point...

WvV> So this might be behaviour that has changed (=fixed) in recent
WvV> binkd versions?

true... i know that with backresolv enabled, you get the FQDN on the "session
with" line and the IP is placed in []s... without backresolv, you get only the
IP and no []s... at least in the newer versions i've been running on my OS/2
box...

ml> i would not have discovered this bug if i had not been determined
ml> to figure out why the script wasn't working... a quick hack to the
ml> script for it pull the IP from the first location in the line
ml> immediately resulted in the script working as desired and
ml> displaying sensible statistics instead of all zeros...

WvV> It might not be a bug, but a new feature ... ;)

granted... i was tired and had been digging into that script all day for the
last several days... a bug was the only thing i could come up with since the
other versions i have at hand log the data in the manner that the script is/was
expecting it to be logged...

ml> can someone please take a look at this bug and repair it?

WvV> ... So it doesn't necessarily need repair.

it would be nice if someone on the team could look and see... at least at the
CVS/SVN/GIT and see if/when this was changed... i don't know where it is or i
would go and try to look myself...

the script is also rather old, too... it is the binkdstat.pl script written by
val khokhlov... what i started with was v1.0 and then i found a 1.21 (i
believe) on a sourceforge site for a router device... since i've been whittling
away at the various critters i've been finding in it, i've gotten it to work
well with the current binkd/2 i'm running on my main system... the same script
won't, however, work properly on either of the winwhatever or *nix systems i
have at hand because of the way it tracks by IP and those values having been
moved/changed in the new versions compared to the older ones...

ok, so if it isn't a bug or two that i've found, then i guess the scripts i've
been looking at needed fixing anyway... i chose the one because it has nice
output and capabilities... i absolutely enjoy being able to get stats for the
last hour, range of hours, day, range of days, week, range of weeks, month,
range of months, year and range of years ;)

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin