Nitin wrote:
Hi All,
can you please suggest a way to print the UDP message when udpOverflows probe
hits.
As per my understanding, udpInOverflows probe hits, when there is no space in
UDP buffer. It means socket/port/application for which this UDP packet belongs
will never receive that packet.
So how to check which packet application lost with dtrace or other means on
solaris 10
I presume you're talking about the dtrace probe which fires when the
udpInOverflows MIB is incremented? Actually, you need the
udpIfStatsInOverflows mib (see the #define in <inet/mib2.h>). As the
probe fires, I think you only get the address of the stat which got
updated as an argument. So, you need to catch the mblk_t * earlier in
the chain.
My suggestion would be to put an fbt :entry probe on a handful of probes
(see below) and store the relevant arg (the mblk_t *), then predicate
your BUMP_MIB probe on whether this has a value. Something like this
(untested) example:
fbt::ip_udp_input:entry
{ self->mp = args[1]; }
:::udpIfStatsInOverflows
/self->mp/
{ tracemem (self->mp->b_rptr, (self->mp->b_wptr - self->mp->b_wptr));
self->mp = 0; }
It looks like the list of fbt probes needed is:
# dtrace -l -n udpIfStatsInOverflows
ID PROVIDER MODULE FUNCTION NAME
2948 mib ip ip_rput_data_v6
udpIfStatsInOverflows
2949 mib ip ip_fanout_udp_v6
udpIfStatsInOverflows
2950 mib ip ip_udp_input
udpIfStatsInOverflows
2951 mib ip ip_fanout_udp_conn
udpIfStatsInOverflows
so add these to the fbt :entry probe list. The mblk is:
arg2 for ip_rput_data_v6
arg1 for ip_fanout_udp_v6
arg1 for ip_udp_input
probably arg2 for ip_fanout_udp_conn (maybe arg1, but not likely)
so adjust your probes accordingly.
You could obviously replace the tracemem call (which is a pure binary
dump) with something more intelligent to dump out the src/dst IP
addresses and ports, but I'll leave that as an exercise for the reader :-)
Given this is Solaris 10, for any further help than this, I'd suggest
raising a support call.
Regards,
Brian
--
Brian Ruthven
Solaris Network RPE (Sustaining)
Oracle UK
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
