Hi Jeff, I think in the current master, we do support the function code of "write" in the master branch, but not the type of objects used in the given pcap file. In that development branch you mentioned, I think I added as many as event handlers I can. But we could not merge them into the master branch, as at that time, we could not find any sufficient test pcap files that can trigger the event handlers. Probably it is the time for me to search again for the test pcap files again from the Internet. The pacp that you provide may not be used as a test case, as it looks like a truncated communication, i.e., a request without responses. If you have any test pcap, feel free to share with us if that is appropriate for you. Also, if you need to use these event handlers, I think that you can also go for that development branch. And also feel free to let me know if there is any bug in that branch, I can work to fix them.
Best, Hui Lin On Tue, Feb 9, 2016 at 5:19 PM, Jeff Barber <[email protected]> wrote: > > It's only particular object types and especially those in the *request* > that I'm referring to. I do see response objects fine. I wish I had better > pcaps to share, but I'm having trouble finding those myself. :) > > > I have attached one I found on the web which, according to wireshark, has > a single write of object type 50, variation 01. It produces these events: > > header_block, [orig_h=127.0.0.1, orig_p=37712/tcp, resp_h=127.0.0.1, > resp_p=20000/tcp, vlan=0, inner_vlan=0], T, Start, 25605, Len, 18, Ctrl, > 196, Dst, 3, Src, 4 > application_request_header, [orig_h=127.0.0.1, orig_p=37712/tcp, > resp_h=127.0.0.1, resp_p=20000/tcp, vlan=0, inner_vlan=0], T, App, 193, FC, > 2 > object_header, [orig_h=127.0.0.1, orig_p=37712/tcp, resp_h=127.0.0.1, > resp_p=20000/tcp, vlan=0, inner_vlan=0], T, OT, 12801, Qua, 7, Num, 1, RF, > 1, 0 > object_prefix, [orig_h=127.0.0.1, orig_p=37712/tcp, resp_h=127.0.0.1, > resp_p=20000/tcp, vlan=0, inner_vlan=0], T, PREF, 0 > > (Mnemonics included except for the first two fields which are always c$id > and is_orig.) > > but there's no event giving the content of that object type. > > > I'm not getting any error messages, but just in looking at the .pac files > in the dnp3 directory, I see the code apparently parsing all the unique > types below, but it doesn't seem to be generating events for any of them. > At least some of those *do* seem to have had events generated for them in > that dnp3-events branch code. > > AnaOutStatus32 > AnaOutStatus16 > AnaOutStatusSP > AnaOutStatusDP > AnaOut32 > AnaOut16 > AnaOutSP > AnaOutDP > AnaOutEve32woTime > AnaOutEve16woTime > AnaOutEve32wTime > AnaOutEve16wTime > AnaOutEveSPwoTime > AnaOutEveDPwoTime > AnaOutEveSPwTime > AnaOutEveDPwTime > > > Thanks. > > > On Tue, Feb 9, 2016 at 4:49 PM, Hui Lin (Hugo) <[email protected]> > wrote: > >> Hi Jeff, >> >> I think the master branch should contain what we wrote before. I run some >> simple DNP3 test cases included in Bro from master branch and I do see the >> simple print out message. >> >> Does running your pcap generate any error message? Do you mind sharing >> the trace that you are using for me to take a look at what is going on? >> >> Best, >> >> Hui Lin >> >> On Tue, Feb 9, 2016 at 3:04 PM, Jeff Barber <[email protected]> wrote: >> >>> Hi >>> >>> I'm trying to use bro for decoding DNP3 traffic and following the logic >>> through its parser to the various dnp3_xxx events. (The documentation on >>> how to use the DNP3 events is a bit light but I think I understand what's >>> happening.) When I try to follow the request objects logic (e.g. as you >>> might get from a DNP3 write command), I can't see how they're getting >>> output to the bro script layer at all. Most of them seem to simply dead-end >>> in the parser with no event generated. >>> >>> I spent a little while looking through the bro branches and came across >>> a branch called topics/hui/dnp3-events that _seems_ to have support for a >>> bunch of additional objects. It was last worked on in February 2014 but I >>> can't find any hint of it in the master branch. >>> >>> Just wondering if anyone can clarify. Am I misunderstanding how it >>> works? Or did the code in dnp3-events branch get lost? Or was it never >>> merged? Or never completed? >>> >>> Thanks! >>> >>> Addressing to Hui Lin but also including bro-dev in case someone else >>> knows the history. >>> >>> >> >> >> -- >> Hui Lin >> PhD Candidate (http://hlin33.web.engr.illinois.edu/) >> DEPEND (http://depend.csl.illinois.edu/) >> ECE, Uni. of Illinois at Urbana-Champaign >> >> > -- Hui Lin PhD Candidate (http://hlin33.web.engr.illinois.edu/) DEPEND (http://depend.csl.illinois.edu/) ECE, Uni. of Illinois at Urbana-Champaign
_______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
