× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.