Trace network operation of a session

I was trying to find a way to trace network operations of a session sending an email from inside 
Oracle. First I tested strace -f -e trace=network -p on the server process. But the output was too 
verbose and "chatty" to be useful. I searched and found a number of documents and bug reports such as

Random/Sporadic/Intermittent "ORA-29278: SMTP transient error: 421 Service not available" Errors (Doc ID 1435323.1)
Bug 6140957 : ORA-29279: SMTP PERMANENT ERROR USING UTL_MAIL AND ZMAILER SMTP SERVER

where they talked about event 10590 set at level 14. This event is

$ oerr ora 10590
10590, 00000, "kga (argus debugger) test flags"
// *Cause:
// *Action: set this event only under the supervision of Oracle development

Google search shows that the argus debugger is generally used for network tracing and debugging. 
Oracle used to publish
ORA-600 Lookup Error Categories (Doc ID 175982.1)
where a bunch of kga* functions are related to "support for Java Debug Wire Protocol (JDWP) and 
debugging facilites".

Anyway, here's my test in 11.2.0.3:

--after granting execute on utl_smtp to me (since we don't grant it to public)

CREATE PROCEDURE send_mail
(  sender     IN VARCHAR2,
   recipient  IN VARCHAR2,
   subject    IN VARCHAR2,
   message    IN VARCHAR2)
IS
  mailhost     VARCHAR2(30) := 'mail.mycompany.com';
  mail_conn    utl_smtp.connection;

  crlf VARCHAR2( 2 ):= CHR( 13 ) || CHR( 10 );
  mesg VARCHAR2( 1000 );
BEGIN
  mail_conn := utl_smtp.open_connection(mailhost, 25);

  mesg:= 'Date: ' || TO_CHAR( SYSDATE, 'dd Mon yy hh24:mi:ss' ) || crlf ||
         'From:  <'||sender||'>' || crlf ||
         'Subject: '||subject || crlf ||
         'To: '||recipient || crlf ||
         '' || crlf || message;
  utl_smtp.helo(mail_conn, mailhost);
  utl_smtp.mail(mail_conn, sender);
  utl_smtp.rcpt(mail_conn, recipient);
  utl_smtp.data(mail_conn, mesg);
  utl_smtp.quit(mail_conn);
END;
/
alter session set events '10590 trace name context forever, level 14';
exec send_mail('yhuang@mycompany.com', 'yhuang@mycompany.com', 'test mail', 'Hello, this is a test!')
alter session set events '10590 trace name context off';

The trace file is quite readable:

kgasct_connect_tcp
kgasiu_init_uga
kgassn_setup_ns
kgassg_setup_gbh
  kgassg_setup_gbh: initialized gbh 0x000000000DB596B0
  kgasct_connect_tcp: connecting NS (ADDRESS=(PROTOCOL=tcp)(HOST=10.114.218.100)(PORT=25))
  kgasct_connect_tcp: nscall conn 0 conn_ns 0 65535 8192 8182 f4ffe9ff 6014 e881 0 7f08
  kgasct_connect_tcp: 0 0x0000000000000000
kgasr_recv 0 1024 0 -1 -1
kgasra_recv_avail 0 4294967295
  kgasra_recv_avail: 0 conns found with events
  kgasra_recv_avail: 1 conns found with events
  kgasra_recv_avail: conn_ns 0 event 2
  kgasra_recv_avail: 1 0 2
  kgasr_recv: read 95 oer 0
  kgasr_recv: 95 oer 0
  kgasr_recv:   50 2   50 2   48 0   32    109 m   97 a  105 i  108 l
...
  kgasr_recv:   77 M  105 i   99 c  114 r  111 o  115 s  111 o  102 f
  kgasr_recv:  116 t   32     69 E   83 S   77 M   84 T   80 P   32
  kgasr_recv:   77 M   65 A   73 I   76 L   32     83 S  101 e  114 r
  kgasr_recv:  118 v  105 i   99 c  101 e   32    114 r  101 e   97 a
  kgasr_recv:  100 d  121 y   32     97 a  116 t   32     77 M  111 o
  kgasr_recv:  110 n   44 ,   32     50 2   57 9   32     83 S  101 e
  kgasr_recv:  112 p   32     50 2   48 0   49 1   52 4   32     49 1
  kgasr_recv:   52 4   58 :   53 5   55 7   58 :   52 4   51 3   32
  kgasr_recv:   45 -   48 0   53 5   48 0   48 0   13     10
kgass_send 0 26 0
  kgass_send: 26 0 0 26 0
  kgass_send:   72 H   69 E   76 L   79 O   32    109 m   97 a  105 i
  kgass_send:  108 l   46 .  ...
...

All SMTP commands and responses are shown. Reply codes such as 220 are documented at
http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/u_smtp.htm#ARPLS074


But of course this event can be used to trace other types of network activity (but not Oracle Net 
or DB link activity). Here's a trace on another session, which has sid and serial# 432, 41465, 
respetively:

In monitoring session:
exec dbms_system.set_ev(432,41465,10590,14,'')

In the traced session:
SQL> select utl_http.request('http://www.oracle.com') from dual;

UTL_HTTP.REQUEST('HTTP://WWW.ORACLE.COM')
-------------------------------------------------------------------------
<!DOCTYPE html>

<html  lang="en-US" class="no-js">
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <script type="text/javascript">
   var _U = "undefined";
   var g_HttpRelativeWebRoot = "/ocom/";
...

In monitoring session:
exec dbms_system.set_ev(432,41465,10590,0,'')

The trace shows:

  kgass_send:   71 G   69 E   84 T   32     47 /   32     72 H   84 T
  kgass_send:   84 T   80 P   47 /   49 1   46 .   49 1   13     10
  kgass_send:   72 H  111 o  115 s  116 t   58 :   32    119 w  119 w
  kgass_send:  119 w   46 .  111 o  114 r   97 a   99 c  108 l  101 e
  kgass_send:   46 .   99 c  111 o  109 m   13     10     67 C  111 o
  kgass_send:  110 n  110 n  101 e   99 c  116 t  105 i  111 o  110 n
  kgass_send:   58 :   32     99 c  108 l  111 o  115 s  101 e   13
  kgass_send:   10     13     10
...
  kgasr_recv:   72 H   84 T   84 T   80 P   47 /   49 1   46 .   49 1
  kgasr_recv:   32     51 3   48 0   49 1   32     77 M  111 o  118 v
  kgasr_recv:  101 e  100 d   32     80 P  101 e  114 r  109 m   97 a
  kgasr_recv:  110 n  101 e  110 n  116 t  108 l  121 y   13     10
  kgasr_recv:   76 L  111 o   99 c   97 a  116 t  105 i  111 o  110 n
  kgasr_recv:   58 :   32    104 h  116 t  116 t  112 p   58 :   47 /
  kgasr_recv:   47 /  119 w  119 w  119 w   46 .  111 o  114 r   97 a
  kgasr_recv:   99 c  108 l  101 e   46 .   99 c  111 o  109 m   47 /
  kgasr_recv:  105 i  110 n  100 d  101 e  120 x   46 .  104 h  116 t
  kgasr_recv:  109 m  108 l   13     10     83 S  101 e  114 r  118 v
  kgasr_recv:  101 e  114 r   58 :   32     66 B  105 i  103 g   73 I

This is like using the old telnet trick to see what's going on across the wire, because the actual 
web client, Sqlplus in this case, does not show the initially sent data and the response it gets, 
such as telling the client the location has permanently moved to a different URL, let alone the 
HTTP headers.