Hi Robin,<br><br>Thanks, actually it just need to check if the packet that replying is with 18 bytes length so I guess its good to go.<br><br>Back to word, I would like to know if anyone working on skype policy script, in case there's merge of same interest.
<br><br><br><br><div><span class="gmail_quote">On 9/19/07, <b class="gmail_sendername">Robin Sommer</b> <<a href="mailto:robin@icir.org">robin@icir.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Tue, Sep 18, 2007 at 15:39 +0800, CS Lee wrote:<br><br>> The script can locate the <a href="http://210.79.186.143">210.79.186.143</a> but not <a href="http://200.83.176.80">200.83.176.80</a> and<br>> <a href="http://89.37.157.114">
89.37.157.114</a>. That lead us to believe that bro understand the flow in<br>> semantic level. In fact if we do the matching to 18+19 = 37 bytes,<br><br>That's right, the size in the endpoint record is cumulative and
<br>reflects the total size of the flow so far.<br><br>I see two options for you:<br><br>- you could remember the flows' size with every udp_reply and then<br>calculate the increase when the next udp_reply comes in.<br>
<br>- you could use the new_packet() event which gives you the size for<br>each packet.<br><br>None of the two approaches is very nice and both can also turn out to<br>be pretty expensive. The main problem here is that Bro isn't really
<br>well-suited for expressing policies at the level of indivdual packets<br>as it tries to abstract from packets o high-level activity as much as<br>possible.<br><br>Robin<br><br>--<br>Robin Sommer * Phone +1 (510) 931-5555 *
<a href="mailto:robin@icir.org">robin@icir.org</a><br>LBNL/ICSI * Fax +1 (510) 666-2956 * <a href="http://www.icir.org">www.icir.org</a><br></blockquote></div><br><br clear="all"><br>-- <br>Best Regards,<br><br>CS Lee<geekooL[at]gmail.com>