Re: What job is trying to communicate out via a certain port? -- MIDRANGE-L

LOL Justin - you have an excellent way of revealing my inexperience in the UNIX or Linux world where I've played just a little!

I did see your request on that post, and I simply didn't know what to reply, nor did I have much time.

The help on the utilities I posted use stuff that sounds like what you are describing - a command called TRCINT - Trace internals - is one of the things used. Not something the everyday user could care about, and for things like this you need the *SERVICE special authority.

There is also something called PEX - not the plastic piping, please!! - Performance Explorer. This can get you just about everything you'd ever want to know about processes. Because this kind of performance information is already available there, I suspect that the IBM i system developers saw no need for these utilities.

As a comment on all this system admin stuff - the original system/38 - it had basically the same OS as our enhanced OS for i. And it monitors EVERYthing - one of the reasons that mainframes are desirable for headsdown number crunching is, they don't have as much integrated logging of various metrics, while IBM i collects a ton of it.

IIRC, this is now called Collection Services - something like that. Actually, that is a layer on top, sort of, that gathers in the metrics and can be put into tables, which you can use to analyze to your heart's content.

The latest web-based Navigator has tooling to help analyze this stuff, too.

Hope that gives you something worth looking at, man!!

Vern

On 2/24/2016 3:13 PM, Justin Dearing wrote:

Vernon,

I recently asked on this very list if such a thing existed:
http://archive.midrange.com/midrange-l/201602/msg00546.html

Actually strace/procmon/trussare not TCP/IP things. They monitor low level
process calls INCLUDING opening up network sockets (which tend to be
TCP/IP). I don't know of a standard BSD utility (ping, traceroute,netstat,
etc) that would monitor what process is bound to what port, except netstat,
which Rob already mentioned using.

That being said, I Hope Rob does find a solution neater than his SQL loop
and reports it back here. If Rob's question sparks someone to find an
answer to my question, I'm glad we can all learn something useful.

Justin

On Wed, Feb 24, 2016 at 4:06 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Justin

Are you sure these things are not there, perhaps under a different name
or function? At one time, IBM had their regular 3-letter-component names
in commands for the well-known TCPIP things - PING is there and is also
known as VFYTCPCNN - Verify TCP/IP Connection.

There are also a couple commands that might be useful - TRCTCPAPP
apparently can give one a lot of information, and TRCCNN might help Rob
- it has an optional parameter to specify from and to ports.

HTH
Vern

On 2/24/2016 2:17 PM, Justin Dearing wrote:

Rob,

Not going to be of help, just going to commiserate here for a bit. If

there

was a strace/dtrace/truss/procmon kind of thing for IBM i, this is
*exactly* the use case for it. You know something is making a TCP
connection. you even know the port, you don't know what. Well actually on
linux your going to need to write some C code to be notified when a

process

starts because you can only strace one process at a time.

My only other shot in the dark idea, is it possible to do the following
(without making your whole system useless):
1. Attach every new job to a debugger
2. Have the debugger break on whatever the lowest level TCP connection

api

call is that any LDAP connect API call would call?

If I was on linux or windows and you took away strace and procmon, and

the

APIs that they used, my MacGyver strategy would be to use windbg or gdb

in

the manner described above.

On Wed, Feb 24, 2016 at 3:01 PM Rob Berendt <rob@xxxxxxxxx> wrote:

I have two lpars in this thread: GDISYS1, GDISYS2
On GDISYS1 I do WRKJOB QUSRDIR and look at the joblog and I see:
Message ID . . . . . . : GLD0120
Message . . . . : Bind error with directory server.
Cause . . . . . : Distinguished name (dn) 'CN=ADMINISTRATOR' at IP
address
10.10.6.129 failed to bind with the directory server.

The IP address for GDISYS1 is 10.17.6.129 and the IP address for GDISYS2
is 10.10.6.129.
I can run a comm trace on both lpars and I can see that port 389 on
GDISYS1 address 10.17.6.129 is being accessed from port 42408 from

address

10.10.6.129 from GDISYS2.

I'm trying to determine what job is trying to perform an ldap bind from
GDISYS2 onto GDISYS1 using the name CN=ADMINISTRATOR.

Comm trace does not display jobs on either the source or target side.

NETSTAT *CNN requires that I am constantly refreshing it and I've been
unable to catch it. It doesn't have an output option to put it into a
program loop. Like the following:
create table rob.netstatstuff as (
select current timestamp as TS, n.*
from qsys2.netstat_job_info n
where n.local_port=42408
) with data

// start loop
insert into rob.netstatstuff (
select current timestamp as TS, n.*
from qsys2.netstat_job_info n
where n.local_port=42408
)
// end loop

Again, you're timing has to be perfect otherwise you get:
SQL0100 - Row not found for INSERT.

Is there a better way to determine who is trying to bind via ldap?

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.