On Tue, May 28, 2013 at 3:41 PM, Gilles Chehade <[email protected]> wrote:
> From within the filter API, you can have all the information mentionned
> above if you want to... you can very well write a filter that will write
> the Receive line in l33t sp34k if sent from an ip address that ends with
> .42 over an encrypted and authenticated channel if you will.
>
> The filter layer is stateful, it *must* be, and filters can keep track
> of session characteristics to reuse them in further hooks.
Oh, I see:
case HOOK_CONNECT:
m_get_sockaddr(&m, (struct sockaddr*)&q_connect.local);
m_get_sockaddr(&m, (struct sockaddr*)&q_connect.remote);
m_get_string(&m, &q_connect.hostname);
m_end(&m);
filter_dispatch_connect(id, qid, &q_connect);
break;
So basically, a filter writer has to note the local/remote sockaddr
and connect it up with its qid, store that state information
somewhere, and then re-correlate the qid on the dataline situation?
Blah, that sounds a bit tedious -- I wouldn't enjoy programming for
it.
Also -- this exposes local and remote sockaddrs and the connect
hostname, but not much else, such as labels, authentication status,
tls status, etc. Are there plans to introduce a better state
mechanism? Also, as a nitpick, sockaddr is size-less, so the filter
can't know with total certainty which size to cast it back to.
--
You received this email because you are subscribed to mailing list:
[email protected]
To unsubscribe, send mail with subject:
[[email protected]] unregister
