On Sep 29, 9:33pm, James_Shanks@TIVOLI.COM wrote:
> Subject: Re: trapd problem
> How about a little more explanation of what you are trying to do here?
OK, you asked for it!
We have a firewall'ed "secure" subnet which we have to monitor with NetView.
The firewall will NOT allow udp through, only tcp.
We are installing MLM on the secure subnet, and hope to "force"
tcp traps (even if we have to use "snmptrap -t ...") out to our "main"
Monitoring station running NetView.
A simple test using "snmptrap -t ..." from the "MLM" machine 129.128.8.18
to the NetView machine "condor", with tracing and dump
on trapd show'ed the following:
Tue Sep 29 16:29:27 1998 Tracing Started
Tue Sep 29 16:29:33 1998 add_connection: [10] connected
30 46 02 01 00 04 06 70 75 62 6c 69 63 a4 39 06 0F.....public.9.
08 2b 06 01 04 01 02 06 0c 40 04 81 80 08 12 02 .+.......@......
01 06 02 01 0f 43 03 1c 75 ca 30 1c 30 1a 06 0b .....C..u.0.0...
2b 06 01 04 01 02 06 0c 02 01 00 04 0b 74 6f 20 +............to
70 6f 72 74 20 31 36 32 -- -- -- -- -- -- -- -- port 162........
Tue Sep 29 16:29:33 1998 queue_event: queued 72 bytes.
Tue Sep 29 16:29:33 1998 flush_event: flushed 1 events.
Tue Sep 29 16:29:33 1998 del_connection: [10] disconnected
Tue Sep 29 16:30:25 1998 Tracing Stopped
So are we off base here?
Why is trapd "flushing"?
>
> When you send a trap to 162/udp it is a one-way operation. The trap
> receiver just has to listen to the port. But tcp communication requires
> that the parties involved negotiate a session -- tcp is connection-oriented
> while udp is conectionless. So trapd does allow tcp communication --
> netmon sends that way, so does MLM, even another NetView's trapd, but they
> are designed to do that.
>
> Who is sending the trap to 162/tcp?
--
/in haste
/Bob
|