Hi Jason
1)
I was looking at rpcstat_init and its hard coded link into tethereal.
My initial reaction is that there should be a way of handing off a tap
string to the tap subsystem for validation. I would also think that the
tap initialization core would merely hand off the string (without "rpc,"
etc...) to a lower level initialization routine...
I agree, If we start getting a lot of tap extensions, we should seriously
consider this since otherwise the parsing of the
command line arguments will become huge. Doing it via registration instead
would also make the tap-listener
more self contained.
2)
I can envision the need for a more selective tap calling trigger than a
packet of the right type being encountered. It would be nice to have a
tap listener called the first time that a packet is processed (or every
time except the first time). I imagine that this might be easy to do
based on pinfo, but somehow I think that such functionality should not
be inside the tap listener, but outside of it.
Hm.
On this I dont think I agree. I actually think that this kind of semantics
should be placed in the tap-listener itself.
But it is simple to implement but it does not require using pinfo structure.
To add the only-use-first-packet semantics to tap_rpcstat.c this is as
simple as
1, add "int packet_num;" to the definition of rpcstat_t
2, set packet_num=0; where the rpcstat_t structures is allocated.
3, add rs->packet_num=0; to the beginning of the _reset() callback.
4, add rs->packet_num++; if(rs->packet_num>1)return FALSE; to the
_packet() callback.
simple as that.
Since this kind of semantics is so simple to implement in the tap-listener I
think it should be kept there
so we dont add complexity to the tap layer itself (for functions that only
few taps will use?)
best regards
ronnie sahlberg
_________________________________________________________________
Get a speedy connection with MSN Broadband. Join now!
http://resourcecenter.msn.com/access/plans/freeactivation.asp
