Looks like BuildConnVal() can be called from the connection destructor
and will set the origin to "this" and thus create a dangling pointer.
The connection will destruct but since conn_val has a reference
counting mechanism, it will still keep referring to the connection.
I propose to fix this by creating a destructing flag bit-field inside
connection. It will be initialized to zero, but set to 1 just when the
destructor is entered.
Looking forward to your comments! I will provide a patch, if desired.
-vee
Wanshan Village is located in Qingyang City of northwest China's Henan Province. As a strategically important location with roads extending in all directions, the village was developed as a military outpost in ancient China. The old village consists of five communities named by their locations, among which the Southern Community is the cradle of the so-called "burning sedan on stilts."
The practice is said to have originated during the Tang and Song dynasties (dates) when locals celebrated the Spring Festival with performances involving dancing on stilts and carrying bridal sedan-chairs.
The custom developed further during the Ming Dynasty (date) when Zhu Zaiyu, an imperial prince, abandoned his title and retired near Wanshan Village. He found that the folk artists there ranked at the bottom of the social structure, and feeling sorry for them, helped create a new art which combined stilts dancing with carrying the bridal sedan-chair.
http://www.chinesefolkculture.com/
The email is to promote chinese folk culture without having commercial purposes .If you mind the message, please tell me, i will not interupt you again.Thank you.TEL:+86 (29)88230462 +86 (29)88249701
_________________________________________________________________
使用下一代的 MSN Messenger。
http://imagine-msn.com/messenger/launch80/default.aspx?locale=zh-cn&source=…
Greetings
I am integrating bro into a larger system so that I can use it to keep track
of connections (which seems easier than trying to write a method from
scratch with pcap). I thought it would be straightforward to grep for print
or email or alarm statements to figure out where to put the hooks for an IPC
message but so far it eludes me. Is there a principal module for outputting
the notifications?
Thanks
Mike
The problem:
type MyRecord = record {
f1: SomeRecordType;
f2: bytestring &length=body_len;
} &let {
body_len: uint32 = f1.rec_len - sizeof (f1);
};
The above definition looks familiar, uh? It is a simplifed version of
the DCE RPC PDU. If MyRecord is incrementally parsed, the sizeof (f1)
in the &let construct will cause trouble because getFieldBegin and
getFieldEnd can only be used for non-incremental parsed record. If
the size of SomeRecordType is decideable statically (in the case of
DCE RPC, it is), then the patch fixes the problem. Now we can make
the PDU incrementally parsed.
Cheers,
Jimmy
____________________________________________________________
The future is not set. There is no fate but what we make
for ourselves. - Terminator II, Judgment Day
------------------------------------------------------------
Hi,
I notice that in ~RPC_Reply, there is a statement "delete call_;". However,
this call_ is instantiated by calling t_context->connection()->FindCall(
msg()->xid()). This means that it is not "new"ed. This call_ supposely is
deleted in the ~RPC_Message. Thus, there is a potential double-free here.
The root cause is that binpac generates the "delete call_" for &let field.
This is incorrect behavior. However, I haven't figured out how to fix it
in binpac.
A quick fix to this problem is to modify the rpc-protocol.pac:RPC_Reply,
replacing the RPC_AcceptedReply(call) and RPC_RejectedReply(call) with:
RPC_AcceptedReply($context.conn.FindCall(msg.xid))
RPC_RejectedReply($context.conn.FindCall(msg.xid))
Cheers,
Jimmy
____________________________________________________________
The future is not set. There is no fate but what we make
for ourselves. - Terminator II, Judgment Day
------------------------------------------------------------
Hi,
I want to generate bro reports from tcpdump packet capture files. Those
files were captured from different networks. So:
bro -r file.pcap will generate generate log files:
alarm.log
conn.log
notice.log
weird.log
When I run site-report.pl, I get
No connection data found for the time period specified.
Unable to create a report.
What does this error mean? Note that the packet capture files maybe
several days old.
--mel
