could I please get a summary of when connection_state_remove is
triggered. It sounds like what I need, is mentioned in a bunch of places
in the code, but unfortunately not documented and so I'm confused about
its semantics.
Some context: if I have a table[conn_id] of blah that indexes on both
UDP and TCP connection identifiers, then what's the best way to reliably
expire all of its entries as time progresses? Can I just fix an upper-
bound @read_expire that is larger than TCP's, so I can rely on UDP being
kicked out eventually without interfering with the TCP state management,
and if so, what value do I use? Thanks!
could I please get a summary of when connection_state_remove is
triggered.
That's actually easy to summarize: connection_state_remove is
triggered at the time Bro removes a connection's internal connection
state, for whatever reason.
In fact, the reason to introduce this was to get reliable clean-up
of script-level state: if you have state which is stored per
connection and not needed after the connection's removal,
connection_state_remove is the way to reclaim it.
It sounds like what I need, is mentioned in a bunch of places
in the code,
There shouldn't be too many of these places. Essentially everywhere
where a Connection object is destroyed.
Some context: if I have a table[conn_id] of blah that indexes on both
UDP and TCP connection identifiers, then what's the best way to reliably
expire all of its entries as time progresses?
Depends on whether you still need the entries when the internal
state has already been thrown away. If so, then a read_expire may
be the way to go. If not, connection_state_remove is probably better.
> could I please get a summary of when connection_state_remove is
> triggered.
That's actually easy to summarize: connection_state_remove is
triggered at the time Bro removes a connection's internal connection
state, for whatever reason.
In fact, the reason to introduce this was to get reliable clean-up
of script-level state: if you have state which is stored per
connection and not needed after the connection's removal,
connection_state_remove is the way to reclaim it.
I see; but afaik UDP connection state is never expired (until
net_finish), right? My confusion about the semantics partially stem from
the fact that I see connection_state_remove used on non-TCP connections,
but I'm unclear about Bro's treatment of such connections.
> It sounds like what I need, is mentioned in a bunch of places
> in the code,
There shouldn't be too many of these places. Essentially everywhere
where a Connection object is destroyed.
Okay, thanks.
> Some context: if I have a table[conn_id] of blah that indexes on both
> UDP and TCP connection identifiers, then what's the best way to reliably
> expire all of its entries as time progresses?
Depends on whether you still need the entries when the internal
state has already been thrown away. If so, then a read_expire may
be the way to go. If not, connection_state_remove is probably better.
I indeed don't need it any more in this case, I just want to make sure
both TCP *and* UDP are expired. I'm aware of the difficulty of expiring
UDP state -- I just need some reasonable value that lets me run this
script on very large traces.
I guess I could just use separate tables and have a read_expire throw
out entries in the UDP table and connection_state_remove() handle the
ones in the TCP one, though given that conn_ids are so nicely identical
for UDP+TCP that'd seem a bit of a shame...
*If* Bro expires a UDP connection, it raises
connection_state_remove. But you're right, but default Bro doesn't
remove (most of the) UDP state. But you can set a
udp_inactivity_timeout, then it will (in fact, if you're analyzining
UDP traffic you *really* want to have such a timeout; otherwise your
table is probably the smallest problem
Ah! I wasn't aware of that setting. udp_inactivity_timeout seems set to
10s by default, so I guess after 10s connection_state_remove *is*
actually triggered by default for UDP. I need to re-run my scripts to
see whether I'm actually leaking state. Thanks Robin!
Yes, then UDP core-state should