From noreply at bro.org Wed Apr 1 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 1 Apr 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504010700.t3170MFC008043@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer - 2015-03-31 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From jira at bro-tracker.atlassian.net Wed Apr 1 07:36:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 1 Apr 2015 09:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20211#comment-20211 ] Jon Siwek commented on BIT-1364: -------------------------------- Same thing as BIT-844 ? I think the agreement was that UDP signature matching does currently have a problem and it should match packet-wise. It's an ugly workaround, but prefixing ".*" instead of "^" to the signature should cause matches on any packet (but also possibly mismatches if the pattern appears within a packet's payload). > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 07:47:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 1 Apr 2015 09:47:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20212#comment-20212 ] Jon Siwek commented on BIT-1361: -------------------------------- Mostly I'd just like confirmation the patch seems to fix your problem (in case the pcap I was working from just happened to trigger the same assertion, but in a different way from what you saw). > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 08:07:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 1 Apr 2015 10:07:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: Jon Siwek created BIT-1365: ------------------------------ Summary: direction field of SSH::Info no longer populated Key: BIT-1365 URL: https://bro-tracker.atlassian.net/browse/BIT-1365 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Jon Siwek Fix For: 2.4 Here's the bug report: {quote} Reporter::ERROR field value missing [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da ta.bro, line 29 Reporter::WARNING non-void function returns without a value: SSH::get_location (empty) Tracing this back, it looks like the SSH::c$ssh$direction is not being populated. I checked the /base/protocols/ssh/main.bro file and it looks like the function is missing. Looking at https://www.bro.org/sphinx/_downloads/main32.bro and https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro it looks like the function that determined the direction was removed at one point, which looks like it causes the /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 08:11:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 1 Apr 2015 10:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20213#comment-20213 ] Johanna Amann commented on BIT-1364: ------------------------------------ Ah, sorry - I was not aware that we already have a ticket like that. And yes, that seems to be the same thing. I guess switching the pattern in this case might work, it is specific enough that it is unlikely to match otherwhise. We probably should still fix this sometime, it does not seem that that solution would always be viable.. > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 10:08:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 1 Apr 2015 12:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20214#comment-20214 ] Jon Siwek commented on BIT-1364: -------------------------------- Yeah, should do a real fix; just wanted to mention the workaround in case that's a more viable option to make it in to 2.4. > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 10:08:01 2015 From: jira at bro-tracker.atlassian.net (Ted Llewellyn (JIRA)) Date: Wed, 1 Apr 2015 12:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Llewellyn updated BIT-1361: ------------------------------- Jon, No problem. The longest it has run before is about 48 hours. It will hit that tomorrow night about 9 pm Eastern. So, it should be safe to say that if it's still running on Monday morning the fix is probably good. Thanks, Ted > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 10:20:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 1 Apr 2015 12:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1362) topic/dnthayer/fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20216#comment-20216 ] Robin Sommer commented on BIT-1362: ----------------------------------- Justin, feel like doing your first merge? :-) > topic/dnthayer/fixes-for-2.4 > ---------------------------- > > Key: BIT-1362 > URL: https://bro-tracker.atlassian.net/browse/BIT-1362 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/fixes-for-2.4 contains fixes that address > BIT-1360, 1355, 1349, 1329, and 631, as well as various other fixes > and improvements. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 10:20:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 1 Apr 2015 12:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1362) topic/dnthayer/fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1362: --------------------------------- Assignee: Justin Azoff > topic/dnthayer/fixes-for-2.4 > ---------------------------- > > Key: BIT-1362 > URL: https://bro-tracker.atlassian.net/browse/BIT-1362 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/fixes-for-2.4 contains fixes that address > BIT-1360, 1355, 1349, 1329, and 631, as well as various other fixes > and improvements. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 11:12:01 2015 From: jira at bro-tracker.atlassian.net (Ted Llewellyn (JIRA)) Date: Wed, 1 Apr 2015 13:12:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Llewellyn updated BIT-1361: ------------------------------- Jon, I think this is something new; I do not remember seeing anything like this in my weird.log before applying the patch: 1427911262.505789 CYEwoB1X7XFyozYsdc 61.240.144.66 60000 10.10.32.253 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911263.624456 CCEGxTr3jHEZWIb1k 61.240.144.66 60000 10.10.32.250 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911263.847535 C86BvxMqoOeUz1e7e 61.240.144.66 60000 10.10.32.245 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911272.856867 CgQRbt3gokYaNcaZth 61.240.144.66 60000 10.10.32.252 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro Ted > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 1 11:16:00 2015 From: jira at bro-tracker.atlassian.net (Ted Llewellyn (JIRA)) Date: Wed, 1 Apr 2015 13:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Llewellyn updated BIT-1361: ------------------------------- Comment: was deleted (was: Jon, I think this is something new; I do not remember seeing anything like this in my weird.log before applying the patch: 1427911262.505789 CYEwoB1X7XFyozYsdc 61.240.144.66 60000 10.10.32.253 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911263.624456 CCEGxTr3jHEZWIb1k 61.240.144.66 60000 10.10.32.250 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911263.847535 C86BvxMqoOeUz1e7e 61.240.144.66 60000 10.10.32.245 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro 1427911272.856867 CgQRbt3gokYaNcaZth 61.240.144.66 60000 10.10.32.252 514 binpac exception: out_of_bound: Syslog_Priority:lt: 1 > 0 - Fbro Ted ) > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Thu Apr 2 00:00:34 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 2 Apr 2015 00:00:34 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504020700.t3270Ye9009466@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer Justin Azoff 2015-04-01 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From jira at bro-tracker.atlassian.net Thu Apr 2 01:15:01 2015 From: jira at bro-tracker.atlassian.net (Frank Meier (JIRA)) Date: Thu, 2 Apr 2015 03:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1366) clarify warning message about invalid checksums In-Reply-To: References: Message-ID: Frank Meier created BIT-1366: -------------------------------- Summary: clarify warning message about invalid checksums Key: BIT-1366 URL: https://bro-tracker.atlassian.net/browse/BIT-1366 Project: Bro Issue Tracker Issue Type: Patch Components: Bro Affects Versions: git/master Reporter: Frank Meier Priority: Low Attachments: find-checksum-offloading.diff Just to clarify the consequences of bad checksums in Bro. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 2 01:16:00 2015 From: jira at bro-tracker.atlassian.net (Frank Meier (JIRA)) Date: Thu, 2 Apr 2015 03:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1366) clarify warning message about invalid checksums In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20218#comment-20218 ] Frank Meier commented on BIT-1366: ---------------------------------- ..that was supposed to be "engine". > clarify warning message about invalid checksums > ----------------------------------------------- > > Key: BIT-1366 > URL: https://bro-tracker.atlassian.net/browse/BIT-1366 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: Frank Meier > Priority: Low > Labels: documentation, logging > Attachments: find-checksum-offloading.diff > > > Just to clarify the consequences of bad checksums in Bro. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 2 08:16:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 2 Apr 2015 10:16:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1366) clarify warning message about invalid checksums In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1366: --------------------------- Resolution: Fixed Fix Version/s: 2.4 Status: Closed (was: Open) I just committed an even more verbose version of the suggested warning to git/master. If anyone has a more succinct wording, feel free to suggest/change. > clarify warning message about invalid checksums > ----------------------------------------------- > > Key: BIT-1366 > URL: https://bro-tracker.atlassian.net/browse/BIT-1366 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: Frank Meier > Priority: Low > Labels: documentation, logging > Fix For: 2.4 > > Attachments: find-checksum-offloading.diff > > > Just to clarify the consequences of bad checksums in Bro. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Fri Apr 3 00:00:20 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 3 Apr 2015 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504030700.t3370KV8027638@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer Justin Azoff 2015-04-01 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From jira at bro-tracker.atlassian.net Fri Apr 3 08:47:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 3 Apr 2015 10:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: Johanna Amann created BIT-1367: ---------------------------------- Summary: Type clashing problem when records with default values are used in sets. Key: BIT-1367 URL: https://bro-tracker.atlassian.net/browse/BIT-1367 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Johanna Amann Fix For: 2.4 topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: {code} Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, $interv=1hr, $postprocessor=Log::sftp_postprocessor]); Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); {code} or similar leads to {code} type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) {code} Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. Working example: {code} Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, $interv=1hr, $postprocessor=Log::sftp_postprocessor]); Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); {code} Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 10:30:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 3 Apr 2015 12:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: Seth Hall created BIT-1368: ------------------------------ Summary: File type identification fixes Key: BIT-1368 URL: https://bro-tracker.atlassian.net/browse/BIT-1368 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.4 Reporter: Seth Hall Assignee: Seth Hall I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: ``` type fa_sniff: record { ## Depth sniffed. depth: count &default=0; ## Sniffed mime type if one was discovered. mime_type: string &optional; }; event file_sniff(f: fa_file, sniff: fa_sniff) { if ( sniff?$mime_type ) { print sniff$mime_type; } } ``` One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 10:31:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 3 Apr 2015 12:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20220#comment-20220 ] Seth Hall commented on BIT-1363: -------------------------------- How did you test it? Did you write a new packet source plugin? > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:05:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 3 Apr 2015 13:05:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: Vlad Grigorescu created BIT-1370: ------------------------------------ Summary: SIP Analyzer Key: BIT-1370 URL: https://bro-tracker.atlassian.net/browse/BIT-1370 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: 2.4 Reporter: Vlad Grigorescu Assignee: Vlad Grigorescu topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:05:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 3 Apr 2015 13:05:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: Vlad Grigorescu created BIT-1369: ------------------------------------ Summary: Kerberos Analyzer Key: BIT-1369 URL: https://bro-tracker.atlassian.net/browse/BIT-1369 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: 2.4 Reporter: Vlad Grigorescu Assignee: Vlad Grigorescu topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:08:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1367: --------------------------------- Assignee: Jon Siwek (was: Robin Sommer) > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Jon Siwek > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:08:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1367: --------------------------------- Assignee: Robin Sommer > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Robin Sommer > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:09:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1365: --------------------------------- Assignee: Vlad Grigorescu > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:12:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-844: ----------------------------- Priority: Low (was: Normal) > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Priority: Low > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:12:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:12:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1365: ------------------------------ Priority: Normal (was: Low) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:12:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1365: ------------------------------ Priority: Low (was: Normal) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:13:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:13:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1364: ------------------------------ Priority: Low (was: Normal) > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Priority: Low > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:13:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:13:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1364: --------------------------------- Assignee: Jon Siwek > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Jon Siwek > Priority: Low > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:15:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1361: --------------------------------- Assignee: Jon Siwek > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Assignee: Jon Siwek > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:16:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1360) Better error message when SpoolDir does not exist In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20221#comment-20221 ] Robin Sommer commented on BIT-1360: ----------------------------------- Included in BIT-1362 > Better error message when SpoolDir does not exist > ------------------------------------------------- > > Key: BIT-1360 > URL: https://bro-tracker.atlassian.net/browse/BIT-1360 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Priority: Low > Fix For: 2.4 > > > Currently, the error message that is given when SpoolDir in broctl.cfg does not exist is rather unhelpful (something in the direction of "Cannot open database". -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:17:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:17:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1360) Better error message when SpoolDir does not exist In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1360: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Better error message when SpoolDir does not exist > ------------------------------------------------- > > Key: BIT-1360 > URL: https://bro-tracker.atlassian.net/browse/BIT-1360 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Priority: Low > Fix For: 2.4 > > > Currently, the error message that is given when SpoolDir in broctl.cfg does not exist is rather unhelpful (something in the direction of "Cannot open database". -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:19:02 2015 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Fri, 3 Apr 2015 13:19:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20222#comment-20222 ] Aashish Sharma commented on BIT-1370: ------------------------------------- I've been running vlad's branch (2443d319112fd345878766618951c56c2fd65fbd) for a long while and for all practical purposes, its been running stable and blocking sip scanners and logging sip sessions. There are a couple unknown_SIP_method (SUBSCRIBE and NOTIFY) in weird logs. I will send vlad pcaps for these specific ones. At present, I don't know if these are affecting anything per se. > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:23:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:23:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1355) Hitting crl+c in broctl gives ugly output In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20223#comment-20223 ] Robin Sommer commented on BIT-1355: ----------------------------------- Part of BIT-1362. > Hitting crl+c in broctl gives ugly output > ----------------------------------------- > > Key: BIT-1355 > URL: https://bro-tracker.atlassian.net/browse/BIT-1355 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > Hitting ctrl+c in broctl results in an ugly stack-trace at the moment: > {code} > $ broctl > warning: new bro version detected (run the broctl "deploy" command) > Welcome to BroControl 1.3-162 > Type "help" for help. > [BroControl] > Traceback (most recent call last): > File "/xa/bro/master/bin/broctl", line 777, in > sys.exit(main()) > File "/xa/bro/master/bin/broctl", line 772, in main > cmdsuccess = loop.cmdloop("\nWelcome to BroControl %s\n\nType \"help\" for help.\n" % version.VERSION) > File "/xa/bro/master/lib/broctl/BroControl/brocmd.py", line 36, in cmdloop > line = py3bro.input(self.prompt) > KeyboardInterrupt > $ > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:23:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:23:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1355) Hitting crl+c in broctl gives ugly output In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1355: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Hitting crl+c in broctl gives ugly output > ----------------------------------------- > > Key: BIT-1355 > URL: https://bro-tracker.atlassian.net/browse/BIT-1355 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > Hitting ctrl+c in broctl results in an ugly stack-trace at the moment: > {code} > $ broctl > warning: new bro version detected (run the broctl "deploy" command) > Welcome to BroControl 1.3-162 > Type "help" for help. > [BroControl] > Traceback (most recent call last): > File "/xa/bro/master/bin/broctl", line 777, in > sys.exit(main()) > File "/xa/bro/master/bin/broctl", line 772, in main > cmdsuccess = loop.cmdloop("\nWelcome to BroControl %s\n\nType \"help\" for help.\n" % version.VERSION) > File "/xa/bro/master/lib/broctl/BroControl/brocmd.py", line 36, in cmdloop > line = py3bro.input(self.prompt) > KeyboardInterrupt > $ > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:32:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20224#comment-20224 ] Robin Sommer commented on BIT-1353: ----------------------------------- set timeout to 30s and make configurable, revisit later when Broker is there > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:33:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:33:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1349) Broctl stop output is not sorted anymore In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20225#comment-20225 ] Robin Sommer commented on BIT-1349: ----------------------------------- Fixed in BIT-1362. > Broctl stop output is not sorted anymore > ---------------------------------------- > > Key: BIT-1349 > URL: https://bro-tracker.atlassian.net/browse/BIT-1349 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Priority: Trivial > Fix For: 2.4 > > > Minor: the output of the worker nodes when doing broctl stop is not sorted anymore. We should either sort it (or just skip outputting it altogether) - at the moment it is not really useful; if there is no numerical order it is difficult to see if a number one wants to have in there is missing or not. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:33:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1352) Certificate validation script does not deal well with root-certs being sent by server In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1352: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > Certificate validation script does not deal well with root-certs being sent by server > ------------------------------------------------------------------------------------- > > Key: BIT-1352 > URL: https://bro-tracker.atlassian.net/browse/BIT-1352 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Johanna Amann > Fix For: 2.5 > > > Currently, the validate-certs script in policy does not deal well with certain certificate chains, where the trust-anchor is being sent by the server. We should be able to fix this by removing the trust-anchor automatically from the chain; solving this might potentially change the way root-certs are currently being loaded into Bro. > Example server: access.redhat.com -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:33:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:33:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1349) Broctl stop output is not sorted anymore In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1349: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Broctl stop output is not sorted anymore > ---------------------------------------- > > Key: BIT-1349 > URL: https://bro-tracker.atlassian.net/browse/BIT-1349 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Priority: Trivial > Fix For: 2.4 > > > Minor: the output of the worker nodes when doing broctl stop is not sorted anymore. We should either sort it (or just skip outputting it altogether) - at the moment it is not really useful; if there is no numerical order it is difficult to see if a number one wants to have in there is missing or not. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:34:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1345) Crash due to a bad dictionary insert In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1345: --------------------------------- Assignee: Jon Siwek > Crash due to a bad dictionary insert > ------------------------------------ > > Key: BIT-1345 > URL: https://bro-tracker.atlassian.net/browse/BIT-1345 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Aaron Eppert > Assignee: Jon Siwek > Priority: High > Fix For: 2.4 > > > #0 0x0000000000713b87 in Dictionary::Insert (this=0x1339840, new_entry=0xb18a9d0, copy_key=0) at /root//bro/src/Dict.cc:419 > #1 0x00000000007130b0 in Dictionary::Insert (this=0x1339840, key=0xa23f6d0, key_size=36, hash=658668102, val=0x67fde40, copy_key=0) at /root//bro/src/Dict.cc:158 > #2 0x00000000006cb508 in Dictionary::Insert (this=0x1339840, key=0x7ffff4ba81b0, val=0x67fde40) at /root//bro/src/Dict.h:47 > #3 0x000000000077ee9b in IDPDict::Insert (this=0x1339840, key=0xebf780 "#-..#21703#1182", val=0x67fde40) at /root//bro/src/Scope.h:18 > #4 0x000000000077ef05 in Scope::Insert (this=0x133a8b0, name=0xebf780 "#-..#21703#1182", id=0x67fde40) at /root//bro/src/Scope.h:26 > #5 0x00000000008010cc in MutableVal::Bind (this=0x14f451f0) at /root//bro/src/Val.cc:624 > #6 0x0000000000800ec8 in MutableVal::AddProperties (this=0x14f451f0, arg_props=2 '\002') at /root//bro/src/Val.cc:558 > #7 0x000000000080a8d6 in RecordVal::AddProperties (this=0x14f451f0, arg_props=2 '\002') at /root//bro/src/Val.cc:2866 > #8 0x0000000000805948 in TableVal::Assign (this=0xb1dab00, index=0x13e81770, k=0x0, new_val=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Val.cc:1502 > #9 0x0000000000805501 in TableVal::Assign (this=0xb1dab00, index=0x13e81770, new_val=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Val.cc:1442 > #10 0x0000000000738b13 in IndexExpr::Assign (this=0x2087350, f=0x12073280, v=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Expr.cc:3135 > #11 0x00000000007362a2 in RefExpr::Assign (this=0x2087540, f=0x12073280, v=0x14f451f0, opcode=OP_ASSIGN) at /root//bro/src/Expr.cc:2463 > #12 0x00000000007370ea in AssignExpr::Eval (this=0x20874d0, f=0x12073280) at /root//bro/src/Expr.cc:2673 > #13 0x00000000007e22bb in ExprStmt::Exec (this=0x2087660, f=0x12073280, flow=@0x7ffff4ba8624) at /root//bro/src/Stmt.cc:369 > #14 0x00000000007e8375 in StmtList::Exec (this=0x2082c80, f=0x12073280, flow=@0x7ffff4ba8624) at /root//bro/src/Stmt.cc:1764 > #15 0x000000000074e6cd in BroFunc::Call (this=0x2087e70, args=0x13525bb0, parent=0x0) at /root//bro/src/Func.cc:386 > #16 0x0000000000725883 in EventHandler::Call (this=0x2082160, vl=0x13525bb0, no_remote=false) at /root//bro/src/EventHandler.cc:80 > #17 0x00000000006d8cc2 in Event::Dispatch (this=0x620e610, no_remote=false) at /root//bro/src/Event.h:50 > #18 0x0000000000724ef7 in EventMgr::Dispatch (this=0xebd400) at /root//bro/src/Event.cc:111 > #19 0x0000000000725032 in EventMgr::Drain (this=0xebd400) at /root//bro/src/Event.cc:128 > #20 0x0000000000788828 in net_packet_dispatch (t=1426626559.98401, hdr=0x3314d40, pkt=0x7f14a8b464cc
, hdr_size=14, src_ps=0x3314c00) > at /root//bro/src/Net.cc:278 > #21 0x0000000000a786d5 in iosource::PktSrc::Process (this=0x3314c00) at /root//bro/src/iosource/PktSrc.cc:411 > #22 0x00000000007889f8 in net_run () at /root//bro/src/Net.cc:320 > #23 0x00000000006d8157 in main (argc=20, argv=0x7ffff4ba9188) at /root//bro/src/main.cc:1200 -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:38:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:38:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1342) Occasional test failures In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1342: --------------------------------- Assignee: Daniel Thayer > Occasional test failures > ------------------------ > > Key: BIT-1342 > URL: https://bro-tracker.atlassian.net/browse/BIT-1342 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Robin Sommer > Assignee: Daniel Thayer > Fix For: 2.4 > > > Two tests in current master fail for me occasionally (usually when I run the full broctl test-suite but not when I rerun just these failing tests). Diag output below. > {code} > command.start-stop-standalone ... failed > % 'btest-diff stop.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > stopping bro ... > Exception in thread Thread-1 (most likely raised during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/usr/lib64/python2.7/Queue.py", line 177, in get > File "/usr/lib64/python2.7/threading.py", line 354, in wait > : 'NoneType' object is not callable > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-stop-standalone/stop.out 2013-06-01 00:29:07.0000 > +++ stop.out 2015-03-17 22:50:01.857838625 +0000 > @@ -1 +1,9 @@ > stopping bro ... > +Exception in thread Thread-1 (most likely raised during interpreter shutdown): > +Traceback (most recent call last): > + File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/usr/lib64/python2.7/Queue.py", line 177, in get > + File "/usr/lib64/python2.7/threading.py", line 354, in wait > +: 'NoneType' object is not callable > ======================================= > [...] > command.start-cluster-slowstart ... failed > % 'btest-diff status2.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > Getting process status ... > Getting peer status ... > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > worker-1 worker localhost stopped > worker-2 worker localhost stopped > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-cluster-slowstart/status2.out 2015-03-04 20:16 > +++ status2.out 2015-03-17 22:50:26.578618684 +0000 > @@ -3,5 +3,5 @@ > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > -worker-1 worker localhost crashed > +worker-1 worker localhost stopped > worker-2 worker localhost stopped > ======================================= > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:41:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1339) Remove src and dst from notice In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1339: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > Remove src and dst from notice > ------------------------------ > > Key: BIT-1339 > URL: https://bro-tracker.atlassian.net/browse/BIT-1339 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > Email from Brian Kellog... > Related to this, I'm planning on deprecating $src and $dst from notices and removing their use from all shipped Bro scripts. > {quote} > I'm going through and updating the NOTICEs for different detection scripts built into Bro. Trying to get the generated NOTICE logs set correctly for ELSA to parse. It is working but I'm not sure if I'm doing this the most Bro appropriate way. Couple questions: > Is this the best way to accomplish this task? Secondly, if advisable, how do we get these script changes incorporated into Bro base? I'm not that experienced with git but willing to learn more if needed. These changes were made, again, to benefit ELSA searching/grouping and for the Bro correlation script recently released. > Here's what I changed/add to some of the built-in detection scripts (Lines with "+" are what I changed/added): > /opt/bro/share/bro/policy/protocols/ssh/detect-bruteforcing.bro > NOTICE([$note=Password_Guessing, > $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num), > $sub=sub_msg, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/ftp/detect-bruteforcing.bro > NOTICE([$note=FTP::Bruteforcing, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/http/detect-sqli.bro > NOTICE([$note=SQL_Injection_Attacker, > $msg="An SQL injection attacker was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=SQL_Injection_Victim, > $msg="An SQL injection victim was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=0.0.0.0,$orig_p=0/tcp,$resp_h=key$host,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/scan.bro > NOTICE([$note=Address_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=key$str], > + #$p=to_port(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=Port_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=key$str,$resp_p=0/tcp], > + #$dst=to_addr(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/detect-traceroute/main.bro > NOTICE([$note=Traceroute::Detected, > $msg=fmt("%s seems to be running traceroute using %s", src, proto), > + #$src=src, > + $id=[$orig_h=src,$orig_p=0/icmp,$resp_h=dst,$resp_p=0/icmp], > $identifier=cat(src,proto)]); > }]); > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:41:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1339) Remove src and dst from notice In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20226#comment-20226 ] Robin Sommer commented on BIT-1339: ----------------------------------- Turns out this needs more discussion, as the right solution isn't quite clear yet. > Remove src and dst from notice > ------------------------------ > > Key: BIT-1339 > URL: https://bro-tracker.atlassian.net/browse/BIT-1339 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > Email from Brian Kellog... > Related to this, I'm planning on deprecating $src and $dst from notices and removing their use from all shipped Bro scripts. > {quote} > I'm going through and updating the NOTICEs for different detection scripts built into Bro. Trying to get the generated NOTICE logs set correctly for ELSA to parse. It is working but I'm not sure if I'm doing this the most Bro appropriate way. Couple questions: > Is this the best way to accomplish this task? Secondly, if advisable, how do we get these script changes incorporated into Bro base? I'm not that experienced with git but willing to learn more if needed. These changes were made, again, to benefit ELSA searching/grouping and for the Bro correlation script recently released. > Here's what I changed/add to some of the built-in detection scripts (Lines with "+" are what I changed/added): > /opt/bro/share/bro/policy/protocols/ssh/detect-bruteforcing.bro > NOTICE([$note=Password_Guessing, > $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num), > $sub=sub_msg, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/ftp/detect-bruteforcing.bro > NOTICE([$note=FTP::Bruteforcing, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/http/detect-sqli.bro > NOTICE([$note=SQL_Injection_Attacker, > $msg="An SQL injection attacker was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=SQL_Injection_Victim, > $msg="An SQL injection victim was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=0.0.0.0,$orig_p=0/tcp,$resp_h=key$host,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/scan.bro > NOTICE([$note=Address_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=key$str], > + #$p=to_port(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=Port_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=key$str,$resp_p=0/tcp], > + #$dst=to_addr(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/detect-traceroute/main.bro > NOTICE([$note=Traceroute::Detected, > $msg=fmt("%s seems to be running traceroute using %s", src, proto), > + #$src=src, > + $id=[$orig_h=src,$orig_p=0/icmp,$resp_h=dst,$resp_p=0/icmp], > $identifier=cat(src,proto)]); > }]); > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:42:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:42:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1339) Remove src and dst from notice In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1339: --------------------------------- Assignee: (was: Seth Hall) > Remove src and dst from notice > ------------------------------ > > Key: BIT-1339 > URL: https://bro-tracker.atlassian.net/browse/BIT-1339 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Fix For: 2.5 > > > Email from Brian Kellog... > Related to this, I'm planning on deprecating $src and $dst from notices and removing their use from all shipped Bro scripts. > {quote} > I'm going through and updating the NOTICEs for different detection scripts built into Bro. Trying to get the generated NOTICE logs set correctly for ELSA to parse. It is working but I'm not sure if I'm doing this the most Bro appropriate way. Couple questions: > Is this the best way to accomplish this task? Secondly, if advisable, how do we get these script changes incorporated into Bro base? I'm not that experienced with git but willing to learn more if needed. These changes were made, again, to benefit ELSA searching/grouping and for the Bro correlation script recently released. > Here's what I changed/add to some of the built-in detection scripts (Lines with "+" are what I changed/added): > /opt/bro/share/bro/policy/protocols/ssh/detect-bruteforcing.bro > NOTICE([$note=Password_Guessing, > $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num), > $sub=sub_msg, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/ftp/detect-bruteforcing.bro > NOTICE([$note=FTP::Bruteforcing, > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/protocols/http/detect-sqli.bro > NOTICE([$note=SQL_Injection_Attacker, > $msg="An SQL injection attacker was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=SQL_Injection_Victim, > $msg="An SQL injection victim was discovered!", > $email_body_sections=vector(format_sqli_samples(r$samples)), > + #$src=key$host, > + $id=[$orig_h=0.0.0.0,$orig_p=0/tcp,$resp_h=key$host,$resp_p=0/tcp], > + $sub=cat(format_sqli_samples(r$samples)), > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/scan.bro > NOTICE([$note=Address_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=key$str], > + #$p=to_port(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > ? > NOTICE([$note=Port_Scan, > #$src=key$host, > + $id=[$orig_h=key$host,$orig_p=0/tcp,$resp_h=key$str,$resp_p=0/tcp], > + #$dst=to_addr(key$str), > $sub=side, > $msg=message, > $identifier=cat(key$host)]); > }]); > /opt/bro/share/bro/policy/misc/detect-traceroute/main.bro > NOTICE([$note=Traceroute::Detected, > $msg=fmt("%s seems to be running traceroute using %s", src, proto), > + #$src=src, > + $id=[$orig_h=src,$orig_p=0/icmp,$resp_h=dst,$resp_p=0/icmp], > $identifier=cat(src,proto)]); > }]); > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:43:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:43:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1337) Bro worker crash - terminate after 'std::length_error' In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20227#comment-20227 ] Robin Sommer commented on BIT-1337: ----------------------------------- Let's do a quick sanity check of the code. > Bro worker crash - terminate after 'std::length_error' > ------------------------------------------------------ > > Key: BIT-1337 > URL: https://bro-tracker.atlassian.net/browse/BIT-1337 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Josh Liburdi > Fix For: 2.4 > > > Running Bro master with the Kerberos and RDP analyzer branches resulted in one crashed worker on a pf_ring cluster. BroControl diag results below: > terminate called after throwing an instance of 'std::length_error' > what(): basic_string::_S_create > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 195850 Aborted (core dumped) nohup $mybro "$@" -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:44:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1336: --------------------------------- Assignee: Seth Hall > ElasticSearch indices in UTC > ---------------------------- > > Key: BIT-1336 > URL: https://bro-tracker.atlassian.net/browse/BIT-1336 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Seth Hall > Priority: Trivial > Fix For: 2.4 > > > For improved compatibility with Kibana and other ElasticSearch frontends, the timestamps on the Bro indices should be changed to UTC. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:44:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1337) Bro worker crash - terminate after 'std::length_error' In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1337: --------------------------------- Assignee: Vlad Grigorescu > Bro worker crash - terminate after 'std::length_error' > ------------------------------------------------------ > > Key: BIT-1337 > URL: https://bro-tracker.atlassian.net/browse/BIT-1337 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Josh Liburdi > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Running Bro master with the Kerberos and RDP analyzer branches resulted in one crashed worker on a pf_ring cluster. BroControl diag results below: > terminate called after throwing an instance of 'std::length_error' > what(): basic_string::_S_create > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 195850 Aborted (core dumped) nohup $mybro "$@" -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:45:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:45:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1331: ------------------------------ Priority: Low (was: High) > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Priority: Low > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:46:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1331: ------------------------------ Priority: Normal (was: Low) > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:48:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1329) BroControl scripts displays meta-information from bro logger In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20228#comment-20228 ] Robin Sommer commented on BIT-1329: ----------------------------------- Fixed in BIT-1362. > BroControl scripts displays meta-information from bro logger > ------------------------------------------------------------ > > Key: BIT-1329 > URL: https://bro-tracker.atlassian.net/browse/BIT-1329 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > When issuing a broctl scripts, the output contains meta bro-log-lines (like #fields, etc) that we probably do not want to display in this case. > Example: > {code} > [BroControl] > scripts manager > manager scripts are ok. > #separator \x09 > #set_separator , > #empty_field (empty) > #unset_field - > #path loaded_scripts > #open 2015-03-05-13-24-34 > #fields name > #types string > /xa/bro/master/share/bro/base/init-bare.bro > /xa/bro/master/share/bro/base/bif/const.bif.bro > ... > /xa/bro/master/share/bro/broctl/check.bro > #close 2015-03-05-13-24-34 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:48:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:48:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1329) BroControl scripts displays meta-information from bro logger In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1329: ------------------------------ Resolution: Fixed Status: Closed (was: Reopened) > BroControl scripts displays meta-information from bro logger > ------------------------------------------------------------ > > Key: BIT-1329 > URL: https://bro-tracker.atlassian.net/browse/BIT-1329 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > When issuing a broctl scripts, the output contains meta bro-log-lines (like #fields, etc) that we probably do not want to display in this case. > Example: > {code} > [BroControl] > scripts manager > manager scripts are ok. > #separator \x09 > #set_separator , > #empty_field (empty) > #unset_field - > #path loaded_scripts > #open 2015-03-05-13-24-34 > #fields name > #types string > /xa/bro/master/share/bro/base/init-bare.bro > /xa/bro/master/share/bro/base/bif/const.bif.bro > ... > /xa/bro/master/share/bro/broctl/check.bro > #close 2015-03-05-13-24-34 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:48:01 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Fri, 3 Apr 2015 13:48:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20229#comment-20229 ] Michal Purzynski commented on BIT-1363: --------------------------------------- No, I used unmodified Bro 2.3 and started it on a router with a configuration like this [manager] type=manager host=172.19.254.254 [proxy-1] type=proxy host=172.19.254.254 [nsm1-eth0] type=worker host=172.19.254.254 interface=eth0 Bro starts with a single worker and logs are generated. Name Type Host Status Pid Peers Started manager manager 172.19.254.254 running 16784 2 20 Feb 23:45:34 proxy-1 proxy 172.19.254.254 running 16824 2 20 Feb 23:45:36 nsm1-eth0 worker 172.19.254.254 running 16849 2 20 Feb 23:45:38 > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:50:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:50:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20230#comment-20230 ] Robin Sommer commented on BIT-1306: ----------------------------------- Check the change. > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:50:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:50:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1263) Implementing three event handlers for supported data structure in Modbus Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1263: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > Implementing three event handlers for supported data structure in Modbus Analyzer > --------------------------------------------------------------------------------- > > Key: BIT-1263 > URL: https://bro-tracker.atlassian.net/browse/BIT-1263 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: hui > Priority: Low > Labels: analyzer, modbus > Fix For: 2.5 > > > Three support data structures are defined in Modbus analyzer: > FileRecordRequest, > FileRecordResponse, > ReferenceWithData > Three event handlers are declared for them. > The changes are already made and pushed into the branch: > topic/hui/modbus-events2 -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:50:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:50:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1306: --------------------------------- Assignee: Robin Sommer > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:53:03 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:53:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1154) Formatters restructed in: topic/seth/json-formatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1154: --------------------------------- Assignee: Seth Hall > Formatters restructed in: topic/seth/json-formatter > --------------------------------------------------- > > Key: BIT-1154 > URL: https://bro-tracker.atlassian.net/browse/BIT-1154 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.4 > > > topic/seth/json-formatter has an abstraction for Formatters and I created a formatters directory under threading. There is also a new JSON formatter and support in the Ascii and ElasticSearch writers for the JSON formatter. > I went ahead and threw in per-filter configuration options for the Ascii writer for all of the options that were exposed globally too. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:53:03 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 3 Apr 2015 13:53:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20231#comment-20231 ] Johanna Amann commented on BIT-1363: ------------------------------------ I am not sure we can do this easily, because we need something that makes sure that the same flows always go to the same bro workers... this seems like it might be a job for packet-bricks or similar and not for Bro. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:56:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-947) Incorrect size calculation for SSH failed/successful heuristic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20232#comment-20232 ] Robin Sommer commented on BIT-947: ---------------------------------- Should be fixed with new SSH code. > Incorrect size calculation for SSH failed/successful heuristic > -------------------------------------------------------------- > > Key: BIT-947 > URL: https://bro-tracker.atlassian.net/browse/BIT-947 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > We're getting a lot of false positives for successful SSH logins from a source that we recently blackholed. I suspect what's happening is that the retransmissions keep bumping up the size of the connection, until it crosses the threshold for a "successful" connection. > With the changes from BIT-730: Find and fix tcp sequence counting bugs, is it possible to improve the accuracy of the reported size? -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:56:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-947) Incorrect size calculation for SSH failed/successful heuristic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-947: ----------------------------- Resolution: Fixed Status: Closed (was: Open) > Incorrect size calculation for SSH failed/successful heuristic > -------------------------------------------------------------- > > Key: BIT-947 > URL: https://bro-tracker.atlassian.net/browse/BIT-947 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > We're getting a lot of false positives for successful SSH logins from a source that we recently blackholed. I suspect what's happening is that the retransmissions keep bumping up the size of the connection, until it crosses the threshold for a "successful" connection. > With the changes from BIT-730: Find and fix tcp sequence counting bugs, is it possible to improve the accuracy of the reported size? -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:57:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:57:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-931) Ascii writer does not escape empty sets / vectors In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-931: ----------------------------- Fix Version/s: (was: 2.4) 2.5 > Ascii writer does not escape empty sets / vectors > ------------------------------------------------- > > Key: BIT-931 > URL: https://bro-tracker.atlassian.net/browse/BIT-931 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Seth Hall > Fix For: 2.5 > > > The script > {noformat} > redef LogAscii::empty_field = "EMPTY"; > module SSH; > export { > redef enum Log::ID += { LOG }; > type Log: record { > ss: set[string]; > } &log; > } > event bro_init() > { > Log::create_stream(SSH::LOG, [$columns=Log]); > Log::write(SSH::LOG, [ > $ss=set("EMPTY") > ]); > } > {noformat} > Outputs the line > {noformat} > EMPTY > {noformat} > to a log-file. This makes it impossible to distinguish a line containing EMPTY from a line containing an empty set. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:58:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-631) Special message for broctl locking when done by cron In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20233#comment-20233 ] Robin Sommer commented on BIT-631: ---------------------------------- Fixed in BIT-1362. > Special message for broctl locking when done by cron > ---------------------------------------------------- > > Key: BIT-631 > URL: https://bro-tracker.atlassian.net/browse/BIT-631 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: BroControl > Reporter: Seth Hall > Assignee: Daniel Thayer > Fix For: 2.4 > > > If the broctl lock is being held by the cron command it would be nice if the message that indicates a lock is already held would indicate if it is the cron command. If multiple people are working with broctl the person that gets a lock doesn't know if it's because of another user or because they happened to be trying to do something while the cron command is running. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:58:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 13:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-631) Special message for broctl locking when done by cron In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-631: ----------------------------- Resolution: Fixed Status: Closed (was: Open) > Special message for broctl locking when done by cron > ---------------------------------------------------- > > Key: BIT-631 > URL: https://bro-tracker.atlassian.net/browse/BIT-631 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: BroControl > Reporter: Seth Hall > Assignee: Daniel Thayer > Fix For: 2.4 > > > If the broctl lock is being held by the cron command it would be nice if the message that indicates a lock is already held would indicate if it is the cron command. If multiple people are working with broctl the person that gets a lock doesn't know if it's because of another user or because they happened to be trying to do something while the cron command is running. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 11:59:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 3 Apr 2015 13:59:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1369: --------------------------------- Fix Version/s: 2.4 > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 12:00:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 3 Apr 2015 14:00:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1370: --------------------------------- Fix Version/s: 2.4 > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 12:00:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 3 Apr 2015 14:00:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1368: ------------------------------ Fix Version/s: 2.4 > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 12:31:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 3 Apr 2015 14:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-844: ----------------------------- Assignee: Jon Siwek > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Jon Siwek > Priority: Low > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 12:43:00 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Fri, 3 Apr 2015 14:43:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20234#comment-20234 ] Justin Azoff commented on BIT-1356: ----------------------------------- I wonder if that process is just left over from when bro calls system() to run the child process... I'm not sure what to do about this. killing that process is not the best idea, but there may be a way to wait for it. I think there is a larger issue here in that log rotation has a number of problems: * All logs get rotated+compressed at the same time, causing a CPU/IO Storm * Logs are compressed on the fly to their destination, then the originals are removed * If compression is not in use, logs are copied and then removed (rather than moved) * If using something like the sftp handler and sftp fails, nothing is retried. * Bro is the parent process to all of this. * If bro crashes logs often end up in a crash directory rather than the proper location. I think that the only thing bro should be doing is atomically moving the current logs to an archive directory or an archive staging directory. The compression,moving,copying,uploading would be done by an external tool. There are a number of benefits to this: * If bro crashes recovering the logs is easy: on startup just move any existing log files to the staging dir. A bro crash could never result in a partially compressed/rotated log file * Compression can be done serially or with limited parallelism rather than all at once * You could even delay the compression to idle periods * Bugs like this would not occur since stopping bro would just require the logs to be moved, not compressed > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 12:58:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 3 Apr 2015 14:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20235#comment-20235 ] Jon Siwek commented on BIT-1363: -------------------------------- {quote} I am not sure we can do this easily, because we need something that makes sure that the same flows always go to the same bro workers... this seems like it might be a job for packet-bricks or similar and not for Bro. {quote} I thought the PACKET_FANOUT_HASH socket option helps there? > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 13:00:01 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Fri, 3 Apr 2015 15:00:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20236#comment-20236 ] Michal Purzynski commented on BIT-1363: --------------------------------------- That is exactly what Suricata does ./src/runmode-af-packet.c: aconf->cluster_type = PACKET_FANOUT_HASH; - PACKET_FANOUT_HASH: schedule to socket by skb's packet hash > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 3 13:16:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Fri, 3 Apr 2015 15:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20237#comment-20237 ] Michal Purzynski commented on BIT-1363: --------------------------------------- http://man7.org/linux/man-pages/man7/packet.7.html PACKET_FANOUT_HASH, sends packets from the same flow to the same socket to maintain per-flow ordering. For each packet, it chooses a socket by taking the packet flow hash modulo the number of sockets in the group, where a flow hash is a hash over network-layer address and optional transport-layer port fields. So each process would need to create a socket and join the same group of sockets with setsockopt() and begin receiving packets. FANOUT_HASH has even an optional defragmenting support. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Sat Apr 4 00:00:29 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 4 Apr 2015 00:00:29 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504040700.t3470TN0020658@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer Justin Azoff 2015-04-01 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From noreply at bro.org Sun Apr 5 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 5 Apr 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504050700.t3570MXx018732@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer Justin Azoff 2015-04-01 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From noreply at bro.org Mon Apr 6 00:00:59 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 6 Apr 2015 00:00:59 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504060700.t3670xno023560@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1362 [1] BroControl Daniel Thayer Justin Azoff 2015-04-01 2.4 Normal topic/dnthayer/fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- -------------------------------------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] #28 [6] bro aeppert [7] 2015-03-20 Seems to fix a case where an entry in the table may be null on insert. [8] [1] BIT-1362 https://bro-tracker.atlassian.net/browse/BIT-1362 [2] fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 [6] Pull Request #28 https://github.com/bro/bro/pull/28 [7] aeppert https://github.com/aeppert [8] Merge Pull Request #28 with git pull --no-ff --no-commit https://github.com/aeppert/bro.git master From jira at bro-tracker.atlassian.net Mon Apr 6 04:04:01 2015 From: jira at bro-tracker.atlassian.net (Ted Llewellyn (JIRA)) Date: Mon, 6 Apr 2015 06:04:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20238#comment-20238 ] Ted Llewellyn commented on BIT-1361: ------------------------------------ Still running since Wednesday evening (Eastern) with the patch. This appears to be fixed. Thanks, Jon! > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Assignee: Jon Siwek > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 08:11:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 6 Apr 2015 10:11:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1362) topic/dnthayer/fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1362: ------------------------------ Status: Closed (was: Merge Request) > topic/dnthayer/fixes-for-2.4 > ---------------------------- > > Key: BIT-1362 > URL: https://bro-tracker.atlassian.net/browse/BIT-1362 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/fixes-for-2.4 contains fixes that address > BIT-1360, 1355, 1349, 1329, and 631, as well as various other fixes > and improvements. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 08:24:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 10:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1361: ------------------------------ Assignee: (was: Jon Siwek) > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 08:24:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 10:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1361: --------------------------- Status: Merge Request (was: Open) > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 10:23:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 12:23:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1367: ------------------------------ Assignee: (was: Jon Siwek) > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 10:25:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 12:25:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20239#comment-20239 ] Jon Siwek commented on BIT-1367: -------------------------------- topic/jsiwek/bit-1367 improves the type check/coercion. I branched it off topic/johanna/sft-port, so merging it will bring in both changes. > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 10:25:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 12:25:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1367: --------------------------- Status: Merge Request (was: Open) > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:23:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 6 Apr 2015 15:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1367: ---------------------------------- Assignee: Johanna Amann > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Johanna Amann > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:23:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 6 Apr 2015 15:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1361: ---------------------------------- Assignee: Johanna Amann > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Assignee: Johanna Amann > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:26:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 6 Apr 2015 15:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1361: ---------------------------------- Assignee: (was: Johanna Amann) > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:30:00 2015 From: jira at bro-tracker.atlassian.net (Chris Fowler (JIRA)) Date: Mon, 6 Apr 2015 15:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1371) check-cmake causes make-rpm-packages to fail In-Reply-To: References: Message-ID: Chris Fowler created BIT-1371: --------------------------------- Summary: check-cmake causes make-rpm-packages to fail Key: BIT-1371 URL: https://bro-tracker.atlassian.net/browse/BIT-1371 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Environment: CentOS 7 x64 Reporter: Chris Fowler Attempting to use pkg/make-rpm-packages to build packages on CentOS 7 fails since the pkg/check-cmake script is just checking for an exact match to the version string. CentOS 7's version of cmake (2.8.11) is newer than the one being checked for (2.8.6) and will correctly work for building the packages, but this: bq. #!/bin/sh bq. bq. CMAKE_PACK_REQ="cmake version 2.8.6" bq. CMAKE_VER=`cmake -version` bq. bq. if [ "${CMAKE_VER}" != "${CMAKE_PACK_REQ}" ]; then bq. echo "Package creation requires ${CMAKE_PACK_REQ}" >&2 bq. exit 1 bq. fi will not allow newer versions to be used without bypassing the check. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:45:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:45:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1371) check-cmake causes make-rpm-packages to fail In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1371: ------------------------------ Assignee: Jon Siwek > check-cmake causes make-rpm-packages to fail > -------------------------------------------- > > Key: BIT-1371 > URL: https://bro-tracker.atlassian.net/browse/BIT-1371 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 7 x64 > Reporter: Chris Fowler > Assignee: Jon Siwek > Fix For: 2.4 > > > Attempting to use pkg/make-rpm-packages to build packages on CentOS 7 fails since the pkg/check-cmake script is just checking for an exact match to the version string. CentOS 7's version of cmake (2.8.11) is newer than the one being checked for (2.8.6) and will correctly work for building the packages, but this: > bq. #!/bin/sh > bq. > bq. CMAKE_PACK_REQ="cmake version 2.8.6" > bq. CMAKE_VER=`cmake -version` > bq. > bq. if [ "${CMAKE_VER}" != "${CMAKE_PACK_REQ}" ]; then > bq. echo "Package creation requires ${CMAKE_PACK_REQ}" >&2 > bq. exit 1 > bq. fi > will not allow newer versions to be used without bypassing the check. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:45:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:45:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1371) check-cmake causes make-rpm-packages to fail In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1371: --------------------------- Fix Version/s: 2.4 > check-cmake causes make-rpm-packages to fail > -------------------------------------------- > > Key: BIT-1371 > URL: https://bro-tracker.atlassian.net/browse/BIT-1371 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 7 x64 > Reporter: Chris Fowler > Assignee: Jon Siwek > Fix For: 2.4 > > > Attempting to use pkg/make-rpm-packages to build packages on CentOS 7 fails since the pkg/check-cmake script is just checking for an exact match to the version string. CentOS 7's version of cmake (2.8.11) is newer than the one being checked for (2.8.6) and will correctly work for building the packages, but this: > bq. #!/bin/sh > bq. > bq. CMAKE_PACK_REQ="cmake version 2.8.6" > bq. CMAKE_VER=`cmake -version` > bq. > bq. if [ "${CMAKE_VER}" != "${CMAKE_PACK_REQ}" ]; then > bq. echo "Package creation requires ${CMAKE_PACK_REQ}" >&2 > bq. exit 1 > bq. fi > will not allow newer versions to be used without bypassing the check. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:56:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-844: -------------------------- Fix Version/s: 2.4 > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Jon Siwek > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:58:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20240#comment-20240 ] Jon Siwek commented on BIT-844: ------------------------------- Fixed in topic/jsiwek/bit-844 Unrelated, I also removed some signature "benchmarking" code that I don't think deserves to be in the production version of the code. > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Jon Siwek > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:58:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-844: ----------------------------- Assignee: (was: Jon Siwek) > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 13:58:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 15:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-844: -------------------------- Status: Merge Request (was: Open) > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 14:00:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 16:00:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1364) Bro does not attach UDP analyzers when signature matches after first packet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1364: --------------------------- Resolution: Duplicate Status: Closed (was: Open) Duplicate of BIT-844. I tested the patch mentioned in that ticket against the DTLS examples in this ticket and it seemed to work, please double check that if you can. > Bro does not attach UDP analyzers when signature matches after first packet > --------------------------------------------------------------------------- > > Key: BIT-1364 > URL: https://bro-tracker.atlassian.net/browse/BIT-1364 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Jon Siwek > Priority: Low > Fix For: 2.4 > > Attachments: f1.pcap, f2.pcap > > > At the moment, Bro only seems to attach UDP analyzers based on signatures, if the very first UDP packet matches the signature. Even if later UDP packets match the signature, the analyzer is not attached. > The attachments contain a test case. f1.pcap contains a DTLS connection with a few STUN packets that are sent first, which is not recognized as DTLS. f2.pcap contains the same connection with the first few packets missing. > It would probably be nice if one could at least opt to attach analyzers at a later time too, if a signature matches. (I know that 2.4 is probably a bit optimistic for this). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 6 14:19:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 6 Apr 2015 16:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1371) check-cmake causes make-rpm-packages to fail In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1371: --------------------------- Resolution: Fixed Status: Closed (was: Open) I just removed the version check. I originally intended these scripts to just be for internal use on a very limited set of target platforms and Bro's binary packaging will eventually be done differently: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2015-February/009111.html You might want to check that out (but the CPack/CMake-based build scripts in the pkg/ dir will still probably stick around until they break somehow and there's no one around that feels like maintaining them anymore). > check-cmake causes make-rpm-packages to fail > -------------------------------------------- > > Key: BIT-1371 > URL: https://bro-tracker.atlassian.net/browse/BIT-1371 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 7 x64 > Reporter: Chris Fowler > Assignee: Jon Siwek > Fix For: 2.4 > > > Attempting to use pkg/make-rpm-packages to build packages on CentOS 7 fails since the pkg/check-cmake script is just checking for an exact match to the version string. CentOS 7's version of cmake (2.8.11) is newer than the one being checked for (2.8.6) and will correctly work for building the packages, but this: > bq. #!/bin/sh > bq. > bq. CMAKE_PACK_REQ="cmake version 2.8.6" > bq. CMAKE_VER=`cmake -version` > bq. > bq. if [ "${CMAKE_VER}" != "${CMAKE_PACK_REQ}" ]; then > bq. echo "Package creation requires ${CMAKE_PACK_REQ}" >&2 > bq. exit 1 > bq. fi > will not allow newer versions to be used without bypassing the check. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Tue Apr 7 00:00:31 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 7 Apr 2015 00:00:31 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504070700.t3770VmK025666@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- ------------------------------------------------------------------------------- BIT-1367 [1] Bro Johanna Amann Johanna Amann 2015-04-06 2.4 Normal Type clashing problem when records with default values are used in sets. BIT-1361 [2] Bro Ted Llewellyn - 2015-04-06 2.4 Normal New installation of Bro crashes and core dumps with error indicating ssh/binpac BIT-844 [3] Bro Jon Siwek - 2015-04-06 2.4 Low UDP payload signature patterns don't match packet-wise Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1367 https://bro-tracker.atlassian.net/browse/BIT-1367 [2] BIT-1361 https://bro-tracker.atlassian.net/browse/BIT-1361 [3] BIT-844 https://bro-tracker.atlassian.net/browse/BIT-844 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From noreply at bro.org Wed Apr 8 00:00:25 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 8 Apr 2015 00:00:25 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504080700.t3870P8J003566@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- ------------------------------------------------------------------------------- BIT-1367 [1] Bro Johanna Amann Johanna Amann 2015-04-06 2.4 Normal Type clashing problem when records with default values are used in sets. BIT-1361 [2] Bro Ted Llewellyn - 2015-04-06 2.4 Normal New installation of Bro crashes and core dumps with error indicating ssh/binpac BIT-844 [3] Bro Jon Siwek - 2015-04-06 2.4 Low UDP payload signature patterns don't match packet-wise Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1367 https://bro-tracker.atlassian.net/browse/BIT-1367 [2] BIT-1361 https://bro-tracker.atlassian.net/browse/BIT-1361 [3] BIT-844 https://bro-tracker.atlassian.net/browse/BIT-844 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From noreply at bro.org Thu Apr 9 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 9 Apr 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504090700.t3970QSX006761@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- ------------------------------------------------------------------------------- BIT-1367 [1] Bro Johanna Amann Johanna Amann 2015-04-06 2.4 Normal Type clashing problem when records with default values are used in sets. BIT-1361 [2] Bro Ted Llewellyn - 2015-04-06 2.4 Normal New installation of Bro crashes and core dumps with error indicating ssh/binpac BIT-844 [3] Bro Jon Siwek - 2015-04-06 2.4 Low UDP payload signature patterns don't match packet-wise Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1367 https://bro-tracker.atlassian.net/browse/BIT-1367 [2] BIT-1361 https://bro-tracker.atlassian.net/browse/BIT-1361 [3] BIT-844 https://bro-tracker.atlassian.net/browse/BIT-844 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Thu Apr 9 12:08:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 9 Apr 2015 14:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1361: --------------------------------- Assignee: Robin Sommer > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Assignee: Robin Sommer > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 9 12:13:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 9 Apr 2015 14:13:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-844: -------------------------------- Assignee: Robin Sommer > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 9 14:52:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 9 Apr 2015 16:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20243#comment-20243 ] Robin Sommer commented on BIT-844: ---------------------------------- {quote} Unrelated, I also removed some signature "benchmarking" code that I don't think deserves to be in the production version of the code. {quote} Good call. One question: {code} void RuleMatcher::ClearEndpointState(RuleEndpointState* state) { [...] - ExecPureRules(state, 1); {code} Why the removal of that method call? > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 9 15:22:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 9 Apr 2015 17:22:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20244#comment-20244 ] Jon Siwek commented on BIT-844: ------------------------------- I didn't see anyone actually call RuleMatcher::ClearEndpointState except for what I added in the patch, so I couldn't really even tell if any of the code there was "correct" to start with, so I was mostly just removing things to adapt it specifically to UDP packet-wise matching. For the removal of that ExecPureRules call specifically, I noticed the comment in FinishEndpoint saying it has it's own ExecPureRules call there match rules at the end of the connection/stream, so I thought maybe that was the original intention of the now-dead-code in ClearEndpointState and just removed it since FinishEndpoint takes care of it. And the fact the call to ExecPureRules is setting the eos parameter to signal end-of-stream makes me unsure whether it would still be in the right place. What do you think? > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 9 20:57:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 9 Apr 2015 22:57:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1368: ------------------------------ Assignee: Jon Siwek (was: Seth Hall) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Jon Siwek > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Fri Apr 10 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 10 Apr 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504100700.t3A70QoV019498@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- ------------------------------------------------------------------------------- BIT-1367 [1] Bro Johanna Amann Johanna Amann 2015-04-06 2.4 Normal Type clashing problem when records with default values are used in sets. BIT-1361 [2] Bro Ted Llewellyn Robin Sommer 2015-04-09 2.4 Normal New installation of Bro crashes and core dumps with error indicating ssh/binpac BIT-844 [3] Bro Jon Siwek Robin Sommer 2015-04-09 2.4 Low UDP payload signature patterns don't match packet-wise Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1367 https://bro-tracker.atlassian.net/browse/BIT-1367 [2] BIT-1361 https://bro-tracker.atlassian.net/browse/BIT-1361 [3] BIT-844 https://bro-tracker.atlassian.net/browse/BIT-844 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Fri Apr 10 07:45:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 09:45:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20245#comment-20245 ] Robin Sommer commented on BIT-844: ---------------------------------- Looking at the code again, I believe we still need this ExecPureRules() call. it's actually playing a similar role as the one in FinishEndpoint: making sure that at the end of the matching process, we have indeed reported all matches. However, for packet-wise matching, "the end of the matching process" occurs with every packet, i.e., each time the state gets cleared. that's also the interpretation of the end-of-stream here; it's essentially reporting lots of little streams to the engine. So I believe that without this call, there could be matches missing for some forms of "pure" rules (those without any payload patterns). It's unlikely and these are rarely used these days anyways, and I'm not gonna bother finding a test case, but I'll add the call back in; shouldn't change anything else anyways. > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 08:10:03 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 10:10:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1306: --------------------------------- Assignee: (was: Robin Sommer) > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 08:10:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 10:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20246#comment-20246 ] Robin Sommer commented on BIT-1306: ----------------------------------- Turns out this change was part of the introduction of the iosource_mgr. That mgr has ownership of all IOSources registered with it, which includes the remote serializer. So deleting the iosource_mgr will delete the remote serializer, which is why this explicit delete went aways. (The same applies to other iosources: there used to be deletes for dns_mgr/event_player/etc., which likewise went away). Aashish, did you ever get to try if Jon's patch made a difference? If it actually did, then there's something with the iosource_mgr clean up not working. (Btw, I learned a fun new git option when looking into this: {{git log -L 368,397:main.cc}} shows all commits that contributed to that particular block of code, as it is now). > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 08:31:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 10:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1361) New installation of Bro crashes and core dumps with error indicating ssh/binpac In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1361: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > New installation of Bro crashes and core dumps with error indicating ssh/binpac > ------------------------------------------------------------------------------- > > Key: BIT-1361 > URL: https://bro-tracker.atlassian.net/browse/BIT-1361 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port > Reporter: Ted Llewellyn > Assignee: Robin Sommer > Labels: binpac, ssh > Fix For: 2.4 > > Attachments: bro-bt-033115.txt > > > diag results: > [BroControl] > diag > [bro] > Bro 2.3-633 > Linux 3.2.0-4-686-pae > No gdb installed. > ==== No reporter.log > ==== stderr.log > listening on eth1, capture length 8192 bytes > bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed. > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@" > ==== stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) unlimited > virtual memory (kbytes, -v) unlimited > core file size (blocks, -c) unlimited > ==== .cmdline > -i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE= > ==== .status > RUNNING [net_run] > ==== No prof.log > ==== No packet_filter.log > ==== No loaded_scripts.log > [BroControl] > -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 08:31:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 10:31:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-844: ----------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 10:19:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 10 Apr 2015 12:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-844) UDP payload signature patterns don't match packet-wise In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20247#comment-20247 ] Jon Siwek commented on BIT-844: ------------------------------- bq. it's essentially reporting lots of little streams to the engine. Yeah, that makes sense. bq. I'll add the call back in Thanks. > UDP payload signature patterns don't match packet-wise > ------------------------------------------------------ > > Key: BIT-844 > URL: https://bro-tracker.atlassian.net/browse/BIT-844 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > The docs say: > {noformat} > Regular expressions are implicitly anchored, i.e., they work as if prefixed with the ^ operator. For reassembled TCP connections, they are anchored at the first byte of the payload stream. For all other connections, they are anchored at the first payload byte of each packet. To match at arbitrary positions, you can prefix the regular expression with .*, as done in the examples above. > {noformat} > But for a UDP connection made up of 2 packets with payloads "XXXX'" and then "YYYY", I still need the ".*" prefix to match on the 2nd: > {noformat} > signature yyyy { > ip-proto = udp > payload /.*YYYY/ > event "Found YYYY" > } > {noformat} > Changing the pattern to {{/YYYY/}} or {{/^YYYY/}} results in no match (but does match if I flip order of packets). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:12:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20248#comment-20248 ] Robin Sommer commented on BIT-1370: ----------------------------------- Seth going to review the code. > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:16:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20249#comment-20249 ] Robin Sommer commented on BIT-1369: ----------------------------------- Vlad to double-check there are tests, then file merge request. We merge as is right now. > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:24:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20250#comment-20250 ] Robin Sommer commented on BIT-1368: ----------------------------------- Jon to propose new names for fa_* types. > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Jon Siwek > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:29:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:29:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1306: --------------------------------- Assignee: Robin Sommer > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:29:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:29:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20251#comment-20251 ] Robin Sommer commented on BIT-1306: ----------------------------------- Robin to check if insource manager indeed deletes the remote serializer. > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:29:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:29:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20252#comment-20252 ] Robin Sommer commented on BIT-1356: ----------------------------------- This may be relates to BIT-1306, let's wait for that. > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:30:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20252#comment-20252 ] Robin Sommer edited comment on BIT-1356 at 4/10/15 1:29 PM: ------------------------------------------------------------ This may be related to BIT-1306, let's wait for that. was (Author: robin): This may be relates to BIT-1306, let's wait for that. > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:31:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1345) Crash due to a bad dictionary insert In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1345: ------------------------------ Resolution: Cannot Reproduce Status: Closed (was: Open) > Crash due to a bad dictionary insert > ------------------------------------ > > Key: BIT-1345 > URL: https://bro-tracker.atlassian.net/browse/BIT-1345 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Aaron Eppert > Assignee: Jon Siwek > Priority: High > Fix For: 2.4 > > > #0 0x0000000000713b87 in Dictionary::Insert (this=0x1339840, new_entry=0xb18a9d0, copy_key=0) at /root//bro/src/Dict.cc:419 > #1 0x00000000007130b0 in Dictionary::Insert (this=0x1339840, key=0xa23f6d0, key_size=36, hash=658668102, val=0x67fde40, copy_key=0) at /root//bro/src/Dict.cc:158 > #2 0x00000000006cb508 in Dictionary::Insert (this=0x1339840, key=0x7ffff4ba81b0, val=0x67fde40) at /root//bro/src/Dict.h:47 > #3 0x000000000077ee9b in IDPDict::Insert (this=0x1339840, key=0xebf780 "#-..#21703#1182", val=0x67fde40) at /root//bro/src/Scope.h:18 > #4 0x000000000077ef05 in Scope::Insert (this=0x133a8b0, name=0xebf780 "#-..#21703#1182", id=0x67fde40) at /root//bro/src/Scope.h:26 > #5 0x00000000008010cc in MutableVal::Bind (this=0x14f451f0) at /root//bro/src/Val.cc:624 > #6 0x0000000000800ec8 in MutableVal::AddProperties (this=0x14f451f0, arg_props=2 '\002') at /root//bro/src/Val.cc:558 > #7 0x000000000080a8d6 in RecordVal::AddProperties (this=0x14f451f0, arg_props=2 '\002') at /root//bro/src/Val.cc:2866 > #8 0x0000000000805948 in TableVal::Assign (this=0xb1dab00, index=0x13e81770, k=0x0, new_val=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Val.cc:1502 > #9 0x0000000000805501 in TableVal::Assign (this=0xb1dab00, index=0x13e81770, new_val=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Val.cc:1442 > #10 0x0000000000738b13 in IndexExpr::Assign (this=0x2087350, f=0x12073280, v=0x14f451f0, op=OP_ASSIGN) at /root//bro/src/Expr.cc:3135 > #11 0x00000000007362a2 in RefExpr::Assign (this=0x2087540, f=0x12073280, v=0x14f451f0, opcode=OP_ASSIGN) at /root//bro/src/Expr.cc:2463 > #12 0x00000000007370ea in AssignExpr::Eval (this=0x20874d0, f=0x12073280) at /root//bro/src/Expr.cc:2673 > #13 0x00000000007e22bb in ExprStmt::Exec (this=0x2087660, f=0x12073280, flow=@0x7ffff4ba8624) at /root//bro/src/Stmt.cc:369 > #14 0x00000000007e8375 in StmtList::Exec (this=0x2082c80, f=0x12073280, flow=@0x7ffff4ba8624) at /root//bro/src/Stmt.cc:1764 > #15 0x000000000074e6cd in BroFunc::Call (this=0x2087e70, args=0x13525bb0, parent=0x0) at /root//bro/src/Func.cc:386 > #16 0x0000000000725883 in EventHandler::Call (this=0x2082160, vl=0x13525bb0, no_remote=false) at /root//bro/src/EventHandler.cc:80 > #17 0x00000000006d8cc2 in Event::Dispatch (this=0x620e610, no_remote=false) at /root//bro/src/Event.h:50 > #18 0x0000000000724ef7 in EventMgr::Dispatch (this=0xebd400) at /root//bro/src/Event.cc:111 > #19 0x0000000000725032 in EventMgr::Drain (this=0xebd400) at /root//bro/src/Event.cc:128 > #20 0x0000000000788828 in net_packet_dispatch (t=1426626559.98401, hdr=0x3314d40, pkt=0x7f14a8b464cc
, hdr_size=14, src_ps=0x3314c00) > at /root//bro/src/Net.cc:278 > #21 0x0000000000a786d5 in iosource::PktSrc::Process (this=0x3314c00) at /root//bro/src/iosource/PktSrc.cc:411 > #22 0x00000000007889f8 in net_run () at /root//bro/src/Net.cc:320 > #23 0x00000000006d8157 in main (argc=20, argv=0x7ffff4ba9188) at /root//bro/src/main.cc:1200 -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:33:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:33:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1337) Bro worker crash - terminate after 'std::length_error' In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1337: --------------------------------- Assignee: Seth Hall (was: Vlad Grigorescu) > Bro worker crash - terminate after 'std::length_error' > ------------------------------------------------------ > > Key: BIT-1337 > URL: https://bro-tracker.atlassian.net/browse/BIT-1337 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Josh Liburdi > Assignee: Seth Hall > Fix For: 2.4 > > > Running Bro master with the Kerberos and RDP analyzer branches resulted in one crashed worker on a pf_ring cluster. BroControl diag results below: > terminate called after throwing an instance of 'std::length_error' > what(): basic_string::_S_create > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 195850 Aborted (core dumped) nohup $mybro "$@" -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:35:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:35:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20253#comment-20253 ] Robin Sommer commented on BIT-1333: ----------------------------------- Needs code review, probably not working quite right, messes up the test-suite. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:35:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:35:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1333: --------------------------------- Assignee: Robin Sommer (was: Seth Hall) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:37:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1331: --------------------------------- Assignee: Robin Sommer > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Assignee: Robin Sommer > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:38:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20254#comment-20254 ] Robin Sommer commented on BIT-1331: ----------------------------------- Robin to look at the code if something sticks out that could trigger this. > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Assignee: Robin Sommer > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:40:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:40:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1325) multiple sqlite writers to same db file yields "database is locked" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1325: ------------------------------ Priority: Low (was: Normal) > multiple sqlite writers to same db file yields "database is locked" error > ------------------------------------------------------------------------- > > Key: BIT-1325 > URL: https://bro-tracker.atlassian.net/browse/BIT-1325 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Tony Cebzanov > Assignee: Johanna Amann > Priority: Low > Labels: logging, sqlite > Fix For: 2.4 > > Attachments: bro_sqlite_busy_wait.patch > > > I want to have multiple log streams logged to the same sqlite database, but when trying to log to sqlite using the following configuration: > {code} > local filter: Log::Filter = > [ > $name="sqlite_conn", > $path="analysis", > $config=table(["tablename"] = "conn"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(Conn::LOG, filter); > local http_filter: Log::Filter = > [ > $name="sqlite_http", > $path="analysis", > $config=table(["tablename"] = "http"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(HTTP::LOG, http_filter); > {code} > I get the following error: > {code} > error: analysis/Log::WRITER_SQLITE: Error executing table creation statement: database is locked > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 11:45:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 13:45:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1372) Clean up ---help In-Reply-To: References: Message-ID: Robin Sommer created BIT-1372: --------------------------------- Summary: Clean up ---help Key: BIT-1372 URL: https://bro-tracker.atlassian.net/browse/BIT-1372 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Robin Sommer Assignee: Robin Sommer Fix For: 2.4 Remove netflow and DFA cache (plus dead code). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 12:14:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 10 Apr 2015 14:14:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20255#comment-20255 ] Vlad Grigorescu commented on BIT-1370: -------------------------------------- Aashish - can you send me those PCAPs whenever you get a chance? I believe that traffic is actually SSDP and not SIP, but maybe I can tighten up the DPD sig a bit. > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 12:33:00 2015 From: jira at bro-tracker.atlassian.net (Aaron Eppert (JIRA)) Date: Fri, 10 Apr 2015 14:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: Aaron Eppert created BIT-1373: --------------------------------- Summary: Manager crashes with "internal error: bad reference count [0]" Key: BIT-1373 URL: https://bro-tracker.atlassian.net/browse/BIT-1373 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Aaron Eppert {noformat} [Thread debugging using libthread_db enabled] Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. Program terminated with signal 6, Aborted. #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7fa555794700 (LWP 10855)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fa556195700 (LWP 10854)): #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fa557597700 (LWP 10850)): #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 ==== No reporter.log ==== stderr.log internal error: bad reference count [0] /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" ==== stdout.log Known::SERVICES_LOG Files::LOG Syslog::LOG Known::CERTS_LOG Known::HOSTS_LOG PacketFilter::LOG X509::LOG Traceroute::LOG Notice::LOG Cluster::LOG ==== .cmdline -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto ==== .env_vars PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site CLUSTER_NODE=manager ==== .status TERMINATED [internal_error] {noformat} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From johanna at icir.org Fri Apr 10 12:57:31 2015 From: johanna at icir.org (Johanna Amann) Date: Fri, 10 Apr 2015 12:57:31 -0700 Subject: [Bro-Dev] Bro nightly packages for .dev and .rpm based distributions In-Reply-To: <20150212205351.GA35928@Beezling.local> References: <20150212205351.GA35928@Beezling.local> Message-ID: <20150410195731.GB92080@wifi86.sys.ICSI.Berkeley.EDU> Hello, the bro package on the Opensuse Build Service just moved to its final location in network:bro. So - the obs interface for is now available at https://build.opensuse.org/project/show/network:bro and builds for bro-nightly will be available at http://software.opensuse.org/download.html?project=network%3Abro&package=bro-nightly (currently it still is a 404; should hopefully be available within the next few hours). The binaries at the old location will no longer be updated. Johanna On Thu, Feb 12, 2015 at 12:53:51PM -0800, Johanna Amann wrote: > Hello, > > we are considering to provide packages for a number of different > .deb and .rpm based distributions starting with Bro 2.4, using the > OpenSuse build service. > > As a first step, I have created a repository that contains nightly Bro > builds for CentOs, Debian, Fedora, Suse Linux, Scientific Linux, > Univention as well as Ubuntu. > > At the moment, Bro is installed into /opt/bro and broctl needs root > permissions to run. Users in the Bro group (which is automatically created > on installation) should be able to modify configuration files like > local.bro, or the broctl configuration, and read the log files that Bro > writes. > > The package is called bro-nightly which is a metapackage which pulls in > the sub-packages > bro-core-nightly, containing only bro without broctl or libbroccoli > broctl-nightly, containing broctl > libbroccoli-nightly, containing libbroccoli > and libbroccoli-devel-nightly, containing the header files for libbroccoli > > The obs interface showing the status and sources is available at > https://build.opensuse.org/package/show/home:0xxon:bro/bro-nightly and > downloads are available at > http://software.opensuse.org/download.html?project=home%3A0xxon%3Abro&package=bro-nightly > (locations will change in the future). > If you add the repositories to your distribution, new nightly builds > should automatically be installed each time bro is updated. > > Additionally, Bro 2.3.2 packages are available at > https://build.opensuse.org/package/show/home:0xxon:bro/bro. > > At the moment, this is in an early stage and I would be happy to receive > any kind of feedback or problems that you encounter when using these > packages. Please note that the packages have not gone through a lot of > testing and that you should not use them in a production environment :) > > Johanna > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > > From jira at bro-tracker.atlassian.net Fri Apr 10 14:33:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 10 Apr 2015 16:33:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1368: ------------------------------ Assignee: Seth Hall (was: Jon Siwek) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 14:37:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 10 Apr 2015 16:37:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20256#comment-20256 ] Jon Siwek commented on BIT-1368: -------------------------------- Seth, topic/jsiwek/bit-1368 has the changes to the mime type detection script API that you can merge in to your branch for finalization when you're ready. For the naming, I went with: {code} ## Metadata that's been inferred about a particular file. type inferred_file_metadata: record { ## The strongest matching mime type if one was discovered. mime_type: string &optional; ## All matching mime types if any were discovered. mime_types: mime_matches &optional; }; event file_metadata_inferred(f: fa_file, meta: inferred_file_metadata); {code} > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 14:44:01 2015 From: jira at bro-tracker.atlassian.net (klehigh (JIRA)) Date: Fri, 10 Apr 2015 16:44:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20257#comment-20257 ] klehigh commented on BIT-1306: ------------------------------ Tested the patch on FreeBSD-10.1-p9 with bro 2.3-680 and Myricom SNF v3 drivers and it resolves this issue. > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 17:07:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 19:07:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1372) Clean up ---help In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1372: ------------------------------ Status: In Progress (was: Reopened) > Clean up ---help > ---------------- > > Key: BIT-1372 > URL: https://bro-tracker.atlassian.net/browse/BIT-1372 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.4 > > > Remove netflow and DFA cache (plus dead code). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 17:07:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 19:07:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1372) Clean up ---help In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1372: ------------------------------ Status: Reopened (was: Closed) Resolution: (was: Fixed) > Clean up ---help > ---------------- > > Key: BIT-1372 > URL: https://bro-tracker.atlassian.net/browse/BIT-1372 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.4 > > > Remove netflow and DFA cache (plus dead code). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 17:07:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 10 Apr 2015 19:07:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1372) Clean up ---help In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1372: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Clean up ---help > ---------------- > > Key: BIT-1372 > URL: https://bro-tracker.atlassian.net/browse/BIT-1372 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.4 > > > Remove netflow and DFA cache (plus dead code). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 22:20:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 11 Apr 2015 00:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20258#comment-20258 ] Robin Sommer commented on BIT-1356: ----------------------------------- Can somebody see if 0620bc97 helps? > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 22:21:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 11 Apr 2015 00:21:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20259#comment-20259 ] Robin Sommer commented on BIT-1306: ----------------------------------- Can somebody see if 0620bc97 helps? > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 22:23:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 11 Apr 2015 00:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1372) Clean up ---help In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1372: ------------------------------ Resolution: Fixed Status: Closed (was: In Progress) > Clean up ---help > ---------------- > > Key: BIT-1372 > URL: https://bro-tracker.atlassian.net/browse/BIT-1372 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.4 > > > Remove netflow and DFA cache (plus dead code). -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 10 22:59:00 2015 From: jira at bro-tracker.atlassian.net (klehigh (JIRA)) Date: Sat, 11 Apr 2015 00:59:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20260#comment-20260 ] klehigh commented on BIT-1306: ------------------------------ This patch works. I'm able to stop without any hanging processes. > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Sat Apr 11 00:00:49 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 11 Apr 2015 00:00:49 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504110700.t3B70nkn006301@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- ------------------------------------------------------------------------ BIT-1367 [1] Bro Johanna Amann Johanna Amann 2015-04-06 2.4 Normal Type clashing problem when records with default values are used in sets. Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [2] bro jshlbrd [3] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [4] [1] BIT-1367 https://bro-tracker.atlassian.net/browse/BIT-1367 [2] Pull Request #29 https://github.com/bro/bro/pull/29 [3] jshlbrd https://github.com/jshlbrd [4] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Sat Apr 11 07:46:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 11 Apr 2015 09:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1306: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sat Apr 11 07:47:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 11 Apr 2015 09:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20261#comment-20261 ] Robin Sommer commented on BIT-1306: ----------------------------------- Thanks, Keith! Closing ticket. > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sat Apr 11 11:16:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Sat, 11 Apr 2015 13:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1367) Type clashing problem when records with default values are used in sets. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1367: ------------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Type clashing problem when records with default values are used in sets. > ------------------------------------------------------------------------ > > Key: BIT-1367 > URL: https://bro-tracker.atlassian.net/browse/BIT-1367 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Johanna Amann > Labels: logging > Fix For: 2.4 > > > topic/johanna/sft-port is a branch that contains a slight modification to the sftp log-rotator, adding the possibility to select the server port with a default value of 20. > After adding this small change, the Bro type system is no longer able to figure out that it can coerce the record in cases that previously worked. The default evocation of the sftp log-rotator using: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set([$user="testuser",$host="testhost",$path="testpath"]); > {code} > or similar leads to > {code} > type clash in assignment (Log::sftp_destinations[Log::WRITER_ASCII, testconn] = set([$user=testuser, $host=testhost, $path=testpath])) > {code} > Directly specifying the type of the record works, but would break all other scripts that are using the sftp log rotator currently. > Working example: > {code} > Log::add_filter(Conn::LOG, [$name="test", $path="testconn", $writer=Log::WRITER_ASCII, > $interv=1hr, $postprocessor=Log::sftp_postprocessor]); > Log::sftp_destinations[Log::WRITER_ASCII,"testconn"] = set(Log::SFTPDestination($user="testuser",$host="testhost",$path="testpath")); > {code} > Once this is fixed, topic/johanna/sft-port can be merged. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Sun Apr 12 00:00:25 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 12 Apr 2015 00:00:25 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504120700.t3C70Pgo011175@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [1] bro jshlbrd [2] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [3] [1] Pull Request #29 https://github.com/bro/bro/pull/29 [2] jshlbrd https://github.com/jshlbrd [3] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Sun Apr 12 07:39:01 2015 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Sun, 12 Apr 2015 09:39:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1306) bro process would get stuck/freeze with myricom drivers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aashish Sharma updated BIT-1306: -------------------------------- Yes, So sorry, I couldn't get to it soon enough. Yes, Patch fixes the problem. Aashish -- Aashish Sharma (asharma at lbl.gov) Cyber Security, Lawrence Berkeley National Laboratory http://go.lbl.gov/pgp-aashish Office: (510)-495-2680 Cell: (510)-612-7971 > bro process would get stuck/freeze with myricom drivers > ------------------------------------------------------- > > Key: BIT-1306 > URL: https://bro-tracker.atlassian.net/browse/BIT-1306 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: OS: FreeBSD 9.3-RELEASE-p5 OS > bro version 2.3-328 > git log -1 --format="%H" > 379593c7fded0f9791ae71a52dd78a4c9d5a2c1f > Reporter: Aashish Sharma > Assignee: Robin Sommer > Labels: bro-git, myricom > Fix For: 2.4 > > > When I stop bro (in cluster mode), one of the bro worker process (random) would get stuck and wouldn't shutdown, stop or even be killed using kill -s 9. > System has to be ultimately rebooted to remove stuck bro process. > On running myri_start_stop I see: > # /usr/local/opt/snf/sbin/myri_start_stop stop > Removing myri_snf.ko > kldunload: can't unload file: Device busy > It appears that the myri_snf.ko driver cannot be unloaded because of the stuck bro process. That process still has an open descriptor on the Sniffer device/driver and bro process freezes > More details: > The bro process is stuck in RNE state > R Marks a runnable process. > N The process has reduced CPU scheduling priority (see setpriority(2)). > E The process is trying to exit. > Here is an example: > ### stuck process: > [bro at 01 ~]$ ps auxwww | fgrep 1616 > bro 1616 100.0 0.0 758040 60480 ?? RNE 2:57PM 53:50.04 /usr/local/bro-git/bin/bro -i myri0 -U .status -p broctl -p broctl-live -p local -p worker-1-1 mgr.bro broctl base/frameworks/cluster local-worker.bro broctl/auto > ####when checking for process in proc: > [bro at c ~]$ ls -l /proc/1616 > ls: /proc/1616: No such file or directory -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 12 18:13:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 12 Apr 2015 20:13:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20263#comment-20263 ] Daniel Thayer commented on BIT-1356: ------------------------------------ I've tested this, and 0620bc97 fixed the problem for me. > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 12 19:10:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 12 Apr 2015 21:10:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1374: ---------------------------------- Summary: topic/dnthayer/more-fixes-for-2.4 Key: BIT-1374 URL: https://bro-tracker.atlassian.net/browse/BIT-1374 Project: Bro Issue Tracker Issue Type: Problem Components: BroControl Reporter: Daniel Thayer Fix For: 2.4 -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 12 19:18:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 12 Apr 2015 21:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1374: ------------------------------- Description: The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" to hang waiting for the post-terminate script to finish, disable ssh password prompting, and improvements to error reporting, and removes some unused code. > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, disable ssh password > prompting, and improvements to error reporting, and removes some unused > code. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 12 19:20:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 12 Apr 2015 21:20:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1374: ------------------------------- Description: The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" to hang waiting for the post-terminate script to finish, a fix to disable ssh password prompting, improvements to error reporting, and removes some unused code. was: The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" to hang waiting for the post-terminate script to finish, disable ssh password prompting, and improvements to error reporting, and removes some unused code. > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, a fix to disable ssh > password prompting, improvements to error reporting, and removes > some unused code. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 12 19:20:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 12 Apr 2015 21:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1342) Occasional test failures In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20264#comment-20264 ] Daniel Thayer commented on BIT-1342: ------------------------------------ This issue is fixed in BIT-1374. > Occasional test failures > ------------------------ > > Key: BIT-1342 > URL: https://bro-tracker.atlassian.net/browse/BIT-1342 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Robin Sommer > Assignee: Daniel Thayer > Fix For: 2.4 > > > Two tests in current master fail for me occasionally (usually when I run the full broctl test-suite but not when I rerun just these failing tests). Diag output below. > {code} > command.start-stop-standalone ... failed > % 'btest-diff stop.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > stopping bro ... > Exception in thread Thread-1 (most likely raised during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/usr/lib64/python2.7/Queue.py", line 177, in get > File "/usr/lib64/python2.7/threading.py", line 354, in wait > : 'NoneType' object is not callable > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-stop-standalone/stop.out 2013-06-01 00:29:07.0000 > +++ stop.out 2015-03-17 22:50:01.857838625 +0000 > @@ -1 +1,9 @@ > stopping bro ... > +Exception in thread Thread-1 (most likely raised during interpreter shutdown): > +Traceback (most recent call last): > + File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/usr/lib64/python2.7/Queue.py", line 177, in get > + File "/usr/lib64/python2.7/threading.py", line 354, in wait > +: 'NoneType' object is not callable > ======================================= > [...] > command.start-cluster-slowstart ... failed > % 'btest-diff status2.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > Getting process status ... > Getting peer status ... > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > worker-1 worker localhost stopped > worker-2 worker localhost stopped > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-cluster-slowstart/status2.out 2015-03-04 20:16 > +++ status2.out 2015-03-17 22:50:26.578618684 +0000 > @@ -3,5 +3,5 @@ > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > -worker-1 worker localhost crashed > +worker-1 worker localhost stopped > worker-2 worker localhost stopped > ======================================= > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Mon Apr 13 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 13 Apr 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504130700.t3D70MLC010959@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [1] bro jshlbrd [2] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [3] [1] Pull Request #29 https://github.com/bro/bro/pull/29 [2] jshlbrd https://github.com/jshlbrd [3] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Mon Apr 13 08:32:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 13 Apr 2015 10:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1374: ---------------------------------- Assignee: Justin Azoff > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, a fix to disable ssh > password prompting, improvements to error reporting, and removes > some unused code. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Mon Apr 13 08:32:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 13 Apr 2015 10:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1374: ------------------------------- Status: Merge Request (was: Open) > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, a fix to disable ssh > password prompting, improvements to error reporting, and removes > some unused code. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Tue Apr 14 00:00:24 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 14 Apr 2015 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504140700.t3E70Oht017573@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- ------------------------------------- BIT-1374 [1] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [3] bro jshlbrd [4] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [5] [1] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [2] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [3] Pull Request #29 https://github.com/bro/bro/pull/29 [4] jshlbrd https://github.com/jshlbrd [5] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Tue Apr 14 12:32:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 14 Apr 2015 14:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20300#comment-20300 ] Robin Sommer commented on BIT-1333: ----------------------------------- I don't think this is quite right yet: we can't really generally escape backslashes on "print". If we did, we'd get for example this: {code} # cat a.bro event bro_init() { local a = "abc\0def"; local b = escape_string(a); print b; } # bro ./a.bro abc\\x00def {code} I.e, the escape_string() inserts "\x00", and then the print escapes that backslash. What if we did the backslash escape only on "special request", that is when calling escape_string() and simiarl functions? If one wants the reversible representation, one would then need to call such a function; whereas the semantics for a normal print would remain at "make sure it doesn't output non-printable characters", without being reversible. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 13:23:01 2015 From: jira at bro-tracker.atlassian.net (Paul Pearce (JIRA)) Date: Tue, 14 Apr 2015 15:23:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20301#comment-20301 ] Paul Pearce commented on BIT-1333: ---------------------------------- Robin, Thanks for looking at this. Robin, that behavior seems desirable to me as it provides for a completely reversible process. Can you elaborate a bit? The issues I'm encountering has to do with these characters being outputted via the logging framework. My understanding of the framework is such that your solution (special function) would mean that you could never get the recoverable representation via logging. Is that correct? If so, that seems problematic given that many programs consume these logs. Perhaps a middle ground solution would be a bro configuration operation that controls this behavior globally? > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 13:23:01 2015 From: jira at bro-tracker.atlassian.net (Paul Pearce (JIRA)) Date: Tue, 14 Apr 2015 15:23:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20301#comment-20301 ] Paul Pearce edited comment on BIT-1333 at 4/14/15 3:22 PM: ----------------------------------------------------------- Robin, Thanks for looking at this. Robin, that behavior seems desirable to me as it provides for a completely reversible process. Can you elaborate a bit? The issues I'm encountering has to do with these characters being outputted via the logging framework. My understanding of the framework is such that your solution (special function) would mean that you could never get the recoverable representation via logging. Is that correct? If so, that seems problematic given that many programs consume these logs. Perhaps a middle ground solution would be a bro configuration option that controls this behavior globally? was (Author: pearce): Robin, Thanks for looking at this. Robin, that behavior seems desirable to me as it provides for a completely reversible process. Can you elaborate a bit? The issues I'm encountering has to do with these characters being outputted via the logging framework. My understanding of the framework is such that your solution (special function) would mean that you could never get the recoverable representation via logging. Is that correct? If so, that seems problematic given that many programs consume these logs. Perhaps a middle ground solution would be a bro configuration operation that controls this behavior globally? > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 13:24:01 2015 From: jira at bro-tracker.atlassian.net (Paul Pearce (JIRA)) Date: Tue, 14 Apr 2015 15:24:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20301#comment-20301 ] Paul Pearce edited comment on BIT-1333 at 4/14/15 3:23 PM: ----------------------------------------------------------- Robin, Thanks for looking at this. The quoted behavior above seems desirable to me as it provides for a completely reversible process. Can you elaborate a bit? The issues I'm encountering has to do with these characters being outputted via the logging framework. My understanding of the framework is such that your solution (special function) would mean that you could never get the recoverable representation via logging. Is that correct? If so, that seems problematic given that many programs consume these logs. Perhaps a middle ground solution would be a bro configuration option that controls this behavior globally? was (Author: pearce): Robin, Thanks for looking at this. Robin, that behavior seems desirable to me as it provides for a completely reversible process. Can you elaborate a bit? The issues I'm encountering has to do with these characters being outputted via the logging framework. My understanding of the framework is such that your solution (special function) would mean that you could never get the recoverable representation via logging. Is that correct? If so, that seems problematic given that many programs consume these logs. Perhaps a middle ground solution would be a bro configuration option that controls this behavior globally? > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 16:49:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Tue, 14 Apr 2015 18:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1375) Please merge topic/johanna/ca-list In-Reply-To: References: Message-ID: Johanna Amann created BIT-1375: ---------------------------------- Summary: Please merge topic/johanna/ca-list Key: BIT-1375 URL: https://bro-tracker.atlassian.net/browse/BIT-1375 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro Affects Versions: git/master Reporter: Johanna Amann Fix For: 2.4 Please merge topic/johanna/ca-list. This updates the mozilla CA list to the current state and changes a few tests to continue working (CAs that were used in their traces were removed from the CA list). It also fixes the CA list that is used for the external test suite - those traces are kind of old now, more and more of the CAs in them are no longer valid and it does not really make sense to update them on each change... -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 16:50:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Tue, 14 Apr 2015 18:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1375) Please merge topic/johanna/ca-list In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1375: ------------------------------- Status: Merge Request (was: Open) > Please merge topic/johanna/ca-list > ---------------------------------- > > Key: BIT-1375 > URL: https://bro-tracker.atlassian.net/browse/BIT-1375 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > > Please merge topic/johanna/ca-list. This updates the mozilla CA list to the current state and changes a few tests to continue working (CAs that were used in their traces were removed from the CA list). It also fixes the CA list that is used for the external test suite - those traces are kind of old now, more and more of the CAs in them are no longer valid and it does not really make sense to update them on each change... -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Tue Apr 14 22:27:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 15 Apr 2015 00:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20302#comment-20302 ] Robin Sommer commented on BIT-1333: ----------------------------------- I can see doing this generally for logging. So would it work if we did the backslash escaping for logging, but stayed with my suggestion above for print and other script-land stuff? > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Wed Apr 15 00:00:29 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 15 Apr 2015 00:00:29 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504150700.t3F70TXx011772@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- ------------------------------------- BIT-1375 [1] Bro Johanna Amann - 2015-04-14 2.4 Normal Please merge topic/johanna/ca-list BIT-1374 [2] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [3] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1375 https://bro-tracker.atlassian.net/browse/BIT-1375 [2] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [3] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Wed Apr 15 12:46:00 2015 From: jira at bro-tracker.atlassian.net (Paul Pearce (JIRA)) Date: Wed, 15 Apr 2015 14:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20303#comment-20303 ] Paul Pearce commented on BIT-1333: ---------------------------------- That sounds great. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 15:50:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 15 Apr 2015 17:50:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1325) multiple sqlite writers to same db file yields "database is locked" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1325: ------------------------------- Fix Version/s: (was: 2.4) 2.5 > multiple sqlite writers to same db file yields "database is locked" error > ------------------------------------------------------------------------- > > Key: BIT-1325 > URL: https://bro-tracker.atlassian.net/browse/BIT-1325 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Tony Cebzanov > Assignee: Johanna Amann > Priority: Low > Labels: logging, sqlite > Fix For: 2.5 > > Attachments: bro_sqlite_busy_wait.patch > > > I want to have multiple log streams logged to the same sqlite database, but when trying to log to sqlite using the following configuration: > {code} > local filter: Log::Filter = > [ > $name="sqlite_conn", > $path="analysis", > $config=table(["tablename"] = "conn"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(Conn::LOG, filter); > local http_filter: Log::Filter = > [ > $name="sqlite_http", > $path="analysis", > $config=table(["tablename"] = "http"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(HTTP::LOG, http_filter); > {code} > I get the following error: > {code} > error: analysis/Log::WRITER_SQLITE: Error executing table creation statement: database is locked > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 15:50:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 15 Apr 2015 17:50:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1325) multiple sqlite writers to same db file yields "database is locked" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1325: ------------------------------- Affects Version/s: (was: 2.3) git/master > multiple sqlite writers to same db file yields "database is locked" error > ------------------------------------------------------------------------- > > Key: BIT-1325 > URL: https://bro-tracker.atlassian.net/browse/BIT-1325 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Tony Cebzanov > Assignee: Johanna Amann > Labels: logging, sqlite > Fix For: 2.5 > > Attachments: bro_sqlite_busy_wait.patch > > > I want to have multiple log streams logged to the same sqlite database, but when trying to log to sqlite using the following configuration: > {code} > local filter: Log::Filter = > [ > $name="sqlite_conn", > $path="analysis", > $config=table(["tablename"] = "conn"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(Conn::LOG, filter); > local http_filter: Log::Filter = > [ > $name="sqlite_http", > $path="analysis", > $config=table(["tablename"] = "http"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(HTTP::LOG, http_filter); > {code} > I get the following error: > {code} > error: analysis/Log::WRITER_SQLITE: Error executing table creation statement: database is locked > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 15:50:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 15 Apr 2015 17:50:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1325) multiple sqlite writers to same db file yields "database is locked" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1325: ------------------------------- Priority: Normal (was: Low) > multiple sqlite writers to same db file yields "database is locked" error > ------------------------------------------------------------------------- > > Key: BIT-1325 > URL: https://bro-tracker.atlassian.net/browse/BIT-1325 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Tony Cebzanov > Assignee: Johanna Amann > Labels: logging, sqlite > Fix For: 2.5 > > Attachments: bro_sqlite_busy_wait.patch > > > I want to have multiple log streams logged to the same sqlite database, but when trying to log to sqlite using the following configuration: > {code} > local filter: Log::Filter = > [ > $name="sqlite_conn", > $path="analysis", > $config=table(["tablename"] = "conn"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(Conn::LOG, filter); > local http_filter: Log::Filter = > [ > $name="sqlite_http", > $path="analysis", > $config=table(["tablename"] = "http"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(HTTP::LOG, http_filter); > {code} > I get the following error: > {code} > error: analysis/Log::WRITER_SQLITE: Error executing table creation statement: database is locked > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 15:50:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 15 Apr 2015 17:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1325) multiple sqlite writers to same db file yields "database is locked" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20304#comment-20304 ] Johanna Amann commented on BIT-1325: ------------------------------------ Sorry, this will not make it into 2.4. > multiple sqlite writers to same db file yields "database is locked" error > ------------------------------------------------------------------------- > > Key: BIT-1325 > URL: https://bro-tracker.atlassian.net/browse/BIT-1325 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Tony Cebzanov > Assignee: Johanna Amann > Priority: Low > Labels: logging, sqlite > Fix For: 2.5 > > Attachments: bro_sqlite_busy_wait.patch > > > I want to have multiple log streams logged to the same sqlite database, but when trying to log to sqlite using the following configuration: > {code} > local filter: Log::Filter = > [ > $name="sqlite_conn", > $path="analysis", > $config=table(["tablename"] = "conn"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(Conn::LOG, filter); > local http_filter: Log::Filter = > [ > $name="sqlite_http", > $path="analysis", > $config=table(["tablename"] = "http"), > $writer=Log::WRITER_SQLITE > ]; > Log::add_filter(HTTP::LOG, http_filter); > {code} > I get the following error: > {code} > error: analysis/Log::WRITER_SQLITE: Error executing table creation statement: database is locked > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 16:28:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 15 Apr 2015 18:28:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1375) Please merge topic/johanna/ca-list In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1375: --------------------------------- Assignee: Robin Sommer > Please merge topic/johanna/ca-list > ---------------------------------- > > Key: BIT-1375 > URL: https://bro-tracker.atlassian.net/browse/BIT-1375 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Robin Sommer > Fix For: 2.4 > > > Please merge topic/johanna/ca-list. This updates the mozilla CA list to the current state and changes a few tests to continue working (CAs that were used in their traces were removed from the CA list). It also fixes the CA list that is used for the external test suite - those traces are kind of old now, more and more of the CAs in them are no longer valid and it does not really make sense to update them on each change... -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Wed Apr 15 17:01:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 15 Apr 2015 19:01:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20305#comment-20305 ] Robin Sommer commented on BIT-1333: ----------------------------------- Try topic/robin/ascii-escape-normalization and see if that works for you. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Thu Apr 16 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 16 Apr 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504160700.t3G70NED009407@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- ------------------------------------- BIT-1375 [1] Bro Johanna Amann Robin Sommer 2015-04-15 2.4 Normal Please merge topic/johanna/ca-list BIT-1374 [2] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [3] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [4] bro jshlbrd [5] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [6] [1] BIT-1375 https://bro-tracker.atlassian.net/browse/BIT-1375 [2] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [3] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [4] Pull Request #29 https://github.com/bro/bro/pull/29 [5] jshlbrd https://github.com/jshlbrd [6] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Thu Apr 16 08:18:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 10:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1375) Please merge topic/johanna/ca-list In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1375: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Please merge topic/johanna/ca-list > ---------------------------------- > > Key: BIT-1375 > URL: https://bro-tracker.atlassian.net/browse/BIT-1375 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Robin Sommer > Fix For: 2.4 > > > Please merge topic/johanna/ca-list. This updates the mozilla CA list to the current state and changes a few tests to continue working (CAs that were used in their traces were removed from the CA list). It also fixes the CA list that is used for the external test suite - those traces are kind of old now, more and more of the CAs in them are no longer valid and it does not really make sense to update them on each change... -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 08:43:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 16 Apr 2015 10:43:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: Jon Siwek created BIT-1376: ------------------------------ Summary: method to reproduce "internal error: unknown msg type 115 in Poll()" Key: BIT-1376 URL: https://bro-tracker.atlassian.net/browse/BIT-1376 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Jon Siwek Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. Patch: {code} diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h index b590453..39af9b1 100644 --- a/src/ChunkedIO.h +++ b/src/ChunkedIO.h @@ -223,10 +223,10 @@ private: // We report that we're filling up when there are more than this number // of pending chunks. - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; // Maximum number of chunks we store in memory before rejecting writes. - static const uint32 MAX_BUFFERED_CHUNKS = 500000; + static const uint32 MAX_BUFFERED_CHUNKS = 50; char* read_buffer; uint32 read_len; {code} Start a bro process like this: {code} $ cat test.bro @load frameworks/communication/listen redef Communication::nodes += { ["foo"] = [$host = 127.0.0.1, $sync=T] }; global counters: table[string] of count &synchronized &default=0; event do_some (n:count) { ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters["thecounter"]; ++counters[peer_description]; if(counters["thecounter"] % 10000 == 0 ) { Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); } if(n != 0) { schedule 1msec { do_some(n-1) }; } else { Reporter::warning(fmt("The counter is %d", counters["thecounter"])); } } event bro_init() { schedule 1sec { do_some(1000000) }; schedule 2sec { do_some(1000000) }; schedule 3sec { do_some(1000000) }; } $ bro -b ./test.bro {code} Then start another like this: {code} $ cat test.bro @load base/frameworks/communication redef Communication::nodes += { ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, $retry=5sec] }; global counters: table[string] of count &synchronized &default=0; event check () { print counters["thecounter"]; schedule 5sec { check() }; } event bro_init() { schedule 5sec { check() }; } $ bro -b ./test.bro processing suspended processing continued 55069 58963 62831 66636 internal error: unknown msg type 115 in Poll() Abort trap: 6 {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:50:04 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:50:04 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1333: ------------------------------ Status: Merge Request (was: Open) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:50:03 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:50:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1333: --------------------------------- Assignee: Seth Hall (was: Robin Sommer) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:50:04 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:50:04 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20306#comment-20306 ] Robin Sommer commented on BIT-1333: ----------------------------------- Assigning this back to Seth for review and merging. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:52:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20307#comment-20307 ] Robin Sommer commented on BIT-1333: ----------------------------------- Oh, still need to update external tests actually, just a second. :) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:52:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:52:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1333: --------------------------------- Assignee: Robin Sommer (was: Seth Hall) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 13:52:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 15:52:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1333: ------------------------------ Status: Open (was: Merge Request) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 14:30:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 16 Apr 2015 16:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20308#comment-20308 ] Daniel Thayer commented on BIT-1353: ------------------------------------ Branch topic/dnthayer/ticket1353 in the broctl repo contains the fix for this issue. > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 14:30:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 16 Apr 2015 16:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1353: ------------------------------- Status: Merge Request (was: Open) > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 14:31:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 16 Apr 2015 16:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1342) Occasional test failures In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1342: ------------------------------- Resolution: Fixed Status: Closed (was: Open) > Occasional test failures > ------------------------ > > Key: BIT-1342 > URL: https://bro-tracker.atlassian.net/browse/BIT-1342 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Robin Sommer > Assignee: Daniel Thayer > Fix For: 2.4 > > > Two tests in current master fail for me occasionally (usually when I run the full broctl test-suite but not when I rerun just these failing tests). Diag output below. > {code} > command.start-stop-standalone ... failed > % 'btest-diff stop.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > stopping bro ... > Exception in thread Thread-1 (most likely raised during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", line > File "/usr/lib64/python2.7/Queue.py", line 177, in get > File "/usr/lib64/python2.7/threading.py", line 354, in wait > : 'NoneType' object is not callable > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-stop-standalone/stop.out 2013-06-01 00:29:07.0000 > +++ stop.out 2015-03-17 22:50:01.857838625 +0000 > @@ -1 +1,9 @@ > stopping bro ... > +Exception in thread Thread-1 (most likely raised during interpreter shutdown): > +Traceback (most recent call last): > + File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/home/robin/bro/master/aux/broctl/testing/../build/testing/test.21123/lib/broctl/BroControl/ssh_runner.py", l > + File "/usr/lib64/python2.7/Queue.py", line 177, in get > + File "/usr/lib64/python2.7/threading.py", line 354, in wait > +: 'NoneType' object is not callable > ======================================= > [...] > command.start-cluster-slowstart ... failed > % 'btest-diff status2.out' failed unexpectedly (exit code 1) > % cat .diag > == File =============================== > Getting process status ... > Getting peer status ... > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > worker-1 worker localhost stopped > worker-2 worker localhost stopped > == Diff =============================== > --- /home/robin/bro/master/aux/broctl/testing/Baseline/command.start-cluster-slowstart/status2.out 2015-03-04 20:16 > +++ status2.out 2015-03-17 22:50:26.578618684 +0000 > @@ -3,5 +3,5 @@ > Name Type Host Status Pid Peers Started > manager manager localhost stopped > proxy-1 proxy localhost stopped > -worker-1 worker localhost crashed > +worker-1 worker localhost stopped > worker-2 worker localhost stopped > ======================================= > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 14:59:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 16 Apr 2015 16:59:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1353: ------------------------------- Status: Open (was: Merge Request) > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 15:36:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 16 Apr 2015 17:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20309#comment-20309 ] Jon Siwek commented on BIT-1376: -------------------------------- Maybe consider the patch in topic/jsiwek/bit-1376 Basically what I think happened goes like: child->parent sends MSG_LOG "selects=X canwrites=Y" - first chunk saying here comes MSG_LOG gets accepted - second chunk says "selects=X canwrites=Y" gets rejected because the hard cap is reached the queues drain a bit and then you get a similar message sent... child->parent sends MSG_LOG "selects=X canwrites=Y" - first chunk saying here comes MSG_LOG gets accepted - second chunk says "selects=X canwrites=Y" gets accepted because we're under the hard cap again now on the parent side, it reads a chunk that says MSG_LOG, then reads another chunk that says MSG_LOG and misinterprets that as the data that goes with the first message log (which ends up being something like \x13\x00\x00\x00...), but then it reads a chunk with contents "selects=X canwrites=Y" and interprets that as the chunk containing message type information. The message type is found in the first byte and that is 's', whose value is 115 and not valid. Rejecting arbitrary chunks on the child-parent path seems like asking for things to get in a weird state, so the patch just now relies only on shutting down child-child (remote peers) connections to try and deal with overload. In the test case, the memory situation looked stable, but the peers end up thrashing -- so again the user would probably need to intervene and put a higher-level solution in place (e.g. more proxies, etc), except now the signal for overload problems isn't a crash, but just messages in communication.log (maybe something better like a notice can be done). > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 15:38:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 16 Apr 2015 17:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1376: --------------------------- Status: Merge Request (was: Open) > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 15:41:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 16 Apr 2015 17:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20310#comment-20310 ] Jon Siwek commented on BIT-1376: -------------------------------- This hasn't been tested in a real environment, so feel free to reject until that's done, just wanted to set to merge request for visibility. > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 16:16:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 16 Apr 2015 18:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1353: ------------------------------- Status: Merge Request (was: Open) > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 17:09:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 19:09:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1376: --------------------------------- Assignee: Robin Sommer > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Assignee: Robin Sommer > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 17:09:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 19:09:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20311#comment-20311 ] Robin Sommer commented on BIT-1376: ----------------------------------- Very cool that you figured this out, I'll take out a look. Your description matches exactly what I was expecting: that the 2nd block gets parsed as if it were a 1st; but I never found the trigger for when the state can get messed up like this. Didn't realize it's the shutdown that's causing it. > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 21:58:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 23:58:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1333: ------------------------------ Status: Merge Request (was: Open) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 21:58:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 23:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20312#comment-20312 ] Robin Sommer commented on BIT-1333: ----------------------------------- Now in topic/robin/ascii-escape-normalization in bro, bro-testing and bro-testing-private. > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 21:59:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 16 Apr 2015 23:59:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1333: --------------------------------- Assignee: Seth Hall (was: Robin Sommer) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Seth Hall > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 22:03:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 00:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20313#comment-20313 ] Robin Sommer commented on BIT-1331: ----------------------------------- Should be fixed in 9260638948502c795d34f60c095ca33f74bb106a > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Assignee: Robin Sommer > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Thu Apr 16 22:03:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 00:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1331) Bro manager crashes when logs rotate In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1331: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Bro manager crashes when logs rotate > ------------------------------------ > > Key: BIT-1331 > URL: https://bro-tracker.atlassian.net/browse/BIT-1331 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Environment: Ubuntu 12.04.5 LTS, PF_RING lb_method > Reporter: Josh Liburdi > Assignee: Robin Sommer > Fix For: 2.4 > > > The Bro manager crashes when the logs rotate. Workers run fine through this process. > stderr.log output: > internal error: finish missing > /usr/local/bro/share/broctl/scripts/run-bro: line 100: 157357 Aborted (core dumped) nohup "$mybro" "$@" > send-mail: SENDMAIL-NOTFOUND not found -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Fri Apr 17 00:00:24 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 17 Apr 2015 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504170700.t3H70O40029012@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------- ---------- ------------- ---------- -------------------------------------------------------------------- BIT-1376 [1] Bro Jon Siwek Robin Sommer 2015-04-16 - Normal method to reproduce "internal error: unknown msg type 115 in Poll()" BIT-1374 [2] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [3] BIT-1353 [4] BroControl Johanna Amann Daniel Thayer 2015-04-16 2.4 Normal BroCtl status/top take excessive amount of time BIT-1333 [5] Bro Paul Pearce Seth Hall 2015-04-16 2.4 Normal Bro's ASCII logging facilities do not escape escape characters Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [6] bro jshlbrd [7] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [8] [1] BIT-1376 https://bro-tracker.atlassian.net/browse/BIT-1376 [2] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [3] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [4] BIT-1353 https://bro-tracker.atlassian.net/browse/BIT-1353 [5] BIT-1333 https://bro-tracker.atlassian.net/browse/BIT-1333 [6] Pull Request #29 https://github.com/bro/bro/pull/29 [7] jshlbrd https://github.com/jshlbrd [8] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From robin at icir.org Fri Apr 17 08:55:24 2015 From: robin at icir.org (Robin Sommer) Date: Fri, 17 Apr 2015 08:55:24 -0700 Subject: [Bro-Dev] [Bro] Logging VLAN IDs In-Reply-To: References: Message-ID: <20150417155524.GO55440@icir.org> (Cc'ing bro-dev, I suggest we continue the thread there). This sounds generally reasonable, however I think we could take the opportunity here to generalize this a bit more for generally including link-layer information into connection handling. One thing that I didn't quite get form your description is if the objective is really just to get the VLAN ID into conn.log, or whether you also want to use it for defining what constitutes a connection in the first place. The latter would aim at the situations where the same IP addresses can appear on different VLANs for independent connections. Right now, Bro can't keep them apart, but if we made the VLAN part of the connection index into the session table, it would treat them separately. Same applies to other link-level features that could sometimes be useful to be a part of a connection's ID (like MAC addresses). With that in mind, some thoughts on generalizing this (note, I not sureif you're working from 2.3 or git master. The PktSrc API has changed a bit recently, I'll take git as my starting point). - One challenge is passing the the VLAN ID through to the various packet-related methods. You're suggesting additional parameters, which would work. However, these methods are already taking a bunch of parameters, and if in the future we wanted to pass through further link-layer info, we'd have to add even more. A more flexible alternative would be switching to simply passing a Packet structure around that encapsulates all the information, including what's already there (e.g., timestmap, pcap_hdr, payload, etc.). The new PktSrc API already has such a class: PktSrc::Packet; from a quick look I think we could elevate that to be something passed around more generally, and then extend it accordingly. - For the connections, I would store the VLAN inside the ConnID struct, and then modify BuildConnIDHashKey() to take it into account. That way, the session table will make it part of its index. Same for the script-land conn_id record; that will then make script-level tables work that index by conn_id. - Extending the ConnID like this could actually be made a run-time option: I believe it shouldn't be too difficult to let users chose the fields defining a ConnID, so that they can decide if, say, they want to VLAN to be in there or not. We could predefine a set of potential features to choose from, along with some script-land API to pick the set to use, with the current 4-tuple being the default. (This could be a 2nd step for later; if the first two points above were in place, this extension should become mainly a question of finding the right configuration interface.) I haven't thought this thruogh too carefully, so it's conceivable that I'm missing something. But I think it would be really helpful for many folks to get more flexibility into the definition of what consitutes a connection, with VLANs being a good initial target to support. Robin On Tue, Apr 14, 2015 at 16:59 +0000, you wrote: > Dear Bro developers, > > I've been tasked with trying to modify the Bro source code so that > conn.log includes the VLAN IDs (including 802.1ah) that have been observed > in packets associated with that connection. I've scoped out a solution, > but I want to run it by you first before I start to go for it, in case I'm > missing something really big. > > PktSrc::Process() does processing of VLAN and 802.1ah, but it just skips > over them by advancing the data pointer. I will, in addition, store those > VLAN IDs in a new member of the modified PktSrc class. This gets passed on > through net_packet_dispatch() and NetSessions::DispatchPacket(). At this > point NetSessions::NextPacket() gets called, but since the PktSrc doesn't > get passed to it, I'd need another way to pass it the VLAN ID. I am > considering two options: > > 1. duplicate NextPacket() adding a new parameter to pass it the VLAN IDs, > and call that instead, or > 2. store the VLAN IDs in the NetSessions class, in DispatchPacket() so > it?s available to NextPacket() and DoNextPacket() <- Is there a reason > this wouldn?t work, e.g. issues with multi-threading/multi-processing? > > Is there one option that seems better to you? > > NetSessions::DoNextPacket() is called next and I would also need a > modification to pass it VLAN IDs, using one of the options above. In this > method we finally get access to the appropriate Connection instance, so I > would store the VLAN IDs in that instance in DoNextPacket(). > > I'd need to modify the Connection class in Conn.h to include a new member > for tracking VLAN IDs. I'd modify Connection::BuildConnVal() and > scripts/base/init-bare.bro's connection record to make the VLAN IDs > available to scripts. Lastly, I'd write a script to redef the conn Info > structure and handle one or more connection events (perhaps > connection_state_remove) to copy the VLAN IDs from the connection record > to the Info record. > > Is there anything I'm missing? Is there a better way to approach this? > -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From jira at bro-tracker.atlassian.net Fri Apr 17 10:05:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 12:05:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1377) Please merge topic/johanna/conn-threshold In-Reply-To: References: Message-ID: Johanna Amann created BIT-1377: ---------------------------------- Summary: Please merge topic/johanna/conn-threshold Key: BIT-1377 URL: https://bro-tracker.atlassian.net/browse/BIT-1377 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro Affects Versions: git/master Reporter: Johanna Amann Fix For: 2.4 Please merge topic/johanna/conn-threshold. This branch adds a high-level and a low-level API for connection thresholding (packets or bytes). The functions that are exposed to users are: {code} ConnThreshold::set_bytes_threshold(c, [bytes], [direction]); ConnThreshold::set_packets_threshold(c, [packets], [direction]); {code} as well as ConnThreshold::delete_bytes_threshold and ConnThreshold::delete_packets_threshold to delete thresholds. Several thresholds can be added for a single connection; all of them will be raised. The following two events trigger with the thresholds: {code} event ConnThreshold::bytes_threshold_crossed(c: connection, threshold: count, is_orig: bool) event ConnThreshold::packets_threshold_crossed(c: connection, threshold: count, is_orig: bool) {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 10:06:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 12:06:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1377) Please merge topic/johanna/conn-threshold In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1377: ------------------------------- Status: Merge Request (was: Open) > Please merge topic/johanna/conn-threshold > ----------------------------------------- > > Key: BIT-1377 > URL: https://bro-tracker.atlassian.net/browse/BIT-1377 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > > Please merge topic/johanna/conn-threshold. This branch adds a high-level and a low-level API for connection thresholding (packets or bytes). > The functions that are exposed to users are: > {code} > ConnThreshold::set_bytes_threshold(c, [bytes], [direction]); > ConnThreshold::set_packets_threshold(c, [packets], [direction]); > {code} > as well as ConnThreshold::delete_bytes_threshold and ConnThreshold::delete_packets_threshold to delete thresholds. Several thresholds can be added for a single connection; all of them will be raised. > The following two events trigger with the thresholds: > {code} > event ConnThreshold::bytes_threshold_crossed(c: connection, threshold: count, is_orig: bool) > event ConnThreshold::packets_threshold_crossed(c: connection, threshold: count, is_orig: bool) > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 11:27:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 13:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20314#comment-20314 ] Johanna Amann commented on BIT-985: ----------------------------------- Branch topic/johanna/bit0985 adds seeking functionality to raw reader. one can now add an option "offset" to the config map. Positive offsets are interpreted to be from the beginning of the file, negative from the end of the file (-1 is end of file). Only works for raw reader in streaming or manual mode. Does not work with executables. Scott, could you perhaps add a separate bug for your ring-buffer changes if you want to get them into mainline Bro? (They will not make it into 2.4 though). > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Johanna Amann > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 11:27:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 13:27:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-985: ------------------------------ Status: Merge Request (was: Open) > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Johanna Amann > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 11:27:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 13:27:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-985: --------------------------------- Assignee: (was: Johanna Amann) > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 12:38:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 14:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20315#comment-20315 ] Robin Sommer commented on BIT-1376: ----------------------------------- I find it hard to predict if removing the hardcap will cause other trouble, but I'm fine giving this patch a try; in the end, if somebody runs into overload, it's a problem either way. We can use the beta period to see if anything major shows up; if so, it would be easy to back out the patch again. > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Assignee: Robin Sommer > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 12:41:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 14:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1377) Please merge topic/johanna/conn-threshold In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1377: --------------------------------- Assignee: Robin Sommer > Please merge topic/johanna/conn-threshold > ----------------------------------------- > > Key: BIT-1377 > URL: https://bro-tracker.atlassian.net/browse/BIT-1377 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Robin Sommer > Fix For: 2.4 > > > Please merge topic/johanna/conn-threshold. This branch adds a high-level and a low-level API for connection thresholding (packets or bytes). > The functions that are exposed to users are: > {code} > ConnThreshold::set_bytes_threshold(c, [bytes], [direction]); > ConnThreshold::set_packets_threshold(c, [packets], [direction]); > {code} > as well as ConnThreshold::delete_bytes_threshold and ConnThreshold::delete_packets_threshold to delete thresholds. Several thresholds can be added for a single connection; all of them will be raised. > The following two events trigger with the thresholds: > {code} > event ConnThreshold::bytes_threshold_crossed(c: connection, threshold: count, is_orig: bool) > event ConnThreshold::packets_threshold_crossed(c: connection, threshold: count, is_orig: bool) > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 13:04:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 15:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-985: -------------------------------- Assignee: Robin Sommer > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 13:15:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 15:15:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20316#comment-20316 ] Robin Sommer commented on BIT-985: ---------------------------------- Merging. Mind documenting that option somewhere though? > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 13:34:00 2015 From: jira at bro-tracker.atlassian.net (james.lay (JIRA)) Date: Fri, 17 Apr 2015 15:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1378) Include extract_files in archives In-Reply-To: References: Message-ID: james.lay created BIT-1378: ------------------------------ Summary: Include extract_files in archives Key: BIT-1378 URL: https://bro-tracker.atlassian.net/browse/BIT-1378 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: 2.3 Environment: Linux Reporter: james.lay Request to see about getting extract_files included in the 'normal' archiving process -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 13:41:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 17 Apr 2015 15:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20317#comment-20317 ] Johanna Amann commented on BIT-985: ----------------------------------- I actually thought about that and was just not quite sure where - the other flags do not really seem to be documented either :/ > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 13:49:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 15:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20318#comment-20318 ] Robin Sommer commented on BIT-985: ---------------------------------- Extend this one? https://www.bro.org/sphinx-git/frameworks/input.html#different-readers And/or: add it to the header section of scripts/../raw.bro? (And then document the other ones as well :) > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 14:15:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 16:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-985: ----------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > Attachments: input.diff, PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 14:15:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 16:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1377) Please merge topic/johanna/conn-threshold In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1377: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Please merge topic/johanna/conn-threshold > ----------------------------------------- > > Key: BIT-1377 > URL: https://bro-tracker.atlassian.net/browse/BIT-1377 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Robin Sommer > Fix For: 2.4 > > > Please merge topic/johanna/conn-threshold. This branch adds a high-level and a low-level API for connection thresholding (packets or bytes). > The functions that are exposed to users are: > {code} > ConnThreshold::set_bytes_threshold(c, [bytes], [direction]); > ConnThreshold::set_packets_threshold(c, [packets], [direction]); > {code} > as well as ConnThreshold::delete_bytes_threshold and ConnThreshold::delete_packets_threshold to delete thresholds. Several thresholds can be added for a single connection; all of them will be raised. > The following two events trigger with the thresholds: > {code} > event ConnThreshold::bytes_threshold_crossed(c: connection, threshold: count, is_orig: bool) > event ConnThreshold::packets_threshold_crossed(c: connection, threshold: count, is_orig: bool) > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 14:15:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 17 Apr 2015 16:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1376: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Assignee: Robin Sommer > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 17:29:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 17 Apr 2015 19:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1365: --------------------------------- Status: Merge Request (was: Open) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 17:29:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 17 Apr 2015 19:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20319#comment-20319 ] Vlad Grigorescu commented on BIT-1365: -------------------------------------- This is fixed in topic/vladg/ssh. When fixing this, I found a bug with the old implementation. The documentation states that: "If a client was a local host logging into an external host, this would be OUTBOUND. INBOUND would be set for the opposite situation." However, only Site::is_local_addr(c$id$orig_h) was being checked, so local-local would always be OUTBOUND and remote-remote (which could happen if, for example, you haven't set local_nets) would always be INBOUND. I was torn between restoring the old implementation, or doing what the documentation states. I decided to implement what's documented. The field will be unset for local-local or remote-remote conns. > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 18:55:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 17 Apr 2015 20:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20320#comment-20320 ] Vlad Grigorescu commented on BIT-1369: -------------------------------------- I merged master, updated the tests (no changes to bro-testing and bro-testing-private), and updated NEWS. > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Fri Apr 17 18:55:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 17 Apr 2015 20:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1369: --------------------------------- Status: Merge Request (was: Open) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Sat Apr 18 00:01:04 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 18 Apr 2015 00:01:04 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504180701.t3I714aV027599@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- --------------- ---------- ------------- ---------- -------------------------------------------------------------- BIT-1374 [1] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [2] BIT-1369 [3] Bro Vlad Grigorescu Vlad Grigorescu 2015-04-17 2.4 Normal Kerberos Analyzer BIT-1365 [4] Bro Jon Siwek Vlad Grigorescu 2015-04-17 2.4 Normal direction field of SSH::Info no longer populated BIT-1353 [5] BroControl Johanna Amann Daniel Thayer 2015-04-16 2.4 Normal BroCtl status/top take excessive amount of time BIT-1333 [6] Bro Paul Pearce Seth Hall 2015-04-16 2.4 Normal Bro's ASCII logging facilities do not escape escape characters Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [7] bro jshlbrd [8] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [9] [1] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [2] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [3] BIT-1369 https://bro-tracker.atlassian.net/browse/BIT-1369 [4] BIT-1365 https://bro-tracker.atlassian.net/browse/BIT-1365 [5] BIT-1353 https://bro-tracker.atlassian.net/browse/BIT-1353 [6] BIT-1333 https://bro-tracker.atlassian.net/browse/BIT-1333 [7] Pull Request #29 https://github.com/bro/bro/pull/29 [8] jshlbrd https://github.com/jshlbrd [9] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Sat Apr 18 06:40:01 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Sat, 18 Apr 2015 08:40:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1376) method to reproduce "internal error: unknown msg type 115 in Poll()" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20321#comment-20321 ] Justin Azoff commented on BIT-1376: ----------------------------------- I deployed the patch to our dev cluster a few days ago. No issues so far, though we were only seeing a proxy crash about once a week. The highest I've seen 'pending' in the updated log message was one spike to 46095 that drained to 0 within the same second, otherwise it is always 0. I think Seth may be on to something with looking into what the proxies are doing. I'd be ok with running a patch on our dev cluster that dumps all proxy communication to a log file. It appears to be very low volume aside from these occasional spikes. > method to reproduce "internal error: unknown msg type 115 in Poll()" > -------------------------------------------------------------------- > > Key: BIT-1376 > URL: https://bro-tracker.atlassian.net/browse/BIT-1376 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Assignee: Robin Sommer > > Justin found a modification to Bro and a script that triggers the "unknown msg type 115" bug. This method seems to reproduce the problem fairly reliably and between two bro processes started via command-line. > Patch: > {code} > diff --git a/src/ChunkedIO.h b/src/ChunkedIO.h > index b590453..39af9b1 100644 > --- a/src/ChunkedIO.h > +++ b/src/ChunkedIO.h > @@ -223,10 +223,10 @@ private: > > // We report that we're filling up when there are more than this number > // of pending chunks. > - static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 400000; > + static const uint32 MAX_BUFFERED_CHUNKS_SOFT = 40; > > // Maximum number of chunks we store in memory before rejecting writes. > - static const uint32 MAX_BUFFERED_CHUNKS = 500000; > + static const uint32 MAX_BUFFERED_CHUNKS = 50; > > char* read_buffer; > uint32 read_len; > {code} > Start a bro process like this: > {code} > $ cat test.bro > @load frameworks/communication/listen > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $sync=T] > }; > global counters: table[string] of count &synchronized &default=0; > event do_some (n:count) > { > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters["thecounter"]; > ++counters[peer_description]; > if(counters["thecounter"] % 10000 == 0 ) { > Reporter::warning(fmt("I am %s and The counter is %d. my counter is %d", peer_description, counters["thecounter"], counters[peer_description])); > } > if(n != 0) { > schedule 1msec { do_some(n-1) }; > } else { > Reporter::warning(fmt("The counter is %d", counters["thecounter"])); > } > } > event bro_init() > { > schedule 1sec { do_some(1000000) }; > schedule 2sec { do_some(1000000) }; > schedule 3sec { do_some(1000000) }; > } > $ bro -b ./test.bro > {code} > Then start another like this: > {code} > $ cat test.bro > @load base/frameworks/communication > redef Communication::nodes += { > ["foo"] = [$host = 127.0.0.1, $events = /.*/, $connect=T, $sync=T, > $retry=5sec] > }; > global counters: table[string] of count &synchronized &default=0; > event check () > { > print counters["thecounter"]; > schedule 5sec { check() }; > } > event bro_init() > { > schedule 5sec { check() }; > } > $ bro -b ./test.bro > processing suspended > processing continued > 55069 > 58963 > 62831 > 66636 > internal error: unknown msg type 115 in Poll() > Abort trap: 6 > {code} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sat Apr 18 21:14:02 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Sat, 18 Apr 2015 23:14:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20322#comment-20322 ] Justin Azoff commented on BIT-1365: ----------------------------------- Any reason why local-local couldn't be set to INTERNAL? and I suppose remote-remote set to EXTERNAL? I think that if unset ends up meaning INTERNAL for most configurations, we should explicitly say that, and say EXTERNAL if that was not the case. This would simplify things like searching and reporting. (Now that I think of this, this applies to just about all the connection related log files, surprised that utils/site.bro doesn't have a helper for this) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Sun Apr 19 00:00:29 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 19 Apr 2015 00:00:29 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504190700.t3J70T9e012227@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- --------------- ---------- ------------- ---------- -------------------------------------------------------------- BIT-1374 [1] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [2] BIT-1369 [3] Bro Vlad Grigorescu Vlad Grigorescu 2015-04-17 2.4 Normal Kerberos Analyzer BIT-1365 [4] Bro Jon Siwek Vlad Grigorescu 2015-04-18 2.4 Normal direction field of SSH::Info no longer populated BIT-1353 [5] BroControl Johanna Amann Daniel Thayer 2015-04-16 2.4 Normal BroCtl status/top take excessive amount of time BIT-1333 [6] Bro Paul Pearce Seth Hall 2015-04-16 2.4 Normal Bro's ASCII logging facilities do not escape escape characters Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ----------- ---------- ---------------------------------------------- #29 [7] bro jshlbrd [8] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [9] [1] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [2] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [3] BIT-1369 https://bro-tracker.atlassian.net/browse/BIT-1369 [4] BIT-1365 https://bro-tracker.atlassian.net/browse/BIT-1365 [5] BIT-1353 https://bro-tracker.atlassian.net/browse/BIT-1353 [6] BIT-1333 https://bro-tracker.atlassian.net/browse/BIT-1333 [7] Pull Request #29 https://github.com/bro/bro/pull/29 [8] jshlbrd https://github.com/jshlbrd [9] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Sun Apr 19 19:12:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Sun, 19 Apr 2015 21:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer In-Reply-To: References: Message-ID: Vlad Grigorescu created BIT-1379: ------------------------------------ Summary: PE File Analyzer Key: BIT-1379 URL: https://bro-tracker.atlassian.net/browse/BIT-1379 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Reporter: Vlad Grigorescu topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable file analyzer. The branch has been pushed to bro, bro-testing and bro-testing-private. As one might expect, there's a ton of information in the PE file format. The code will only interpret the headers, but that information will still provide a lot of actionable data. I believe that this is ready and would be a good addition to 2.4, but as it wasn't previously discussed, we can punt on it if we have to. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 19 19:12:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Sun, 19 Apr 2015 21:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1379: --------------------------------- Status: Merge Request (was: Open) > PE File Analyzer > ---------------- > > Key: BIT-1379 > URL: https://bro-tracker.atlassian.net/browse/BIT-1379 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Vlad Grigorescu > > topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable file analyzer. The branch has been pushed to bro, bro-testing and bro-testing-private. > As one might expect, there's a ton of information in the PE file format. The code will only interpret the headers, but that information will still provide a lot of actionable data. > I believe that this is ready and would be a good addition to 2.4, but as it wasn't previously discussed, we can punt on it if we have to. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 19 20:20:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Sun, 19 Apr 2015 22:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1370: --------------------------------- Status: Merge Request (was: Open) > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From jira at bro-tracker.atlassian.net Sun Apr 19 20:20:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Sun, 19 Apr 2015 22:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20323#comment-20323 ] Vlad Grigorescu commented on BIT-1370: -------------------------------------- I merged master, updated the tests (no changes to bro-testing and bro-testing-private), and updated NEWS. > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.4-OD-16-006#64014) From noreply at bro.org Mon Apr 20 00:00:31 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 20 Apr 2015 00:00:31 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504200700.t3K70Vwm022160@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- --------------- ---------- ------------- ---------- -------------------------------------------------------------- BIT-1379 [1] Bro Vlad Grigorescu - 2015-04-19 - Normal PE File Analyzer BIT-1374 [2] BroControl Daniel Thayer Justin Azoff 2015-04-13 2.4 Normal topic/dnthayer/more-fixes-for-2.4 [3] BIT-1370 [4] Bro Vlad Grigorescu Vlad Grigorescu 2015-04-19 2.4 Normal SIP Analyzer BIT-1369 [5] Bro Vlad Grigorescu Vlad Grigorescu 2015-04-17 2.4 Normal Kerberos Analyzer BIT-1365 [6] Bro Jon Siwek Vlad Grigorescu 2015-04-18 2.4 Normal direction field of SSH::Info no longer populated BIT-1353 [7] BroControl Johanna Amann Daniel Thayer 2015-04-16 2.4 Normal BroCtl status/top take excessive amount of time BIT-1333 [8] Bro Paul Pearce Seth Hall 2015-04-16 2.4 Normal Bro's ASCII logging facilities do not escape escape characters Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- ----------------------------------------------- #29 [9] bro jshlbrd [10] 2015-03-25 Add PROXY-AUTHORIZATION header to http.log [11] [1] BIT-1379 https://bro-tracker.atlassian.net/browse/BIT-1379 [2] BIT-1374 https://bro-tracker.atlassian.net/browse/BIT-1374 [3] more-fixes-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/more-fixes-for-2.4 [4] BIT-1370 https://bro-tracker.atlassian.net/browse/BIT-1370 [5] BIT-1369 https://bro-tracker.atlassian.net/browse/BIT-1369 [6] BIT-1365 https://bro-tracker.atlassian.net/browse/BIT-1365 [7] BIT-1353 https://bro-tracker.atlassian.net/browse/BIT-1353 [8] BIT-1333 https://bro-tracker.atlassian.net/browse/BIT-1333 [9] Pull Request #29 https://github.com/bro/bro/pull/29 [10] jshlbrd https://github.com/jshlbrd [11] Merge Pull Request #29 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro.git patch-2 From jira at bro-tracker.atlassian.net Mon Apr 20 08:15:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 10:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1370: --------------------------------- Assignee: (was: Vlad Grigorescu) > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 08:16:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 10:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1369: --------------------------------- Assignee: (was: Vlad Grigorescu) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 08:16:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 10:16:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1365: --------------------------------- Assignee: (was: Vlad Grigorescu) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 08:17:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 10:17:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1353: --------------------------------- Assignee: (was: Daniel Thayer) > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 08:24:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Mon, 20 Apr 2015 10:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1380) Files::add_analyzer documentation has too many fields In-Reply-To: References: Message-ID: Vlad Grigorescu created BIT-1380: ------------------------------------ Summary: Files::add_analyzer documentation has too many fields Key: BIT-1380 URL: https://bro-tracker.atlassian.net/browse/BIT-1380 Project: Bro Issue Tracker Issue Type: Problem Components: Documentation Reporter: Vlad Grigorescu Priority: Low I was looking at: [Files::add_analyzer|https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html#id-Files::add_analyzer], and noticed that too many fields seem to be listed for the default of AnalyzerArgs. The same thing happens for remove_analyzer. Is this something we could get cleaned up? -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 09:11:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 11:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20400#comment-20400 ] Seth Hall commented on BIT-1368: -------------------------------- Thanks Jon! I reverted back to the naming I was using (although I'm already taking some flak for it). My topic/seth/more-file-type-ident-fixes is ready for merging. There are branches of the same name in bro-testing and bro-testing-private as well. Merging this branch also merges the contents of Jon's topic/jsiwek/bit-1368 branch. > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 09:11:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 11:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1368: --------------------------- Status: Merge Request (was: Open) Assignee: (was: Seth Hall) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 09:12:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Mon, 20 Apr 2015 11:12:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20401#comment-20401 ] Vlad Grigorescu commented on BIT-1365: -------------------------------------- > Any reason why local-local couldn't be set to INTERNAL? and I suppose remote-remote set to EXTERNAL? Hmm. I don't think those are quite right. The biggest issue is that they're technically not directions, just endpoint attributes. It does simplify some searches, but it still leaves something to be desired there (e.g. if I want to see all SSH connections to systems on my network, I need to search for INBOUND || INTERNAL). I agree that there's a better solution out there, but I think this exposes a larger issue. There are some open questions about local_nets - should RFC-1918 space be in there, or just public space? Should connections from neighbor nets be denoted in the logs as well? What if IP space alone isn't enough to denote my local networks, what if I need, say, VLAN IDs? What might make sense is just to split this into two fields that denote where orig_h and resp_h are, in the order PRIVATE, LOCAL, NEIGHBOR, EXTERNAL (i.e. if is_private_addr return PRIVATE; else if is_local_addr return LOCAL...). We can leave this ticket open to discuss better options down the line - this is marked as a TODO in the script. > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 09:53:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 20 Apr 2015 11:53:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1380) Files::add_analyzer documentation has too many fields In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1380: ------------------------------ Assignee: Jon Siwek > Files::add_analyzer documentation has too many fields > ----------------------------------------------------- > > Key: BIT-1380 > URL: https://bro-tracker.atlassian.net/browse/BIT-1380 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Reporter: Vlad Grigorescu > Assignee: Jon Siwek > Priority: Low > > I was looking at: [Files::add_analyzer|https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html#id-Files::add_analyzer], and noticed that too many fields seem to be listed for the default of AnalyzerArgs. The same thing happens for remove_analyzer. > Is this something we could get cleaned up? -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 10:09:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 12:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1370: ------------------------------ Assignee: Seth Hall > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Seth Hall > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 10:10:00 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Mon, 20 Apr 2015 12:10:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20402#comment-20402 ] Justin Azoff commented on BIT-1365: ----------------------------------- Ah, that makes sense. That reminded me, conn.log recently got a local_resp boolean, so now that has local_orig + local_resp. > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 10:11:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 12:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20403#comment-20403 ] Seth Hall commented on BIT-1365: -------------------------------- I'll be merging Vlad's fixes from topic/vladg/ssh. > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 10:11:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 12:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1365: ------------------------------ Assignee: Seth Hall > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Seth Hall > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 10:50:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 20 Apr 2015 12:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1380) Files::add_analyzer documentation has too many fields In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1380: --------------------------- Resolution: Fixed Fix Version/s: 2.4 Status: Closed (was: Open) > Files::add_analyzer documentation has too many fields > ----------------------------------------------------- > > Key: BIT-1380 > URL: https://bro-tracker.atlassian.net/browse/BIT-1380 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Reporter: Vlad Grigorescu > Assignee: Jon Siwek > Priority: Low > Fix For: 2.4 > > > I was looking at: [Files::add_analyzer|https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html#id-Files::add_analyzer], and noticed that too many fields seem to be listed for the default of AnalyzerArgs. The same thing happens for remove_analyzer. > Is this something we could get cleaned up? -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 12:50:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 14:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1368: --------------------------------- Assignee: Robin Sommer > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Robin Sommer > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 13:33:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 15:33:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20404#comment-20404 ] Robin Sommer commented on BIT-1368: ----------------------------------- I'm seeing significant performance improvements after this merge, like 4-7% on the external tests (in a debug mode compile) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Robin Sommer > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 13:37:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 15:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1369: --------------------------------- Assignee: Robin Sommer > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 13:52:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 20 Apr 2015 15:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20405#comment-20405 ] Seth Hall commented on BIT-1368: -------------------------------- Yay! That's to be expected. This was from fixing the signatures that were interacting poorly with each other. We don't have un-ending DFA state construction anymore. :) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Robin Sommer > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 15:23:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 20 Apr 2015 17:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1381: ------------------------------- Status: Merge Request (was: Open) Assignee: (was: Justin Azoff) > topic/dnthayer/cleanup-for-2.4 > ------------------------------ > > Key: BIT-1381 > URL: https://bro-tracker.atlassian.net/browse/BIT-1381 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.4 > > > The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains > some code cleanup, and fixes for several minor issues (interactive > command mode tab-completion fix, suppress warnings when running > install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 15:23:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 20 Apr 2015 17:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1381: ---------------------------------- Assignee: Justin Azoff > topic/dnthayer/cleanup-for-2.4 > ------------------------------ > > Key: BIT-1381 > URL: https://bro-tracker.atlassian.net/browse/BIT-1381 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains > some code cleanup, and fixes for several minor issues (interactive > command mode tab-completion fix, suppress warnings when running > install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 15:23:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 20 Apr 2015 17:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1381: ---------------------------------- Summary: topic/dnthayer/cleanup-for-2.4 Key: BIT-1381 URL: https://bro-tracker.atlassian.net/browse/BIT-1381 Project: Bro Issue Tracker Issue Type: Problem Components: BroControl Reporter: Daniel Thayer Fix For: 2.4 The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains some code cleanup, and fixes for several minor issues (interactive command mode tab-completion fix, suppress warnings when running install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 15:24:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 20 Apr 2015 17:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1381: ---------------------------------- Assignee: Justin Azoff > topic/dnthayer/cleanup-for-2.4 > ------------------------------ > > Key: BIT-1381 > URL: https://bro-tracker.atlassian.net/browse/BIT-1381 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains > some code cleanup, and fixes for several minor issues (interactive > command mode tab-completion fix, suppress warnings when running > install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 16:09:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 18:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1379: --------------------------------- Assignee: Robin Sommer > PE File Analyzer > ---------------- > > Key: BIT-1379 > URL: https://bro-tracker.atlassian.net/browse/BIT-1379 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable file analyzer. The branch has been pushed to bro, bro-testing and bro-testing-private. > As one might expect, there's a ton of information in the PE file format. The code will only interpret the headers, but that information will still provide a lot of actionable data. > I believe that this is ready and would be a good addition to 2.4, but as it wasn't previously discussed, we can punt on it if we have to. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 16:23:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 18:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20406#comment-20406 ] Robin Sommer commented on BIT-1369: ----------------------------------- Mind if I rename the kb.log to kerberos.log? The kinit.trace seems to trigger only 4 of the 10 krb_* events. How did you test the other ones? Any chance to get a trace for those as well? > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 16:25:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 18:25:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20406#comment-20406 ] Robin Sommer edited comment on BIT-1369 at 4/20/15 6:24 PM: ------------------------------------------------------------ Mind if I rename the krb.log to kerberos.log? The kinit.trace seems to trigger only 4 of the 10 krb_* events. How did you test the other ones? Any chance to get a trace for those as well? was (Author: robin): Mind if I rename the kb.log to kerberos.log? The kinit.trace seems to trigger only 4 of the 10 krb_* events. How did you test the other ones? Any chance to get a trace for those as well? > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 17:20:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Mon, 20 Apr 2015 19:20:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20407#comment-20407 ] Vlad Grigorescu commented on BIT-1369: -------------------------------------- > Mind if I rename the krb.log to kerberos.log? I could go either way on this. KRB is a pretty common abbreviation for the protocol (to use it, you need a krb5.conf, for example), but I can also see why the full name would be clearer. Down the road, I'd like to add support for auth mechanisms that use Kerberos as the underlying provider, and I envision splitting the log into ticket issuance (krb_ticket) and ticket usage (krb_auth), or something like that. It might make sense to go with kerberos.log for now, and tackle that down the line. Whatever you think is best. > The kinit.trace seems to trigger only 4 of the 10 krb_* events. How did you test the other ones? Any chance to get a trace for those as well? I used some private PCAPs. I'll see if I can figure out how to generate those events in my test environment, and will add another test. > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:26:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1353: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:26:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1353) BroCtl status/top take excessive amount of time In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20408#comment-20408 ] Robin Sommer commented on BIT-1353: ----------------------------------- This has been merged already. > BroCtl status/top take excessive amount of time > ----------------------------------------------- > > Key: BIT-1353 > URL: https://bro-tracker.atlassian.net/browse/BIT-1353 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Fix For: 2.4 > > > After running a large bro cluster for a few days on a FreeBSD system (FreeBSD 10.1, 28 physical nodes, 81 worker processes), broctl actions that interact with all nodes seem to take excessive amounts of time (>2 minutes for a broctl status). This was not the case right after starting up the cluster. > If there is any way I can help with more information, please let me know what to do. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:36:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1369: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:36:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1368) File type identification fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1368: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > File type identification fixes > ------------------------------ > > Key: BIT-1368 > URL: https://bro-tracker.atlassian.net/browse/BIT-1368 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Robin Sommer > Fix For: 2.4 > > > I have some changes nearly queued up for 2.4 release in the repository (topic/seth/more-file-type-ident-fixes) in the but a bit more work needs to be done. > There may be one more breaking change to the files api coming in this branch too. Jon and I discussed some options and I think that creating a new event named file_sniff in place of the file_mime_type event makes sense. We can put the mime type and more "sniff" originated data in a record on that event so that we can extend it cleanly (and without breaking APIs) in the future. I think it will look something like this: > ``` > type fa_sniff: record { > ## Depth sniffed. > depth: count &default=0; > ## Sniffed mime type if one was discovered. > mime_type: string &optional; > }; > event file_sniff(f: fa_file, sniff: fa_sniff) > { > if ( sniff?$mime_type ) > { > print sniff$mime_type; > } > } > ``` > One other thing this branch will address is a performance degradation from certain file signatures interacting with each other poorly. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:49:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:49:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1369: ------------------------------ Status: Reopened (was: Closed) Resolution: (was: Merged) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:49:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1379: ------------------------------ Status: Closed (was: Merge Request) > PE File Analyzer > ---------------- > > Key: BIT-1379 > URL: https://bro-tracker.atlassian.net/browse/BIT-1379 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable file analyzer. The branch has been pushed to bro, bro-testing and bro-testing-private. > As one might expect, there's a ton of information in the PE file format. The code will only interpret the headers, but that information will still provide a lot of actionable data. > I believe that this is ready and would be a good addition to 2.4, but as it wasn't previously discussed, we can punt on it if we have to. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:50:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20409#comment-20409 ] Robin Sommer commented on BIT-1369: ----------------------------------- Oops, closed the wrong one. This one hasn't been merged yet (waiting for test) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:51:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20410#comment-20410 ] Robin Sommer commented on BIT-1374: ----------------------------------- This one has been merged already. Justin, please close tickets when merging. > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, a fix to disable ssh > password prompting, improvements to error reporting, and removes > some unused code. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:52:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1374) topic/dnthayer/more-fixes-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1374: ------------------------------ Status: Closed (was: Merge Request) > topic/dnthayer/more-fixes-for-2.4 > --------------------------------- > > Key: BIT-1374 > URL: https://bro-tracker.atlassian.net/browse/BIT-1374 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/more-fixes-for-2.4 in the broctl repo contains > fixes that address BIT-1342, a fix for an issue that could cause "broctl stop" > to hang waiting for the post-terminate script to finish, a fix to disable ssh > password prompting, improvements to error reporting, and removes > some unused code. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:52:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:52:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1369: ------------------------------ Status: Merge Request (was: Reopened) Assignee: (was: Robin Sommer) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 20 19:52:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 20 Apr 2015 21:52:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1369: --------------------------------- Assignee: Robin Sommer > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Tue Apr 21 00:00:24 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 21 Apr 2015 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504210700.t3L70OaX011235@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- -------------------------------------------------------------- BIT-1381 [1] BroControl Daniel Thayer Justin Azoff 2015-04-20 2.4 Normal topic/dnthayer/cleanup-for-2.4 [2] BIT-1370 [3] Bro Vlad Grigorescu Seth Hall 2015-04-20 2.4 Normal SIP Analyzer BIT-1369 [4] Bro Vlad Grigorescu Robin Sommer 2015-04-20 2.4 Normal Kerberos Analyzer BIT-1365 [5] Bro Jon Siwek Seth Hall 2015-04-20 2.4 Normal direction field of SSH::Info no longer populated BIT-1333 [6] Bro Paul Pearce Seth Hall 2015-04-16 2.4 Normal Bro's ASCII logging facilities do not escape escape characters [1] BIT-1381 https://bro-tracker.atlassian.net/browse/BIT-1381 [2] cleanup-for-2.4 https://github.com/bro/brocontrol/tree/topic/dnthayer/cleanup-for-2.4 [3] BIT-1370 https://bro-tracker.atlassian.net/browse/BIT-1370 [4] BIT-1369 https://bro-tracker.atlassian.net/browse/BIT-1369 [5] BIT-1365 https://bro-tracker.atlassian.net/browse/BIT-1365 [6] BIT-1333 https://bro-tracker.atlassian.net/browse/BIT-1333 From jira at bro-tracker.atlassian.net Tue Apr 21 08:09:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 10:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20411#comment-20411 ] Jon Siwek commented on BIT-1373: -------------------------------- topic/jsiwek/bit-1373 has a fix > Manager crashes with "internal error: bad reference count [0]" > -------------------------------------------------------------- > > Key: BIT-1373 > URL: https://bro-tracker.atlassian.net/browse/BIT-1373 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Aaron Eppert > Labels: cluster > Fix For: 2.4 > > > {noformat} > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. > Program terminated with signal 6, Aborted. > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fa555794700 (LWP 10855)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 > #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 > #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fa556195700 (LWP 10854)): > #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 > #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 > #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 > #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 > #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fa557597700 (LWP 10850)): > #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 > #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 > #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 > #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 > #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 > #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 > #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 > #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 > #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 > #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 > #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 > #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 > #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 > #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 > #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 > #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 > #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 > #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 > #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 > #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 > #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 > #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 > #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 > #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 > #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 > #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 > #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 > #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 > #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 > #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal error: bad reference count [0] > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" > ==== stdout.log > Known::SERVICES_LOG > Files::LOG > Syslog::LOG > Known::CERTS_LOG > Known::HOSTS_LOG > PacketFilter::LOG > X509::LOG > Traceroute::LOG > Notice::LOG > Cluster::LOG > ==== .cmdline > -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE=manager > ==== .status > TERMINATED [internal_error] > {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 08:09:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 10:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1373: --------------------------- Fix Version/s: 2.4 > Manager crashes with "internal error: bad reference count [0]" > -------------------------------------------------------------- > > Key: BIT-1373 > URL: https://bro-tracker.atlassian.net/browse/BIT-1373 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Aaron Eppert > Labels: cluster > Fix For: 2.4 > > > {noformat} > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. > Program terminated with signal 6, Aborted. > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fa555794700 (LWP 10855)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 > #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 > #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fa556195700 (LWP 10854)): > #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 > #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 > #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 > #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 > #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fa557597700 (LWP 10850)): > #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 > #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 > #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 > #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 > #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 > #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 > #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 > #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 > #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 > #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 > #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 > #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 > #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 > #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 > #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 > #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 > #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 > #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 > #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 > #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 > #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 > #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 > #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 > #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 > #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 > #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 > #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 > #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 > #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 > #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal error: bad reference count [0] > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" > ==== stdout.log > Known::SERVICES_LOG > Files::LOG > Syslog::LOG > Known::CERTS_LOG > Known::HOSTS_LOG > PacketFilter::LOG > X509::LOG > Traceroute::LOG > Notice::LOG > Cluster::LOG > ==== .cmdline > -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE=manager > ==== .status > TERMINATED [internal_error] > {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 08:09:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 10:09:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1373: --------------------------- Status: Merge Request (was: Open) > Manager crashes with "internal error: bad reference count [0]" > -------------------------------------------------------------- > > Key: BIT-1373 > URL: https://bro-tracker.atlassian.net/browse/BIT-1373 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Aaron Eppert > Labels: cluster > Fix For: 2.4 > > > {noformat} > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. > Program terminated with signal 6, Aborted. > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fa555794700 (LWP 10855)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 > #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 > #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fa556195700 (LWP 10854)): > #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 > #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 > #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 > #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 > #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fa557597700 (LWP 10850)): > #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 > #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 > #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 > #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 > #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 > #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 > #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 > #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 > #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 > #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 > #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 > #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 > #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 > #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 > #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 > #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 > #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 > #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 > #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 > #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 > #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 > #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 > #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 > #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 > #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 > #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 > #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 > #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 > #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 > #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal error: bad reference count [0] > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" > ==== stdout.log > Known::SERVICES_LOG > Files::LOG > Syslog::LOG > Known::CERTS_LOG > Known::HOSTS_LOG > PacketFilter::LOG > X509::LOG > Traceroute::LOG > Notice::LOG > Cluster::LOG > ==== .cmdline > -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE=manager > ==== .status > TERMINATED [internal_error] > {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 08:47:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 10:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1357) Complete TODOs in NEWS file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1357: ------------------------------ Resolution: Done Status: Closed (was: Open) Seems generally up to date now, so closing the ticket. But if you notice anything still missing, patches still welcome. > Complete TODOs in NEWS file > --------------------------- > > Key: BIT-1357 > URL: https://bro-tracker.atlassian.net/browse/BIT-1357 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Fix For: 2.4 > > > There's several TODO markers in NEWS to complete before releasing. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 08:47:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 10:47:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1356) Bro process sticks around after broctl stop In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1356: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > Bro process sticks around after broctl stop > ------------------------------------------- > > Key: BIT-1356 > URL: https://bro-tracker.atlassian.net/browse/BIT-1356 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.4 > > > It seems that after running a "broctl stop" not all bro processes are killed immediately. On our cluster, one of the processes keeps running; I seems like it eventually terminates after all log-compression is done. Is that on purpose or is that a bug? > Ps output (on the node running the manager, bro process in first line, including the running compression jobs for completeness): > {code} > $ ps -ax | grep bro > 23353 - IN 20:06.96 /xa/bro/master/bin/bro -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > 24979 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log http.2015-03-25-14-40-30.log http 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25047 - I 0:00.01 bash /xa/bro/master/share/broctl/scripts/archive-log conn.2015-03-25-14-40-30.log conn 15-03-25_14.40.30 15-03-25_16.29.29 1 ascii > 25841 - S 0:00.59 bash /xa/bro/master/share/broctl/scripts/post-terminate /xa/bro/master/spool/manager > 29204 0 D+ 0:00.00 grep bro > {code} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 10:10:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Tue, 21 Apr 2015 12:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20413#comment-20413 ] Vlad Grigorescu commented on BIT-1369: -------------------------------------- I tweaked the kinit btest to print output for one of the other events, and I added another btest that tests the TGS events. I couldn't find a good way to generate the other events in my test environment - I've often seen them in Microsoft AD environments, and not in the MIT or Heimdal implementations. Of the untested events, ```krb_ap_response``` and ```krb_priv``` only have the connection information, ```krb_cred`` and ```krb_safe``` are rarely seen. I'll keep thinking of a way to test those, but I don't think that should be a blocker. > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 11:18:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 13:18:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1343) Add Support for Including Common PAC Files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1343: --------------------------- Fix Version/s: 2.4 > Add Support for Including Common PAC Files > ------------------------------------------ > > Key: BIT-1343 > URL: https://bro-tracker.atlassian.net/browse/BIT-1343 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Reporter: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > With some new analyzers, we're duplicating code that we're shipping with Bro, due to a limitation in BinPAC - currently, BinPAC doesn't support %include-ing files from other directories. ASN.1 is a good example of this - SNMP and Kerberos both need a copy of the same ASN.1 parsing code. SMB also has some overlap with other analyzers. > I tried the obvious fix of adding parsing support for {{%include ../snmp/asn1.pac}}, but the include paths get mixed up and compilation fails. > I believe this should be a relatively simple fix. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 11:18:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 13:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1343) Add Support for Including Common PAC Files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20414#comment-20414 ] Jon Siwek commented on BIT-1343: -------------------------------- topic/jsiwek/bit-1343 in binpac and bro repos fixes this. (But the kerberos analyzer isn't merged in yet, so that can still have common code to factor out) > Add Support for Including Common PAC Files > ------------------------------------------ > > Key: BIT-1343 > URL: https://bro-tracker.atlassian.net/browse/BIT-1343 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Reporter: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > With some new analyzers, we're duplicating code that we're shipping with Bro, due to a limitation in BinPAC - currently, BinPAC doesn't support %include-ing files from other directories. ASN.1 is a good example of this - SNMP and Kerberos both need a copy of the same ASN.1 parsing code. SMB also has some overlap with other analyzers. > I tried the obvious fix of adding parsing support for {{%include ../snmp/asn1.pac}}, but the include paths get mixed up and compilation fails. > I believe this should be a relatively simple fix. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 11:18:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 21 Apr 2015 13:18:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1343) Add Support for Including Common PAC Files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1343: --------------------------- Status: Merge Request (was: Open) > Add Support for Including Common PAC Files > ------------------------------------------ > > Key: BIT-1343 > URL: https://bro-tracker.atlassian.net/browse/BIT-1343 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Reporter: Vlad Grigorescu > Priority: Low > Fix For: 2.4 > > > With some new analyzers, we're duplicating code that we're shipping with Bro, due to a limitation in BinPAC - currently, BinPAC doesn't support %include-ing files from other directories. ASN.1 is a good example of this - SNMP and Kerberos both need a copy of the same ASN.1 parsing code. SMB also has some overlap with other analyzers. > I tried the obvious fix of adding parsing support for {{%include ../snmp/asn1.pac}}, but the include paths get mixed up and compilation fails. > I believe this should be a relatively simple fix. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 12:02:00 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Tue, 21 Apr 2015 14:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1381?focusedWorklogId=10000&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-10000 ] Justin Azoff logged work on BIT-1381: ------------------------------------- Author: Justin Azoff Created on: 21/Apr/15 2:01 PM Start Date: 21/Apr/15 2:01 PM Worklog Time Spent: 45 minutes Work Description: Merged. And I think I didn't screw up this time! Issue Time Tracking ------------------- Worklog Id: (was: 10000) Time Spent: 45 minutes Remaining Estimate: 0 minutes > topic/dnthayer/cleanup-for-2.4 > ------------------------------ > > Key: BIT-1381 > URL: https://bro-tracker.atlassian.net/browse/BIT-1381 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > Time Spent: 45 minutes > Remaining Estimate: 0 minutes > > The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains > some code cleanup, and fixes for several minor issues (interactive > command mode tab-completion fix, suppress warnings when running > install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 12:02:00 2015 From: jira at bro-tracker.atlassian.net (Justin Azoff (JIRA)) Date: Tue, 21 Apr 2015 14:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1381) topic/dnthayer/cleanup-for-2.4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Azoff updated BIT-1381: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) Merged. And I think I didn't screw up this time! > topic/dnthayer/cleanup-for-2.4 > ------------------------------ > > Key: BIT-1381 > URL: https://bro-tracker.atlassian.net/browse/BIT-1381 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Assignee: Justin Azoff > Fix For: 2.4 > > > The branch topic/dnthayer/cleanup-for-2.4 in the broctl repo contains > some code cleanup, and fixes for several minor issues (interactive > command mode tab-completion fix, suppress warnings when running > install or deploy, and handle broctl output more consistently). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 12:39:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 14:39:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1369: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Kerberos Analyzer > ----------------- > > Key: BIT-1369 > URL: https://bro-tracker.atlassian.net/browse/BIT-1369 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/kerberos has a Kerberos analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 13:34:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 15:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1365: --------------------------------- Assignee: Robin Sommer (was: Seth Hall) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 13:41:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 15:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1373: --------------------------------- Assignee: Robin Sommer > Manager crashes with "internal error: bad reference count [0]" > -------------------------------------------------------------- > > Key: BIT-1373 > URL: https://bro-tracker.atlassian.net/browse/BIT-1373 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Aaron Eppert > Assignee: Robin Sommer > Labels: cluster > Fix For: 2.4 > > > {noformat} > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. > Program terminated with signal 6, Aborted. > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fa555794700 (LWP 10855)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 > #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 > #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fa556195700 (LWP 10854)): > #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 > #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 > #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 > #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 > #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fa557597700 (LWP 10850)): > #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 > #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 > #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 > #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 > #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 > #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 > #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 > #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 > #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 > #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 > #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 > #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 > #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 > #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 > #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 > #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 > #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 > #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 > #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 > #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 > #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 > #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 > #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 > #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 > #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 > #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 > #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 > #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 > #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 > #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal error: bad reference count [0] > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" > ==== stdout.log > Known::SERVICES_LOG > Files::LOG > Syslog::LOG > Known::CERTS_LOG > Known::HOSTS_LOG > PacketFilter::LOG > X509::LOG > Traceroute::LOG > Notice::LOG > Cluster::LOG > ==== .cmdline > -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE=manager > ==== .status > TERMINATED [internal_error] > {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 13:47:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 15:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1343) Add Support for Including Common PAC Files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1343: --------------------------------- Assignee: Robin Sommer > Add Support for Including Common PAC Files > ------------------------------------------ > > Key: BIT-1343 > URL: https://bro-tracker.atlassian.net/browse/BIT-1343 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > With some new analyzers, we're duplicating code that we're shipping with Bro, due to a limitation in BinPAC - currently, BinPAC doesn't support %include-ing files from other directories. ASN.1 is a good example of this - SNMP and Kerberos both need a copy of the same ASN.1 parsing code. SMB also has some overlap with other analyzers. > I tried the obvious fix of adding parsing support for {{%include ../snmp/asn1.pac}}, but the include paths get mixed up and compilation fails. > I believe this should be a relatively simple fix. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 14:18:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 16:18:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1370: --------------------------------- Assignee: Robin Sommer (was: Seth Hall) > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 15:32:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 17:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1333: --------------------------------- Assignee: Robin Sommer (was: Seth Hall) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 16:13:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 18:13:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1333) Bro's ASCII logging facilities do not escape escape characters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1333: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Bro's ASCII logging facilities do not escape escape characters > -------------------------------------------------------------- > > Key: BIT-1333 > URL: https://bro-tracker.atlassian.net/browse/BIT-1333 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Paul Pearce > Assignee: Robin Sommer > Fix For: 2.4 > > > * Bro escapes non-printable ASCII characters with either \x?? or ^ depending on the character (https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html). > * Bro does not however escape \ or ^. > * This behavior makes recovering the original string impossible as you can not differentiate between an escaped sequence and a string containing those characters. > Examples: > $ bro -e 'event bro_init() { print "foo \xc2\xae bar \\xc2\\xae baz"; }' > foo \xc2\xae bar \xc2\xae baz > $ bro -e 'event bro_init() { print "foo\x00bar\\0baz"; }' > foo\0bar\0baz > $ bro -e 'event bro_init() { print "foo \16 bar ^N baz"; }' > foo ^N bar ^N baz > Additionally, it would be ideal if there was a way to standardize escaping to a single syntax (\x?? for all, for example). This would allow post-processing of the bro logs in languages like Python or Ruby trivially using existing decode/encode functionality. I'm happy to file a separate feature request for this behavior, if that is preferred. > I brought this up on the mailing list (http://mailman.icsi.berkeley.edu/pipermail/bro/2015-February/008174.html). It was suggested (off list) that I file a ticket as well. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 16:13:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 18:13:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1370: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > SIP Analyzer > ------------ > > Key: BIT-1370 > URL: https://bro-tracker.atlassian.net/browse/BIT-1370 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Fix For: 2.4 > > > topic/vladg/sip has a SIP analyzer. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 16:13:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 18:13:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1343) Add Support for Including Common PAC Files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1343: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Add Support for Including Common PAC Files > ------------------------------------------ > > Key: BIT-1343 > URL: https://bro-tracker.atlassian.net/browse/BIT-1343 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > Priority: Low > Fix For: 2.4 > > > With some new analyzers, we're duplicating code that we're shipping with Bro, due to a limitation in BinPAC - currently, BinPAC doesn't support %include-ing files from other directories. ASN.1 is a good example of this - SNMP and Kerberos both need a copy of the same ASN.1 parsing code. SMB also has some overlap with other analyzers. > I tried the obvious fix of adding parsing support for {{%include ../snmp/asn1.pac}}, but the include paths get mixed up and compilation fails. > I believe this should be a relatively simple fix. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 16:13:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 18:13:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1365: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > direction field of SSH::Info no longer populated > ------------------------------------------------ > > Key: BIT-1365 > URL: https://bro-tracker.atlassian.net/browse/BIT-1365 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.4 > > > Here's the bug report: > {quote} > Reporter::ERROR field value missing > [SSH::c$ssh$direction] /usr/local/bro/share/bro/policy/protocols/ssh/geo-da > ta.bro, line 29 > Reporter::WARNING non-void function returns without a value: > SSH::get_location (empty) > Tracing this back, it looks like the SSH::c$ssh$direction is not being > populated. I checked the /base/protocols/ssh/main.bro file and it looks > like the function is missing. > Looking at https://www.bro.org/sphinx/_downloads/main32.bro and > https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro > it looks like the function that determined the direction was removed at > one point, which looks like it causes the > /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail > {quote} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 16:13:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 18:13:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1373) Manager crashes with "internal error: bad reference count [0]" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1373: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Manager crashes with "internal error: bad reference count [0]" > -------------------------------------------------------------- > > Key: BIT-1373 > URL: https://bro-tracker.atlassian.net/browse/BIT-1373 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Aaron Eppert > Assignee: Robin Sommer > Labels: cluster > Fix For: 2.4 > > > {noformat} > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -U .status -p broctl -p broctl-live -p local -p manager'. > Program terminated with signal 6, Aborted. > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > Thread 45 (Thread 0x7fa50b5fe700 (LWP 11048)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6009b20) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6009b20) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6009b20) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fa4c57fb700 (LWP 17263)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x61cb2b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x61cb2b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x61cb2b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fa5097fb700 (LWP 11052)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600d5a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600d5a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600d5a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fa4bffff700 (LWP 1407)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x630c8a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x630c8a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x630c8a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fa4ce1fc700 (LWP 11058)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60073c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60073c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60073c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fa4bf5fe700 (LWP 12650)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x1c299310) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x1c299310) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x1c299310) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fa5317fb700 (LWP 11029)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47704f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47704f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47704f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fa4cffff700 (LWP 11054)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6015a90) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6015a90) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6015a90) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fa522bfd700 (LWP 11026)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4988bb0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4988bb0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4988bb0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fa4cf5fe700 (LWP 11056)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6016e10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6016e10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6016e10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fa508dfa700 (LWP 11053)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6014710) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6014710) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6014710) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fa4cd7fb700 (LWP 11059)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6012fd0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6012fd0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6012fd0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fa520dfa700 (LWP 11038)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60087a0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60087a0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60087a0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fa4c7fff700 (LWP 12020)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6023d70) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6023d70) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6023d70) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fa5335fe700 (LWP 10870)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4780da0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4780da0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4780da0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fa4c75fe700 (LWP 12022)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x602c620) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x602c620) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x602c620) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fa5217fb700 (LWP 11037)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4986900) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4986900) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4986900) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fa4c61fc700 (LWP 12983)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x60f21c0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x60f21c0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x60f21c0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fa523fff700 (LWP 10864)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474fa30) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474fa30) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474fa30) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fa530dfa700 (LWP 11036)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4771060) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4771060) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4771060) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fa4bebfd700 (LWP 21017)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x32ecdef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x32ecdef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x32ecdef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fa5457fb700 (LWP 10861)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4742ef0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4742ef0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4742ef0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fa5321fc700 (LWP 11028)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x498a290) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x498a290) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x498a290) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fa4c4dfa700 (LWP 27867)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6185840) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6185840) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6185840) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fa5461fc700 (LWP 10860)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473eb10) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473eb10) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473eb10) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fa532bfd700 (LWP 11027)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4989720) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4989720) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4989720) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fa5221fc700 (LWP 11025)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x476e480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x476e480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x476e480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fa4c6bfd700 (LWP 12974)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6033800) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6033800) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6033800) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fa5475fe700 (LWP 10858)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4736650) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4736650) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4736650) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fa5235fe700 (LWP 10865)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4753e50) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4753e50) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4753e50) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fa533fff700 (LWP 10863)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x474b600) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x474b600) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x474b600) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fa555794700 (LWP 10855)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47085f0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47085f0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47085f0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fa546bfd700 (LWP 10859)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x473a750) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x473a750) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x473a750) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fa554d93700 (LWP 10856)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x470c8b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x470c8b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x470c8b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fa4ccdfa700 (LWP 12019)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6032480) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6032480) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6032480) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fa556b96700 (LWP 10853)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa56806c31c in boost::condition_variable::do_wait_until(boost::unique_lock&, timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #2 0x00007fa56806add6 in boost::this_thread::hiden::sleep_until(timespec const&) () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa568060c8c in boost::this_thread::sleep (abs_time=) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:249 > #4 0x00007fa5680665b6 in sleep (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/pthread/thread_data.hpp:255 > #5 plugin::PS_tcplog::TcpSession::clientThread (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:192 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fa556195700 (LWP 10854)): > #0 0x0000003345ce8ef3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007fa5680626bf in run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/epoll_reactor.ipp:392 > #2 do_run_one (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:368 > #3 boost::asio::detail::task_io_service::run (this=0x36ff4b0, ec=...) at /root/musher/lib/boost/install/include/boost/asio/detail/impl/task_io_service.ipp:153 > #4 0x00007fa56806318e in boost::asio::io_service::run (this=0x7fa567f1c5a8) at /root/musher/lib/boost/install/include/boost/asio/impl/io_service.ipp:59 > #5 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #6 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #7 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fa4cebfd700 (LWP 11057)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x6006040) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x6006040) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x6006040) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fa557597700 (LWP 10850)): > #0 0x000000334600b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fa5680646fb in boost::condition_variable::wait (this=0x7fa550000938, m=...) at /root/musher/lib/boost/install/include/boost/thread/pthread/condition_variable.hpp:73 > #2 0x00007fa56806b38c in boost::thread::join_noexcept() () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #3 0x00007fa56806750a in join (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread.hpp:756 > #4 join_all (this=0x7fa557598010) at /root/musher/lib/boost/install/include/boost/thread/detail/thread_group.hpp:118 > #5 plugin::PS_tcplog::TcpSession::Run (this=0x7fa557598010) at /root/probe4/tcplog/src/TcpSession.h:136 > #6 0x00007fa56806a893 in thread_proxy () from /usr/local/bro/lib/bro/plugins/PS_tcplog//lib/PS-tcplog.linux-x86_64.so > #7 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #8 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fa50abfd700 (LWP 11050)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600aea0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600aea0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600aea0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fa50bfff700 (LWP 10872)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4987830) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4987830) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4987830) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fa544dfa700 (LWP 10862)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x47472b0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x47472b0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x47472b0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fa50a1fc700 (LWP 11051)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x600c220) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x600c220) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x600c220) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fa547fff700 (LWP 10857)): > #0 0x000000334600b98e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000060d898 in Get (this=0x4710cf0) at /root/bro/src/threading/Queue.h:173 > #2 threading::MsgThread::RetrieveIn (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:349 > #3 0x000000000060e92e in threading::MsgThread::Run (this=0x4710cf0) at /root/bro/src/threading/MsgThread.cc:366 > #4 0x000000000060b51d in threading::BasicThread::launcher (arg=0x4710cf0) at /root/bro/src/threading/BasicThread.cc:201 > #5 0x00000033460079d1 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003345ce88fd in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fa5684897e0 (LWP 10822)): > #0 0x0000003345c32625 in raise () from /lib64/libc.so.6 > #1 0x0000003345c33e05 in abort () from /lib64/libc.so.6 > #2 0x00000000005a71f0 in Reporter::InternalError (this=, fmt=) at /root/bro/src/Reporter.cc:137 > #3 0x00000000005ad319 in bad_ref (type=) at /root/bro/src/Obj.cc:257 > #4 0x00000000005dfe07 in Ref (this=) at /root/bro/src/Obj.h:211 > #5 StateAccess::RefThem (this=) at /root/bro/src/StateAccess.cc:135 > #6 0x00000000005dfedb in StateAccess::StateAccess (this=0x6db97b0, arg_opcode=, arg_target=, arg_op1=, arg_op2=, arg_op3=) at /root/bro/src/StateAccess.cc:25 > #7 0x0000000000603836 in VectorVal::Assign (this=0x4b80d90, index=, element=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.cc:3002 > #8 0x000000000056a387 in Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Val.h:969 > #9 IndexExpr::Assign (this=0x35b2040, f=, v=0x1c974230, op=OP_ASSIGN) at /root/bro/src/Expr.cc:3130 > #10 0x0000000000565716 in AddToExpr::Eval (this=0x35b2610, f=0xd8cfa90) at /root/bro/src/Expr.cc:1478 > #11 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:369 > #12 0x00000000005e4b81 in StmtList::Exec (this=0x35b1670, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #13 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #14 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #15 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #16 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #17 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #18 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #19 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #20 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #21 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #22 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #23 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0xd8cfa90, v=, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:484 > #24 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #25 0x00000000005e4b81 in StmtList::Exec (this=0x35aad90, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #26 0x00000000005e9e40 in ForStmt::DoExec (this=0x35aace0, f=0xd8cfa90, v=0x234764a0, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1358 > #27 0x00000000005eafcf in ExprStmt::Exec (this=, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:373 > #28 0x00000000005e4b81 in StmtList::Exec (this=0x35aa890, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #29 0x00000000005e4b81 in StmtList::Exec (this=0x35b2db0, f=0xd8cfa90, flow=@0x7fffc2ba324c) at /root/bro/src/Stmt.cc:1764 > #30 0x000000000058aa21 in BroFunc::Call (this=0x35b2cb0, args=, parent=0x1cd65bd0) at /root/bro/src/Func.cc:386 > #31 0x0000000000569402 in CallExpr::Eval (this=0x2821c50, f=0x1cd65bd0) at /root/bro/src/Expr.cc:4920 > #32 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:369 > #33 0x00000000005e4b81 in StmtList::Exec (this=0x2820860, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #34 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #35 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #36 0x00000000005e4b81 in StmtList::Exec (this=0x2820350, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #37 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x1cd65bd0, v=, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:484 > #38 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:373 > #39 0x00000000005e4b81 in StmtList::Exec (this=0x2825e10, f=0x1cd65bd0, flow=@0x7fffc2ba35fc) at /root/bro/src/Stmt.cc:1764 > #40 0x000000000058aa21 in BroFunc::Call (this=0x2819c30, args=, parent=0x17d92d20) at /root/bro/src/Func.cc:386 > #41 0x0000000000569402 in CallExpr::Eval (this=0x2885a00, f=0x17d92d20) at /root/bro/src/Expr.cc:4920 > #42 0x00000000005eafb0 in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:369 > #43 0x00000000005e4b81 in StmtList::Exec (this=0x28852d0, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #44 0x00000000005e4c6f in IfStmt::DoExec (this=, f=0x17d92d20, v=, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:484 > #45 0x00000000005eafcf in ExprStmt::Exec (this=, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:373 > #46 0x00000000005e4b81 in StmtList::Exec (this=0x2880c40, f=0x17d92d20, flow=@0x7fffc2ba38fc) at /root/bro/src/Stmt.cc:1764 > #47 0x000000000058aa21 in BroFunc::Call (this=0x27855e0, args=, parent=0x0) at /root/bro/src/Func.cc:386 > #48 0x000000000055404b in EventHandler::Call (this=0x2785760, vl=0x22a71780, no_remote=) at /root/bro/src/EventHandler.cc:80 > #49 0x00000000005c3de1 in Dispatch (this=0x195c500) at /root/bro/src/Event.h:50 > #50 Dispatch (this=0x195c500) at /root/bro/src/Event.h:98 > #51 RemoteSerializer::Process (this=0x195c500) at /root/bro/src/RemoteSerializer.cc:1439 > #52 0x00000000005a8d94 in net_run () at /root/bro/src/Net.cc:320 > #53 0x0000000000527945 in main (argc=, argv=) at /root/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal error: bad reference count [0] > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 10822 Aborted (core dumped) nohup $mybro "$@" > ==== stdout.log > Known::SERVICES_LOG > Files::LOG > Syslog::LOG > Known::CERTS_LOG > Known::HOSTS_LOG > PacketFilter::LOG > X509::LOG > Traceroute::LOG > Notice::LOG > Cluster::LOG > ==== .cmdline > -U .status -p broctl -p broctl-live -p local -p manager local.bro broctl base/frameworks/cluster local-manager.bro broctl/auto > ==== .env_vars > PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/tokumx/bin:/root/bin > BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site > CLUSTER_NODE=manager > ==== .status > TERMINATED [internal_error] > {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 17:41:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 19:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1337) Bro worker crash - terminate after 'std::length_error' In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20416#comment-20416 ] Robin Sommer commented on BIT-1337: ----------------------------------- I took a shot into the dark here in 27885e8f0dd2. Closing the ticket, as it will remain unclear how to address this anyways. > Bro worker crash - terminate after 'std::length_error' > ------------------------------------------------------ > > Key: BIT-1337 > URL: https://bro-tracker.atlassian.net/browse/BIT-1337 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Josh Liburdi > Assignee: Seth Hall > Fix For: 2.4 > > > Running Bro master with the Kerberos and RDP analyzer branches resulted in one crashed worker on a pf_ring cluster. BroControl diag results below: > terminate called after throwing an instance of 'std::length_error' > what(): basic_string::_S_create > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 195850 Aborted (core dumped) nohup $mybro "$@" -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 21 17:41:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 21 Apr 2015 19:41:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1337) Bro worker crash - terminate after 'std::length_error' In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1337: ------------------------------ Resolution: Done Status: Closed (was: Open) > Bro worker crash - terminate after 'std::length_error' > ------------------------------------------------------ > > Key: BIT-1337 > URL: https://bro-tracker.atlassian.net/browse/BIT-1337 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Josh Liburdi > Assignee: Seth Hall > Fix For: 2.4 > > > Running Bro master with the Kerberos and RDP analyzer branches resulted in one crashed worker on a pf_ring cluster. BroControl diag results below: > terminate called after throwing an instance of 'std::length_error' > what(): basic_string::_S_create > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 195850 Aborted (core dumped) nohup $mybro "$@" -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 04:16:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Wed, 22 Apr 2015 06:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1382) bro 2.3.2 memory leak In-Reply-To: References: Message-ID: Garanews created BIT-1382: ----------------------------- Summary: bro 2.3.2 memory leak Key: BIT-1382 URL: https://bro-tracker.atlassian.net/browse/BIT-1382 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Environment: Ubuntu 12.04.5 LTS Reporter: Garanews After a day BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 04:18:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Wed, 22 Apr 2015 06:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: Garanews created BIT-1383: ----------------------------- Summary: memory leak Key: BIT-1383 URL: https://bro-tracker.atlassian.net/browse/BIT-1383 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Environment: Ubuntu 12.04.5 LTS Reporter: Garanews BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 05:27:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Wed, 22 Apr 2015 07:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1382) bro 2.3.2 memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garanews updated BIT-1382: -------------------------- Resolution: Duplicate Status: Closed (was: Open) > bro 2.3.2 memory leak > --------------------- > > Key: BIT-1382 > URL: https://bro-tracker.atlassian.net/browse/BIT-1382 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > > After a day BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 08:10:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 10:10:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1336: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > ElasticSearch indices in UTC > ---------------------------- > > Key: BIT-1336 > URL: https://bro-tracker.atlassian.net/browse/BIT-1336 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Seth Hall > Priority: Trivial > Fix For: 2.5 > > > For improved compatibility with Kibana and other ElasticSearch frontends, the timestamps on the Bro indices should be changed to UTC. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 08:10:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 10:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1257) Same file id generated for potentially different files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1257: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > Same file id generated for potentially different files > ------------------------------------------------------ > > Key: BIT-1257 > URL: https://bro-tracker.atlassian.net/browse/BIT-1257 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: CentOS 6 > Reporter: Jimmy Jones > Assignee: Seth Hall > Fix For: 2.5 > > Attachments: fa.bro, sample-samefileid.pcap > > > Attached sample contains two HTTP downloads of the same URL from the same client, but there are no guarantees that the files is actually the same (no Etags etc - in this case it actually is the same, but lets pretend they were different...). However the file analysis framework seems to give the same file ID in file_name and file_chunk for both downloads. > Think this is something to do with Range requests as doesn't happen if do "normal" HTTP requests. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 08:11:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 10:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1154) Formatters restructed in: topic/seth/json-formatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20417#comment-20417 ] Robin Sommer commented on BIT-1154: ----------------------------------- Lesson: Don't merge without the tests being there .... > Formatters restructed in: topic/seth/json-formatter > --------------------------------------------------- > > Key: BIT-1154 > URL: https://bro-tracker.atlassian.net/browse/BIT-1154 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > topic/seth/json-formatter has an abstraction for Formatters and I created a formatters directory under threading. There is also a new JSON formatter and support in the Ascii and ElasticSearch writers for the JSON formatter. > I went ahead and threw in per-filter configuration options for the Ascii writer for all of the options that were exposed globally too. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 08:11:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 10:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1154) Formatters restructed in: topic/seth/json-formatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1154: ------------------------------ Fix Version/s: (was: 2.4) 2.5 > Formatters restructed in: topic/seth/json-formatter > --------------------------------------------------- > > Key: BIT-1154 > URL: https://bro-tracker.atlassian.net/browse/BIT-1154 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > topic/seth/json-formatter has an abstraction for Formatters and I created a formatters directory under threading. There is also a new JSON formatter and support in the Ascii and ElasticSearch writers for the JSON formatter. > I went ahead and threw in per-filter configuration options for the Ascii writer for all of the options that were exposed globally too. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 08:14:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Wed, 22 Apr 2015 10:14:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: Vlad Grigorescu created BIT-1384: ------------------------------------ Summary: Optimize option leads to internal error Key: BIT-1384 URL: https://bro-tracker.atlassian.net/browse/BIT-1384 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vlad Grigorescu On a whim, I tried using the optimize option: > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() bq. Program received signal SIGABRT, Aborted. bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 bq. (gdb) bt bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From robin at icir.org Wed Apr 22 08:16:01 2015 From: robin at icir.org (Robin Sommer) Date: Wed, 22 Apr 2015 08:16:01 -0700 Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: <20150422151601.GD50462@icir.org> On Wed, Apr 22, 2015 at 10:14 -0500, you wrote: > If it's not used much any more, should we consider removing it? Yes, I think so. From jira at bro-tracker.atlassian.net Wed Apr 22 08:17:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 10:17:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1384: ------------------------------ Yes, I think so. > Optimize option leads to internal error > --------------------------------------- > > Key: BIT-1384 > URL: https://bro-tracker.atlassian.net/browse/BIT-1384 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vlad Grigorescu > > On a whim, I tried using the optimize option: > > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > bq. Program received signal SIGABRT, Aborted. > bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. (gdb) bt > bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 > bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 > bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 > bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 > bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 > bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 > bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 > bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 > bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 > bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 > bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 > bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 09:48:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 22 Apr 2015 11:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1385) binpac example analyzer is outdated In-Reply-To: References: Message-ID: Robin Sommer created BIT-1385: --------------------------------- Summary: binpac example analyzer is outdated Key: BIT-1385 URL: https://bro-tracker.atlassian.net/browse/BIT-1385 Project: Bro Issue Tracker Issue Type: Problem Components: Website Reporter: Robin Sommer Fix For: 2.4 This hasn't been working anymore for a while already: https://www.bro.org/development/howtos/binpac-sample-analyzer.html We should probably instead link to Vlad's binpac quickstart at https://github.com/grigorescu/binpac_quickstart, ideally with a bit of a walkthrough how to get started with that. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 12:19:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 22 Apr 2015 14:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1386) topic/jsiwek/missing-pac-deps In-Reply-To: References: Message-ID: Jon Siwek created BIT-1386: ------------------------------ Summary: topic/jsiwek/missing-pac-deps Key: BIT-1386 URL: https://bro-tracker.atlassian.net/browse/BIT-1386 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Jon Siwek This branch may help the recent problems w/ binpac analyzer dependency tracking. To get binpac target dependencies fully automated, I think we need support in CMake itself for custom dependency scanners, like mentioned in these: http://public.kitware.com/Bug/view.php?id=2172 http://www.mail-archive.com/cmake at cmake.org/msg30396.html The problem is that if we tried to do our own dependency scan for %includes at configure-time (like in a CMake script), then a .pac file is modified to have more %includes, those later ones don?t get included in the dependency chain unless a CMake configuration runs again. Explicitly specifying all the dependency .pac files may have to do for now. This was always the case, but mostly recent analyzers didn't strictly adhere to this rule (which isn't very clear if just copy-pasting the CMake stuff from another analyzer). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 12:19:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 22 Apr 2015 14:19:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1386) topic/jsiwek/missing-pac-deps In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1386: --------------------------- Status: Merge Request (was: Open) > topic/jsiwek/missing-pac-deps > ----------------------------- > > Key: BIT-1386 > URL: https://bro-tracker.atlassian.net/browse/BIT-1386 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > > This branch may help the recent problems w/ binpac analyzer dependency tracking. > To get binpac target dependencies fully automated, I think we need support in CMake itself for custom dependency scanners, like mentioned in these: > http://public.kitware.com/Bug/view.php?id=2172 > http://www.mail-archive.com/cmake at cmake.org/msg30396.html > The problem is that if we tried to do our own dependency scan for %includes at configure-time (like in a CMake script), then a .pac file is modified to have more %includes, those later ones don?t get included in the dependency chain unless a CMake configuration runs again. > Explicitly specifying all the dependency .pac files may have to do for now. This was always the case, but mostly recent analyzers didn't strictly adhere to this rule (which isn't very clear if just copy-pasting the CMake stuff from another analyzer). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 22 14:42:00 2015 From: jira at bro-tracker.atlassian.net (yun (JIRA)) Date: Wed, 22 Apr 2015 16:42:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1314) Detect "quantum insert" type of attacks In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20419#comment-20419 ] yun commented on BIT-1314: -------------------------- We made a proof of concept Bro policy to detect QI here: https://github.com/fox-it/quantuminsert/tree/master/detection/bro It would be nice if the rexmit_inconsistency event could do this though. > Detect "quantum insert" type of attacks > --------------------------------------- > > Key: BIT-1314 > URL: https://bro-tracker.atlassian.net/browse/BIT-1314 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: David Andr? > > Add detection for "quantum insert" type of attacks. Since the leaked information is classified, I will try to explain in unclassified form what it is about. > The idea is that you have a passive adversary that sniff your TCP sequence numbers and inject its malicious payload faster than the real server. > One of the leaked documents mentions as an alerting mechanism to detect duplicate TCP sequence numbers from same source, where at least 10% of the beginning of the content of the two packets differs. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Thu Apr 23 00:00:31 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 23 Apr 2015 00:00:31 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504230700.t3N70Va2019661@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- --------------------------------- BIT-1386 [1] Bro Jon Siwek - 2015-04-22 - Normal topic/jsiwek/missing-pac-deps [2] Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- -------------------------------------------- 2579b08 [3] bro-aux Daniel Thayer 2015-04-22 Correct a few typos in update-changes script [1] BIT-1386 https://bro-tracker.atlassian.net/browse/BIT-1386 [2] missing-pac-deps https://github.com/bro/bro/tree/topic/jsiwek/missing-pac-deps [3] 2579b08 https://github.com/bro/bro-aux/commit/2579b08e91160c0c93a0289f1164be19c47cd555 From jira at bro-tracker.atlassian.net Thu Apr 23 06:55:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 23 Apr 2015 08:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1386) topic/jsiwek/missing-pac-deps In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1386: --------------------------------- Assignee: Robin Sommer > topic/jsiwek/missing-pac-deps > ----------------------------- > > Key: BIT-1386 > URL: https://bro-tracker.atlassian.net/browse/BIT-1386 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > > This branch may help the recent problems w/ binpac analyzer dependency tracking. > To get binpac target dependencies fully automated, I think we need support in CMake itself for custom dependency scanners, like mentioned in these: > http://public.kitware.com/Bug/view.php?id=2172 > http://www.mail-archive.com/cmake at cmake.org/msg30396.html > The problem is that if we tried to do our own dependency scan for %includes at configure-time (like in a CMake script), then a .pac file is modified to have more %includes, those later ones don?t get included in the dependency chain unless a CMake configuration runs again. > Explicitly specifying all the dependency .pac files may have to do for now. This was always the case, but mostly recent analyzers didn't strictly adhere to this rule (which isn't very clear if just copy-pasting the CMake stuff from another analyzer). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 07:17:00 2015 From: jira at bro-tracker.atlassian.net (Frank Meier (JIRA)) Date: Thu, 23 Apr 2015 09:17:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1387) segfault in nb_dns.cc when nameserver is not reachable In-Reply-To: References: Message-ID: Frank Meier created BIT-1387: -------------------------------- Summary: segfault in nb_dns.cc when nameserver is not reachable Key: BIT-1387 URL: https://bro-tracker.atlassian.net/browse/BIT-1387 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3, git/master Environment: Ubuntu 14.10 and Debian Minimal 7.8 Reporter: Frank Meier The segfault happens, if a nameserver is set in /etc/resolv.conf, but the network of the nameserver is not reachable: $ cat /etc/resolv.conf nameserver 192.168.1.1 $ cat dns.bro event bro_init() { when ( local result = lookup_hostname("example.com") ) { } } $ bro -v bro version 2.3-793 $ bro dns.bro warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable warning: can't issue DNS request warning: can't issue DNS request Segmentation fault (core dumped) The segfault does not happen, if BRO_DNS_FAKE ist set to on or off: $ BRO_DNS_FAKE=0 bro dns.bro warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable $ BRO_DNS_FAKE=1 bro dns.bro warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable Here is the backtrace: $ gdb bro /tmp/core GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs [...] Core was generated by `bro dns.bro'. Program terminated with signal SIGSEGV, Segmentation fault. #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 176 return (nd->s); (gdb) bt #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 #1 0x0000000000567c1d in DNS_Mgr::AnswerAvailable (this=, timeout=0) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1425 #2 0x000000000056c24a in DNS_Mgr::DoProcess (this=0x15c1410, flush=false) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1382 #3 0x000000000056c420 in DNS_Mgr::Flush (this=0x15c1410) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1334 #4 0x0000000000540126 in done_with_network () at /home/franky/bro-git/bro/src/main.cc:316 #5 0x000000000051f679 in main (argc=, argv=) at /home/franky/bro-git/bro/src/main.cc:1216 fix option 1: diff --git a/src/DNS_Mgr.cc b/src/DNS_Mgr.cc index 11fd258..08f76df 100644 --- a/src/DNS_Mgr.cc +++ b/src/DNS_Mgr.cc @@ -1422,6 +1422,10 @@ void DNS_Mgr::DoProcess(bool flush) int DNS_Mgr::AnswerAvailable(int timeout) { + if (!nb_dns) { + reporter->Warning("nb_dns_fd() failed in DNS_Mgr::WaitForReplies"); + return -1; + } int fd = nb_dns_fd(nb_dns); if ( fd < 0 ) { fix option 2: diff --git a/src/nb_dns.c b/src/nb_dns.c index 33a0083..22778e2 100644 --- a/src/nb_dns.c +++ b/src/nb_dns.c @@ -172,7 +172,9 @@ nb_dns_finish(struct nb_dns_info *nd) int nb_dns_fd(struct nb_dns_info *nd) { - + if (!nd) { + return -1; + } return (nd->s); } -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 07:20:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 23 Apr 2015 09:20:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1387) segfault in nb_dns.cc when nameserver is not reachable In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1387: ------------------------------ Fix Version/s: 2.4 > segfault in nb_dns.cc when nameserver is not reachable > ------------------------------------------------------ > > Key: BIT-1387 > URL: https://bro-tracker.atlassian.net/browse/BIT-1387 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Ubuntu 14.10 and Debian Minimal 7.8 > Reporter: Frank Meier > Fix For: 2.4 > > > The segfault happens, if a nameserver is set in /etc/resolv.conf, but the network > of the nameserver is not reachable: > $ cat /etc/resolv.conf > nameserver 192.168.1.1 > $ cat dns.bro > event bro_init() { > when ( local result = lookup_hostname("example.com") ) { > } > } > $ bro -v > bro version 2.3-793 > $ bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > warning: can't issue DNS request > warning: can't issue DNS request > Segmentation fault (core dumped) > The segfault does not happen, if BRO_DNS_FAKE ist set to on or off: > $ BRO_DNS_FAKE=0 bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > $ BRO_DNS_FAKE=1 bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > Here is the backtrace: > $ gdb bro /tmp/core > GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs > [...] > Core was generated by `bro dns.bro'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 > 176 return (nd->s); > (gdb) bt > #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 > #1 0x0000000000567c1d in DNS_Mgr::AnswerAvailable (this=, timeout=0) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1425 > #2 0x000000000056c24a in DNS_Mgr::DoProcess (this=0x15c1410, flush=false) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1382 > #3 0x000000000056c420 in DNS_Mgr::Flush (this=0x15c1410) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1334 > #4 0x0000000000540126 in done_with_network () at /home/franky/bro-git/bro/src/main.cc:316 > #5 0x000000000051f679 in main (argc=, argv=) at /home/franky/bro-git/bro/src/main.cc:1216 > fix option 1: > diff --git a/src/DNS_Mgr.cc b/src/DNS_Mgr.cc > index 11fd258..08f76df 100644 > --- a/src/DNS_Mgr.cc > +++ b/src/DNS_Mgr.cc > @@ -1422,6 +1422,10 @@ void DNS_Mgr::DoProcess(bool flush) > > int DNS_Mgr::AnswerAvailable(int timeout) > { > + if (!nb_dns) { > + reporter->Warning("nb_dns_fd() failed in DNS_Mgr::WaitForReplies"); > + return -1; > + } > int fd = nb_dns_fd(nb_dns); > if ( fd < 0 ) > { > fix option 2: > diff --git a/src/nb_dns.c b/src/nb_dns.c > index 33a0083..22778e2 100644 > --- a/src/nb_dns.c > +++ b/src/nb_dns.c > @@ -172,7 +172,9 @@ nb_dns_finish(struct nb_dns_info *nd) > int > nb_dns_fd(struct nb_dns_info *nd) > { > - > + if (!nd) { > + return -1; > + } > return (nd->s); > } -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 07:24:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 23 Apr 2015 09:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1386) topic/jsiwek/missing-pac-deps In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1386: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > topic/jsiwek/missing-pac-deps > ----------------------------- > > Key: BIT-1386 > URL: https://bro-tracker.atlassian.net/browse/BIT-1386 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > > This branch may help the recent problems w/ binpac analyzer dependency tracking. > To get binpac target dependencies fully automated, I think we need support in CMake itself for custom dependency scanners, like mentioned in these: > http://public.kitware.com/Bug/view.php?id=2172 > http://www.mail-archive.com/cmake at cmake.org/msg30396.html > The problem is that if we tried to do our own dependency scan for %includes at configure-time (like in a CMake script), then a .pac file is modified to have more %includes, those later ones don?t get included in the dependency chain unless a CMake configuration runs again. > Explicitly specifying all the dependency .pac files may have to do for now. This was always the case, but mostly recent analyzers didn't strictly adhere to this rule (which isn't very clear if just copy-pasting the CMake stuff from another analyzer). -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 07:48:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Thu, 23 Apr 2015 09:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20420#comment-20420 ] Garanews commented on BIT-1383: ------------------------------- How is possible to identify it there is a script that is having a memory leak instead bro service? > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 09:51:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 23 Apr 2015 11:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20421#comment-20421 ] Jon Siwek commented on BIT-1383: -------------------------------- Can you check/post the content of reporter.log for errors? Some types of scripting errors may result in memory leaks. Also, loading the policy/misc/profiling.bro script should generate a prof.log and in that may be useful information about script-layer state (e.g. tables) that are growing large. > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 10:46:00 2015 From: jira at bro-tracker.atlassian.net (Aaron Eppert (JIRA)) Date: Thu, 23 Apr 2015 12:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1387) segfault in nb_dns.cc when nameserver is not reachable In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20422#comment-20422 ] Aaron Eppert commented on BIT-1387: ----------------------------------- This is how I fixed it in my local repository. There are a few other areas in DNS_Mgr.cc that need to definitely be shored up. Also, I would say, there needs to be some kind of state kept on DNS failures so that there doesn't have to be a log generated each and every time this occurs. There are definitely instances of Bro being leveraged on internal networks where an outbound, or even local, DNS resolution isn't possible. Typically this would mean: eth1 - Passive collection through Bro from a tap or other eth0 - General outbound connections, but in the case of a security audit may be disconnected, thus rendering DNS resolution not possible. I resolved this further and prevented excessive reporter.log issues, by modifying my Bro init script to add 127.0.0.1 as the nameserver in resolv.conf when eth0 is disconnected. This would, then, be overwritten accordingly if eth0 came up because of DHCP. > segfault in nb_dns.cc when nameserver is not reachable > ------------------------------------------------------ > > Key: BIT-1387 > URL: https://bro-tracker.atlassian.net/browse/BIT-1387 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Ubuntu 14.10 and Debian Minimal 7.8 > Reporter: Frank Meier > Fix For: 2.4 > > > The segfault happens, if a nameserver is set in /etc/resolv.conf, but the network > of the nameserver is not reachable: > $ cat /etc/resolv.conf > nameserver 192.168.1.1 > $ cat dns.bro > event bro_init() { > when ( local result = lookup_hostname("example.com") ) { > } > } > $ bro -v > bro version 2.3-793 > $ bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > warning: can't issue DNS request > warning: can't issue DNS request > Segmentation fault (core dumped) > The segfault does not happen, if BRO_DNS_FAKE ist set to on or off: > $ BRO_DNS_FAKE=0 bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > $ BRO_DNS_FAKE=1 bro dns.bro > warning in /home/franky/bro-git/bro/scripts/base/init-bare.bro, line 1: problem initializing NB-DNS: connect(192.168.1.1): Network is unreachable > Here is the backtrace: > $ gdb bro /tmp/core > GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs > [...] > Core was generated by `bro dns.bro'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 > 176 return (nd->s); > (gdb) bt > #0 nb_dns_fd (nd=0x0) at /home/franky/bro-git/bro/src/nb_dns.c:176 > #1 0x0000000000567c1d in DNS_Mgr::AnswerAvailable (this=, timeout=0) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1425 > #2 0x000000000056c24a in DNS_Mgr::DoProcess (this=0x15c1410, flush=false) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1382 > #3 0x000000000056c420 in DNS_Mgr::Flush (this=0x15c1410) at /home/franky/bro-git/bro/src/DNS_Mgr.cc:1334 > #4 0x0000000000540126 in done_with_network () at /home/franky/bro-git/bro/src/main.cc:316 > #5 0x000000000051f679 in main (argc=, argv=) at /home/franky/bro-git/bro/src/main.cc:1216 > fix option 1: > diff --git a/src/DNS_Mgr.cc b/src/DNS_Mgr.cc > index 11fd258..08f76df 100644 > --- a/src/DNS_Mgr.cc > +++ b/src/DNS_Mgr.cc > @@ -1422,6 +1422,10 @@ void DNS_Mgr::DoProcess(bool flush) > > int DNS_Mgr::AnswerAvailable(int timeout) > { > + if (!nb_dns) { > + reporter->Warning("nb_dns_fd() failed in DNS_Mgr::WaitForReplies"); > + return -1; > + } > int fd = nb_dns_fd(nb_dns); > if ( fd < 0 ) > { > fix option 2: > diff --git a/src/nb_dns.c b/src/nb_dns.c > index 33a0083..22778e2 100644 > --- a/src/nb_dns.c > +++ b/src/nb_dns.c > @@ -172,7 +172,9 @@ nb_dns_finish(struct nb_dns_info *nd) > int > nb_dns_fd(struct nb_dns_info *nd) > { > - > + if (!nd) { > + return -1; > + } > return (nd->s); > } -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 13:36:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 23 Apr 2015 15:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1385) binpac example analyzer is outdated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek reassigned BIT-1385: ------------------------------ Assignee: Jon Siwek > binpac example analyzer is outdated > ----------------------------------- > > Key: BIT-1385 > URL: https://bro-tracker.atlassian.net/browse/BIT-1385 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.4 > > > This hasn't been working anymore for a while already: https://www.bro.org/development/howtos/binpac-sample-analyzer.html > We should probably instead link to Vlad's binpac quickstart at https://github.com/grigorescu/binpac_quickstart, ideally with a bit of a walkthrough how to get started with that. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 23 14:54:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 23 Apr 2015 16:54:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1385) binpac example analyzer is outdated In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1385: --------------------------- Resolution: Fixed Status: Closed (was: Open) I changed it to use binpac_quickstart. Not sure whether the new explanation walkthrough could still use more detail/explanation, but it's at least not outdated/wrong now. > binpac example analyzer is outdated > ----------------------------------- > > Key: BIT-1385 > URL: https://bro-tracker.atlassian.net/browse/BIT-1385 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.4 > > > This hasn't been working anymore for a while already: https://www.bro.org/development/howtos/binpac-sample-analyzer.html > We should probably instead link to Vlad's binpac quickstart at https://github.com/grigorescu/binpac_quickstart, ideally with a bit of a walkthrough how to get started with that. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Fri Apr 24 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 24 Apr 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504240700.t3O70QpR018833@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------- 5ace836 [1] broker Daniel Thayer 2015-04-23 Fix minor typos in the user manual [1] 5ace836 https://github.com/bro/broker/commit/5ace8366b76801043ce858d98d5d11a7597998a8 From jira at bro-tracker.atlassian.net Fri Apr 24 07:58:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Fri, 24 Apr 2015 09:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garanews updated BIT-1383: -------------------------- Attachment: threads.png > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Fri Apr 24 08:00:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Fri, 24 Apr 2015 10:00:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garanews updated BIT-1383: -------------------------- Attachment: screenshot-1.png > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: screenshot-1.png, threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Fri Apr 24 08:03:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Fri, 24 Apr 2015 10:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20424#comment-20424 ] Garanews commented on BIT-1383: ------------------------------- In the reporter.log I have only warnings like this: 1429884007.525166 Reporter::WARNING Analyzer Files::ANALYZER_X509 not added successfully to file FZMat825gmR7UiqCHg. /opt/bro/share/bro/base/frameworks/files/./main.bro, line 286 I have enabled the profiling and looks like: 1429882423.269744 Memory: total=*27988K **total_adj=4127060K malloced: 24905K 1429882423.269744 Run-time: user+sys=285.1 user=256.3 sys=28.8 real=1756.6 1429882423.269744 Conns: total=0 current=0/0 ext=0 mem=0K avg=0.0 table=0K connvals=0K 1429882423.269744 Conns: tcp=0/0 udp=0/0 icmp=0/0 1429882423.269744 TCP-States: Inact. Syn. SA Part. Est. Fin. Rst. 1429882423.269744 TCP-States:Inact. 1429882423.269744 TCP-States:Syn. 1429882423.269744 TCP-States:SA 1429882423.269744 TCP-States:Part. 1429882423.269744 TCP-States:Est. 1429882423.269744 TCP-States:Fin. 1429882423.269744 TCP-States:Rst. 1429882423.269744 Connections expired due to inactivity: 0 1429882423.269744 Total reassembler data: 0K 1429882423.269744 Timers: current=71 max=72 mem=5K lag=0.00s 1429882423.269744 DNS_Mgr: requests=0 succesful=0 failed=0 pending=0 cached_hosts=0 cached_addrs=0 1429882423.269744 Triggers: total=2 pending=0 1429882423.269744 RotateTimer = 28 1429882423.269744 ScheduleTimer = 15 1429882423.269744 TableValTimer = 28 1429882423.269744 Threads: current=36 After a while: 1429887084.548535 Memory: total=*811348K *total_adj=716116K malloced: 791111K 1429887084.548535 Run-time: user+sys=875.4 user=770.1 sys=105.3 real=6417.9 1429887084.548535 Conns: total=0 current=0/0 ext=0 mem=0K avg=0.0 table=0K connvals=0K 1429887084.548535 Conns: tcp=0/0 udp=0/0 icmp=0/0 1429887084.548535 TCP-States: Inact. Syn. SA Part. Est. Fin. Rst. 1429887084.548535 TCP-States:Inact. 1429887084.548535 TCP-States:Syn. 1429887084.548535 TCP-States:SA 1429887084.548535 TCP-States:Part. 1429887084.548535 TCP-States:Est. 1429887084.548535 TCP-States:Fin. 1429887084.548535 TCP-States:Rst. 1429887084.548535 Connections expired due to inactivity: 0 1429887084.548535 Total reassembler data: 0K 1429887084.548535 Timers: current=73 max=74 mem=5K lag=0.00s 1429887084.548535 DNS_Mgr: requests=0 succesful=0 failed=0 pending=0 cached_hosts=0 cached_addrs=0 1429887084.548535 Triggers: total=2 pending=0 1429887084.548535 RotateTimer = 30 1429887084.548535 ScheduleTimer = 15 1429887084.548535 TableValTimer = 28 1429887084.548535 Threads: current=37 So it seems that same threads are leaking ram during time. But see what happened this morning: the number of threads grown up to 150... !threads.png! Seems related to ram leakage: !screenshot-1.png! regarding prof.log what do you mean with table are growing large? I have rows pasted here and others related to single scritps like: 1429887594.568636 software/Log::WRITER_ASCII in=4564 out=197 pending=4296/0 (#queue r/w: in=268/4564 out=197/197) Thanks > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: screenshot-1.png, threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Sat Apr 25 00:00:28 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 25 Apr 2015 00:00:28 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504250700.t3P70Spr031197@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ------------------------------------------------------------ 91f5afb [1] bro-aux Jon Siwek 2015-04-24 Fix sed regex for replacing version in header file. 7a63316 [2] bro Daniel Thayer 2015-04-24 Fix typos in the broker BIF documentation 244dffa [3] bro Johanna Amann 2015-04-24 update installation instructions and remove outdated referen [1] 91f5afb https://github.com/bro/bro-aux/commit/91f5afb101fd75ba2456fafe05252c532fd04d2f [2] 7a63316 https://github.com/bro/bro/commit/7a63316e0eb59f6d6558da5e1b6df362ab57ffab [3] 244dffa https://github.com/bro/bro/commit/244dffa8fc97a21b87e1021af5d60b765c1ea606 From noreply at bro.org Sun Apr 26 00:00:31 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 26 Apr 2015 00:00:31 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504260700.t3Q70V9p025898@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ------------------------------------------------------------ 91f5afb [1] bro-aux Jon Siwek 2015-04-24 Fix sed regex for replacing version in header file. 7a63316 [2] bro Daniel Thayer 2015-04-24 Fix typos in the broker BIF documentation 244dffa [3] bro Johanna Amann 2015-04-24 update installation instructions and remove outdated referen [1] 91f5afb https://github.com/bro/bro-aux/commit/91f5afb101fd75ba2456fafe05252c532fd04d2f [2] 7a63316 https://github.com/bro/bro/commit/7a63316e0eb59f6d6558da5e1b6df362ab57ffab [3] 244dffa https://github.com/bro/bro/commit/244dffa8fc97a21b87e1021af5d60b765c1ea606 From noreply at bro.org Mon Apr 27 00:00:43 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 27 Apr 2015 00:00:43 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504270700.t3R70hW1002358@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ------------------------------------------------------------ 91f5afb [1] bro-aux Jon Siwek 2015-04-24 Fix sed regex for replacing version in header file. 7a63316 [2] bro Daniel Thayer 2015-04-24 Fix typos in the broker BIF documentation 244dffa [3] bro Johanna Amann 2015-04-24 update installation instructions and remove outdated referen [1] 91f5afb https://github.com/bro/bro-aux/commit/91f5afb101fd75ba2456fafe05252c532fd04d2f [2] 7a63316 https://github.com/bro/bro/commit/7a63316e0eb59f6d6558da5e1b6df362ab57ffab [3] 244dffa https://github.com/bro/bro/commit/244dffa8fc97a21b87e1021af5d60b765c1ea606 From robin at icir.org Mon Apr 27 08:28:48 2015 From: robin at icir.org (Robin Sommer) Date: Mon, 27 Apr 2015 08:28:48 -0700 Subject: [Bro-Dev] Memory usage? Message-ID: <20150427152848.GO5910@icir.org> So I was hearing rumors earlier that memory usage might be worse with current git. Anybody seeing that? That would be a reason to hold off on the beta. Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From jira at bro-tracker.atlassian.net Mon Apr 27 10:10:02 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 27 Apr 2015 12:10:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1388) Broker's integration in Bro's main/run loop In-Reply-To: References: Message-ID: Jon Siwek created BIT-1388: ------------------------------ Summary: Broker's integration in Bro's main/run loop Key: BIT-1388 URL: https://bro-tracker.atlassian.net/browse/BIT-1388 Project: Bro Issue Tracker Issue Type: Problem Components: Bro, Broker Reporter: Jon Siwek Fix For: 2.5 * There's a cost to Broker queues being idle. Whenever Broker gets a chance to process messages, it looks for updates to all connections/message-queues/data-stores. That involves sending synchronous messages between actors, and for empty queues, it just gets back an empty deque object it needs to destroy. * Broker queues integrate into Bro's run loop by exposing a file descriptor that's ready when the queue is non-empty. Users have the capability of adding arbitrary numbers of queues at run-time (e.g. they can freely add subscriptions to any amount of logs, events, etc.). Relying on select() may become a bottleneck if someone has hundreds of Broker queues, or could possibly break on some systems if FD_SETSIZE is limited to 1024. Ideas on how to fix: * Improve Bro's main run loop and dedicate an IOSource to each Broker queue (instead of sharing a single IOSource like they do now). There might be several things that could be tweaked in the main run loop, but at a minimum, epoll()/kqueue() could alternatively replace select(). Could also think about using something like libev (http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod) to abstract what particular polling backend is used. Might even be able to use libev's timers to fix how Bro's timers are currently coupled w/ there being an active IOSource consistently driving time forward. * Move the draining of Broker queues completely off to their own threads. This maybe is adding a bit too much complexity (Broker/CAF uses threads for queues, then Bro would use more threads just to talk to those other threads...). Since CAF becomes a requirement, it may be simpler to start replacing/allowing some areas of Bro's threading to be done w/ CAF actors. And then if Broker exposed an optional API to talk directly w/ CAF actors, the integration w/ Bro may actually become more straightforward. And those ideas don't have to be mutually exclusive. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 27 13:14:03 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 27 Apr 2015 15:14:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20500#comment-20500 ] Jon Siwek commented on BIT-1384: -------------------------------- topic/jsiwek/bit-1384 removes the -O option and all associated code. > Optimize option leads to internal error > --------------------------------------- > > Key: BIT-1384 > URL: https://bro-tracker.atlassian.net/browse/BIT-1384 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vlad Grigorescu > > On a whim, I tried using the optimize option: > > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > bq. Program received signal SIGABRT, Aborted. > bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. (gdb) bt > bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 > bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 > bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 > bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 > bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 > bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 > bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 > bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 > bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 > bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 > bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 > bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 27 13:15:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 27 Apr 2015 15:15:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1384: --------------------------- Status: Merge Request (was: Open) > Optimize option leads to internal error > --------------------------------------- > > Key: BIT-1384 > URL: https://bro-tracker.atlassian.net/browse/BIT-1384 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vlad Grigorescu > > On a whim, I tried using the optimize option: > > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > bq. Program received signal SIGABRT, Aborted. > bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. (gdb) bt > bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 > bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 > bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 > bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 > bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 > bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 > bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 > bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 > bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 > bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 > bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 > bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 27 13:55:01 2015 From: jira at bro-tracker.atlassian.net (leres (JIRA)) Date: Mon, 27 Apr 2015 15:55:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1389) [2.3.2] broccoli-config --cflags shouldn't list -I/usr/local/include twice In-Reply-To: References: Message-ID: leres created BIT-1389: -------------------------- Summary: [2.3.2] broccoli-config --cflags shouldn't list -I/usr/local/include twice Key: BIT-1389 URL: https://bro-tracker.atlassian.net/browse/BIT-1389 Project: Bro Issue Tracker Issue Type: Patch Components: bro-aux Affects Versions: 2.3 Environment: FreeBSD fun.ee.lbl.gov 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r6: Thu Oct 9 14:53:28 PDT 2014 leres at fun.ee.lbl.gov:/usr/src/9.3-SYS/amd64/compile/LBL amd64 Reporter: leres Priority: Low Attachments: patch.txt For a while now broccoli-config --cflags has listed /usr/local/include twice: {noformat} fun 75 % broccoli-config --cflags -I/usr/local/include -I/usr/local/include -DBROCCOLI {noformat} -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 27 14:44:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 27 Apr 2015 16:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1350) Anonymous inner record insufficient type checking In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20501#comment-20501 ] Jon Siwek commented on BIT-1350: -------------------------------- topic/jsiwek/bit-1350 > Anonymous inner record insufficient type checking > ------------------------------------------------- > > Key: BIT-1350 > URL: https://bro-tracker.atlassian.net/browse/BIT-1350 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Fix For: 2.5 > > > This mistake should be caught at parse-time: > {code} > global crash = "80/tcp"; > type myrec: record { > cid: conn_id; > }; > event bro_init() > { > local mr: myrec; mr = [$cid = [$orig_h=1.2.3.4,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=crash]]; > get_port_transport_proto(mr$cid$resp_p); > } > {code} > instead it errors out at runtime: fatal error in ././test.bro, line 1: Val::CONVERTER (string/port) (80/tcp) -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Mon Apr 27 14:44:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 27 Apr 2015 16:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1350) Anonymous inner record insufficient type checking In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1350: --------------------------- Status: Merge Request (was: Open) > Anonymous inner record insufficient type checking > ------------------------------------------------- > > Key: BIT-1350 > URL: https://bro-tracker.atlassian.net/browse/BIT-1350 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Fix For: 2.5 > > > This mistake should be caught at parse-time: > {code} > global crash = "80/tcp"; > type myrec: record { > cid: conn_id; > }; > event bro_init() > { > local mr: myrec; mr = [$cid = [$orig_h=1.2.3.4,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=crash]]; > get_port_transport_proto(mr$cid$resp_p); > } > {code} > instead it errors out at runtime: fatal error in ././test.bro, line 1: Val::CONVERTER (string/port) (80/tcp) -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From robin at icir.org Mon Apr 27 17:09:08 2015 From: robin at icir.org (Robin Sommer) Date: Mon, 27 Apr 2015 17:09:08 -0700 Subject: [Bro-Dev] Memory usage? In-Reply-To: <20150427152848.GO5910@icir.org> References: <20150427152848.GO5910@icir.org> Message-ID: <20150428000908.GB31581@icir.org> On Mon, Apr 27, 2015 at 08:28 -0700, I wrote: > So I was hearing rumors earlier that memory usage might be worse with > current git. Anybody seeing that? That would be a reason to hold off > on the beta. So I suggest we wait a couple more days to get confirmation that we aren't having memory problems before going ahead with a beta. Can't hurt. Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From noreply at bro.org Tue Apr 28 00:00:29 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 28 Apr 2015 00:00:29 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504280700.t3S70TiZ020634@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ------------------------------------------------- BIT-1384 [1] Bro Vlad Grigorescu - 2015-04-27 - Normal Optimize option leads to internal error BIT-1350 [2] Bro Jon Siwek - 2015-04-27 2.5 Normal Anonymous inner record insufficient type checking Open Fastpath Commits ====================== Commit Component Author Date Summary ------------ ----------- ------------- ---------- ------------------------------------------------------------ 91f5afb [3] bro-aux Jon Siwek 2015-04-24 Fix sed regex for replacing version in header file. ab917bd [4] bro Daniel Thayer 2015-04-27 Fix the -J/--set-seed cmd-line option c008cd3 [5] bro Daniel Thayer 2015-04-27 Remove unused -l, -L, and -Z cmd-line options 85f4f41 [6] bro Daniel Thayer 2015-04-27 Fix the --time and --re-level cmd-line options 3a40d42 [7] bro Daniel Thayer 2015-04-27 Update NEWS with changes to Bro cmd-line options 1b9e2bb [8] bro Daniel Thayer 2015-04-27 Minor corrections and clarifications to NEWS 7a63316 [9] bro Daniel Thayer 2015-04-24 Fix typos in the broker BIF documentation 244dffa [10] bro Johanna Amann 2015-04-24 update installation instructions and remove outdated referen [1] BIT-1384 https://bro-tracker.atlassian.net/browse/BIT-1384 [2] BIT-1350 https://bro-tracker.atlassian.net/browse/BIT-1350 [3] 91f5afb https://github.com/bro/bro-aux/commit/91f5afb101fd75ba2456fafe05252c532fd04d2f [4] ab917bd https://github.com/bro/bro/commit/ab917bd48c29cca5a588c23791453b111b75b40a [5] c008cd3 https://github.com/bro/bro/commit/c008cd3fcb43d0a50893a972356d7e70b501bd8e [6] 85f4f41 https://github.com/bro/bro/commit/85f4f4102d0e2d3fbe561f30545fffb6ae510013 [7] 3a40d42 https://github.com/bro/bro/commit/3a40d42b2ba2768b5e3a245a0f51c043d5bd4c2e [8] 1b9e2bb https://github.com/bro/bro/commit/1b9e2bb3f46c1cf0a9bfb714b9d862ea53cd746d [9] 7a63316 https://github.com/bro/bro/commit/7a63316e0eb59f6d6558da5e1b6df362ab57ffab [10] 244dffa https://github.com/bro/bro/commit/244dffa8fc97a21b87e1021af5d60b765c1ea606 From jira at bro-tracker.atlassian.net Tue Apr 28 06:17:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Tue, 28 Apr 2015 08:17:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garanews updated BIT-1383: -------------------------- Attachment: log.tar.gz > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: log.tar.gz, screenshot-1.png, threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 06:18:00 2015 From: jira at bro-tracker.atlassian.net (Garanews (JIRA)) Date: Tue, 28 Apr 2015 08:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20502#comment-20502 ] Garanews commented on BIT-1383: ------------------------------- Hello, in attached the output of diag and the prof.log. I disabled all scripts inside local.bro. There is still memory leak. > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: log.tar.gz, screenshot-1.png, threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 07:04:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 28 Apr 2015 09:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1350) Anonymous inner record insufficient type checking In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1350: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Anonymous inner record insufficient type checking > ------------------------------------------------- > > Key: BIT-1350 > URL: https://bro-tracker.atlassian.net/browse/BIT-1350 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Fix For: 2.5 > > > This mistake should be caught at parse-time: > {code} > global crash = "80/tcp"; > type myrec: record { > cid: conn_id; > }; > event bro_init() > { > local mr: myrec; mr = [$cid = [$orig_h=1.2.3.4,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=crash]]; > get_port_transport_proto(mr$cid$resp_p); > } > {code} > instead it errors out at runtime: fatal error in ././test.bro, line 1: Val::CONVERTER (string/port) (80/tcp) -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 07:04:02 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 28 Apr 2015 09:04:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1384: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Optimize option leads to internal error > --------------------------------------- > > Key: BIT-1384 > URL: https://bro-tracker.atlassian.net/browse/BIT-1384 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vlad Grigorescu > > On a whim, I tried using the optimize option: > > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > bq. Program received signal SIGABRT, Aborted. > bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. (gdb) bt > bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 > bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 > bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 > bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 > bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 > bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 > bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 > bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 > bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 > bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 > bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 > bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 07:47:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 28 Apr 2015 09:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1350) Anonymous inner record insufficient type checking In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1350: --------------------------- Fix Version/s: (was: 2.5) 2.4 > Anonymous inner record insufficient type checking > ------------------------------------------------- > > Key: BIT-1350 > URL: https://bro-tracker.atlassian.net/browse/BIT-1350 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Fix For: 2.4 > > > This mistake should be caught at parse-time: > {code} > global crash = "80/tcp"; > type myrec: record { > cid: conn_id; > }; > event bro_init() > { > local mr: myrec; mr = [$cid = [$orig_h=1.2.3.4,$orig_p=0/tcp,$resp_h=0.0.0.0,$resp_p=crash]]; > get_port_transport_proto(mr$cid$resp_p); > } > {code} > instead it errors out at runtime: fatal error in ././test.bro, line 1: Val::CONVERTER (string/port) (80/tcp) -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 07:47:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 28 Apr 2015 09:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1384: --------------------------- Fix Version/s: 2.4 > Optimize option leads to internal error > --------------------------------------- > > Key: BIT-1384 > URL: https://bro-tracker.atlassian.net/browse/BIT-1384 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vlad Grigorescu > Fix For: 2.4 > > > On a whim, I tried using the optimize option: > > % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > > zsh: abort bro -O -Cr ~/pcaps/sansholidayhack2013.pcap > I'm not sure if I'm not using this right, or what. If it's not used much any more, should we consider removing it? Backtrace follows. > internal error in /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad tag in same_expr() > bq. Program received signal SIGABRT, Aborted. > bq. 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. (gdb) bt > bq. #0 0x00007ffff5eda5e7 in raise () from /lib64/libc.so.6 > bq. #1 0x00007ffff5edb9c8 in abort () from /lib64/libc.so.6 > bq. #2 0x0000000000835dc4 in Reporter::InternalError (this=0x111d6c0, fmt=0xbe3b69 "bad tag in same_expr()") at /home/vladg/src/bro/src/Reporter.cc:150 > bq. #3 0x00000000007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at /home/vladg/src/bro/src/Expr.cc:5984 > bq. #4 0x00000000007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at /home/vladg/src/bro/src/Expr.cc:5911 > bq. #5 0x00000000007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:2036 > bq. #6 0x00000000007e1719 in BinaryExpr::Simplify (this=0x14661e0) at /home/vladg/src/bro/src/Expr.cc:586 > bq. #7 0x00000000007f7a96 in simplify_expr (e=0x14661e0, simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828 > bq. #8 0x000000000089194d in ExprStmt::Simplify (this=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:388 > bq. #9 0x0000000000899831 in simplify_stmt (s=0x1466180) at /home/vladg/src/bro/src/Stmt.cc:2282 > bq. #10 0x00000000008975dc in StmtList::Simplify (this=0x1466540) at /home/vladg/src/bro/src/Stmt.cc:1786 > bq. #11 0x0000000000774d60 in yyparse () at parse.y:1177 > bq. #12 0x000000000078b854 in main (argc=4, argv=0x7fffffffe2d8) at /home/vladg/src/bro/src/main.cc:893 -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 08:38:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 28 Apr 2015 10:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1383) memory leak In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20503#comment-20503 ] Jon Siwek commented on BIT-1383: -------------------------------- >From prof.log, it looks like there's a lot of congestion in the threads responsible for writing out logs. E.g. towards the end: 1430224237.180545 syslog/Log::WRITER_ASCII in=43896 out=98 pending=43534/0 (#queue r/w: in=362/43896 out=98/98) prof.log seems to show that, over time, there's quite a bit of log entries that don't get processed: the "pending" value keeps increasing. i.e. logs are produced at a greater rate than they are consumed. So at least part of the memory usage you see may not truly be a leak, but an accumulation of unprocessed log entries over time. Maybe the logging threads aren't getting enough CPU time or they're bottlenecked on disk I/O. > memory leak > ----------- > > Key: BIT-1383 > URL: https://bro-tracker.atlassian.net/browse/BIT-1383 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 LTS > Reporter: Garanews > Labels: leak, memory > Attachments: log.tar.gz, screenshot-1.png, threads.png > > > BRO is taking almos all resources availables (CPUs and 192GBRAM +50GB Swap) : > top - 12:26:56 up 1 day, 1:40, 2 users, load average: 28.10, 28.69, 27.94 > Tasks: 365 total, 16 running, 349 sleeping, 0 stopped, 0 zombie > Cpu(s): 28.7%us, 18.4%sy, 1.4%ni, 48.3%id, 2.4%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 198059808k total, 197549384k used, 510424k free, 1384k buffers > Swap: 201289980k total, 50575440k used, 150714540k free, 10596k cached > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13551 root 20 0 1341m 880m 517m R 100 0.5 993:31.62 bro > 13596 root 20 0 1173m 882m 517m R 100 0.5 1001:27 bro > 13617 root 20 0 8472m 898m 517m R 100 0.5 990:51.10 bro > 13659 root 20 0 1469m 889m 517m R 100 0.5 990:53.08 bro > 13679 root 20 0 1390m 885m 517m R 100 0.5 981:09.51 bro > 13681 root 20 0 2229m 1.8g 517m R 100 1.0 952:03.55 bro > 13653 root 20 0 2953m 881m 517m R 99 0.5 988:00.31 bro > 13685 root 20 0 1106m 888m 517m R 99 0.5 988:19.98 bro > 13641 root 20 0 1122m 884m 517m R 64 0.5 987:33.61 bro > 13672 root 20 0 10.1g 7.5g 517m R 56 4.0 987:49.47 bro > 13696 root 20 0 1161m 881m 517m R 53 0.5 982:57.39 bro > 13668 root 20 0 1149m 883m 517m S 51 0.5 989:52.19 bro > 13691 root 20 0 1989m 884m 517m R 50 0.5 1012:40 bro > 13692 root 20 0 1190m 885m 517m S 48 0.5 995:16.83 bro > 13677 root 20 0 1188m 889m 517m S 44 0.5 993:21.39 bro > 13687 root 20 0 5340m 2.7g 517m S 43 1.5 978:51.70 bro > 8906 root 25 5 294m 111m 672 S 40 0.1 526:31.84 bro > 6545 root 25 5 1235m 859m 624 S 29 0.4 482:23.79 bro > 4645 root 20 0 198g 160g 1832 S 24 85.0 254:50.36 bro > 8238 root 20 0 1755m 114m 1716 S 19 0.1 129:58.95 bro > 15196 root 25 5 685m 539m 515m S 16 0.3 219:22.30 bro > 15149 root 25 5 678m 535m 515m S 16 0.3 210:17.67 bro > 15166 root 25 5 678m 544m 515m S 16 0.3 208:54.70 bro > 15200 root 25 5 686m 543m 515m S 16 0.3 210:56.13 bro > 15148 root 25 5 678m 546m 515m R 16 0.3 211:22.38 bro > 15186 root 25 5 685m 537m 515m S 16 0.3 208:55.80 bro > 15187 root 25 5 685m 545m 515m R 16 0.3 211:02.48 bro > 15188 root 25 5 685m 536m 515m R 16 0.3 207:31.37 bro > 15197 root 25 5 692m 536m 515m S 16 0.3 208:34.05 bro > 15201 root 25 5 692m 547m 515m S 16 0.3 209:19.18 bro > 15165 root 25 5 685m 543m 515m S 15 0.3 207:28.37 bro > 15147 root 25 5 692m 536m 515m S 15 0.3 210:45.36 bro > 15185 root 25 5 686m 544m 515m S 15 0.3 210:45.12 bro > 15198 root 25 5 678m 546m 515m S 15 0.3 203:51.90 bro > 15150 root 25 5 678m 537m 515m S 15 0.3 207:34.16 bro > 15199 root 25 5 685m 537m 515m S 14 0.3 204:45.21 bro -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From edthoma at sandia.gov Tue Apr 28 11:32:32 2015 From: edthoma at sandia.gov (Thomas, Eric D) Date: Tue, 28 Apr 2015 18:32:32 +0000 Subject: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs In-Reply-To: <20150417155524.GO55440@icir.org> References: <20150417155524.GO55440@icir.org> Message-ID: Hi Robin, I thought more about your generalized idea and would like to follow up. To start, adding link-level features to the connection ID hash, while perhaps useful in some contexts, does not provide us the functionality we desire. I have an incoming feed of VLAN-tagged traffic (both VLAN and 802.1ah) with perhaps dozens of different VLANs, and I would like to handle the connections differently in scripts but also mainly in offline log analysis depending upon which VLANs the traffic is associated with. Initially I had proposed simply adding the VLAN Ids to the conn.log file, but that is certainly too specific of a solution. What are your thoughts on exposing link-level features at the script layer for connections? For example, if all observed VLAN tags for a connection were in a set variable of the script-level Connection record, I could then label my data by matching VLAN Ids, then process them differently accordingly. Thoughts? -- Eric Thomas edthoma at sandia.gov On 4/17/15, 8:55 AM, "Robin Sommer" wrote: >(Cc'ing bro-dev, I suggest we continue the thread there). > >This sounds generally reasonable, however I think we could take the >opportunity here to generalize this a bit more for generally including >link-layer information into connection handling. > >One thing that I didn't quite get form your description is if the >objective is really just to get the VLAN ID into conn.log, or whether >you also want to use it for defining what constitutes a connection in >the first place. The latter would aim at the situations where the same >IP addresses can appear on different VLANs for independent >connections. Right now, Bro can't keep them apart, but if we made the >VLAN part of the connection index into the session table, it would >treat them separately. Same applies to other link-level features that >could sometimes be useful to be a part of a connection's ID (like MAC >addresses). > >With that in mind, some thoughts on generalizing this (note, I not >sureif you're working from 2.3 or git master. The PktSrc API has >changed a bit recently, I'll take git as my starting point). > > - One challenge is passing the the VLAN ID through to the various > packet-related methods. You're suggesting additional parameters, > which would work. However, these methods are already taking a > bunch of parameters, and if in the future we wanted to pass > through further link-layer info, we'd have to add even more. A > more flexible alternative would be switching to simply passing a > Packet structure around that encapsulates all the information, > including what's already there (e.g., timestmap, pcap_hdr, > payload, etc.). The new PktSrc API already has such a class: > PktSrc::Packet; from a quick look I think we could elevate that > to be something passed around more generally, and then extend it > accordingly. > > - For the connections, I would store the VLAN inside the ConnID > struct, and then modify BuildConnIDHashKey() to take it into > account. That way, the session table will make it part of its > index. Same for the script-land conn_id record; that will then > make script-level tables work that index by conn_id. > > - Extending the ConnID like this could actually be made a run-time > option: I believe it shouldn't be too difficult to let users > chose the fields defining a ConnID, so that they can decide if, > say, they want to VLAN to be in there or not. We could predefine > a set of potential features to choose from, along with some > script-land API to pick the set to use, with the current 4-tuple > being the default. (This could be a 2nd step for later; if the > first two points above were in place, this extension should > become mainly a question of finding the right configuration > interface.) > >I haven't thought this thruogh too carefully, so it's conceivable that >I'm missing something. But I think it would be really helpful for many >folks to get more flexibility into the definition of what consitutes a >connection, with VLANs being a good initial target to support. > >Robin > >On Tue, Apr 14, 2015 at 16:59 +0000, you wrote: > >> Dear Bro developers, >> >> I've been tasked with trying to modify the Bro source code so that >> conn.log includes the VLAN IDs (including 802.1ah) that have been >>observed >> in packets associated with that connection. I've scoped out a solution, >> but I want to run it by you first before I start to go for it, in case >>I'm >> missing something really big. >> >> PktSrc::Process() does processing of VLAN and 802.1ah, but it just skips >> over them by advancing the data pointer. I will, in addition, store >>those >> VLAN IDs in a new member of the modified PktSrc class. This gets passed >>on >> through net_packet_dispatch() and NetSessions::DispatchPacket(). At this >> point NetSessions::NextPacket() gets called, but since the PktSrc >>doesn't >> get passed to it, I'd need another way to pass it the VLAN ID. I am >> considering two options: >> >> 1. duplicate NextPacket() adding a new parameter to pass it the VLAN >>IDs, >> and call that instead, or >> 2. store the VLAN IDs in the NetSessions class, in DispatchPacket() so >> it?s available to NextPacket() and DoNextPacket() <- Is there a reason >> this wouldn?t work, e.g. issues with multi-threading/multi-processing? >> >> Is there one option that seems better to you? >> >> NetSessions::DoNextPacket() is called next and I would also need a >> modification to pass it VLAN IDs, using one of the options above. In >>this >> method we finally get access to the appropriate Connection instance, so >>I >> would store the VLAN IDs in that instance in DoNextPacket(). >> >> I'd need to modify the Connection class in Conn.h to include a new >>member >> for tracking VLAN IDs. I'd modify Connection::BuildConnVal() and >> scripts/base/init-bare.bro's connection record to make the VLAN IDs >> available to scripts. Lastly, I'd write a script to redef the conn Info >> structure and handle one or more connection events (perhaps >> connection_state_remove) to copy the VLAN IDs from the connection record >> to the Info record. >> >> Is there anything I'm missing? Is there a better way to approach this? >> > > > >-- >Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From jira at bro-tracker.atlassian.net Tue Apr 28 21:44:00 2015 From: jira at bro-tracker.atlassian.net (Josh Liburdi (JIRA)) Date: Tue, 28 Apr 2015 23:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1390) Orphaned field addl In-Reply-To: References: Message-ID: Josh Liburdi created BIT-1390: --------------------------------- Summary: Orphaned field addl Key: BIT-1390 URL: https://bro-tracker.atlassian.net/browse/BIT-1390 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Environment: I'm running master (current as of 04/21/2015) in a cluster environment and am receiving thousands of these reporter.log errors each minute: orphan field "addl" in initialization ([uid=ColGFv4htljLxPq9yg, id=[orig_h=, orig_p=/udp, resp_h=, resp_p=/udp], history=Dd, duration=0.03419, start_time=0, addl=, hot=0]) I've masked the actual connection data (addrs and ports), but the error is the same across multiple Bro deployment-- all involve orphan field "addl". Reporter: Josh Liburdi -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 21:50:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 28 Apr 2015 23:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1391) topic/seth/sip-fixes In-Reply-To: References: Message-ID: Seth Hall created BIT-1391: ------------------------------ Summary: topic/seth/sip-fixes Key: BIT-1391 URL: https://bro-tracker.atlassian.net/browse/BIT-1391 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.4 Reporter: Seth Hall The branch topic/seth/sip-fixes fixes some issues in the sip analyzer's scripts that were causing over logging in some cases and in other cases didn't log valuable information. It also corrects some null field access issues that had shown up on some networks. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 21:51:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 28 Apr 2015 23:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1391) topic/seth/sip-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1391: --------------------------- Status: Merge Request (was: Open) > topic/seth/sip-fixes > -------------------- > > Key: BIT-1391 > URL: https://bro-tracker.atlassian.net/browse/BIT-1391 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > > The branch topic/seth/sip-fixes fixes some issues in the sip analyzer's scripts that were causing over logging in some cases and in other cases didn't log valuable information. > It also corrects some null field access issues that had shown up on some networks. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From robin at icir.org Tue Apr 28 21:56:37 2015 From: robin at icir.org (Robin Sommer) Date: Tue, 28 Apr 2015 21:56:37 -0700 Subject: [Bro-Dev] [JIRA] (BIT-1390) Orphaned field addl In-Reply-To: References: Message-ID: <20150429045637.GV5910@icir.org> The "addl" and "hot" fields have been removed from the connection record recently. From a quick look I don't see them being used in the standard scripts anymore. Is it possible that you have a custom script creating that record? On Tue, Apr 28, 2015 at 23:44 -0500, you wrote: > Josh Liburdi created BIT-1390: > --------------------------------- > > Summary: Orphaned field addl > Key: BIT-1390 > URL: https://bro-tracker.atlassian.net/browse/BIT-1390 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: I'm running master (current as of 04/21/2015) in a cluster environment and am receiving thousands of these reporter.log errors each minute: > > orphan field "addl" in initialization ([uid=ColGFv4htljLxPq9yg, id=[orig_h=, orig_p=/udp, resp_h=, resp_p=/udp], history=Dd, duration=0.03419, start_time=0, addl=, hot=0]) > > I've masked the actual connection data (addrs and ports), but the error is the same across multiple Bro deployment From jira at bro-tracker.atlassian.net Tue Apr 28 21:58:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 28 Apr 2015 23:58:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1390) Orphaned field addl In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1390: ------------------------------ The "addl" and "hot" fields have been removed from the connection record recently. From a quick look I don't see them being used in the standard scripts anymore. Is it possible that you have a custom script creating that record? > Orphaned field addl > ------------------- > > Key: BIT-1390 > URL: https://bro-tracker.atlassian.net/browse/BIT-1390 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: I'm running master (current as of 04/21/2015) in a cluster environment and am receiving thousands of these reporter.log errors each minute: > orphan field "addl" in initialization ([uid=ColGFv4htljLxPq9yg, id=[orig_h=, orig_p=/udp, resp_h=, resp_p=/udp], history=Dd, duration=0.03419, start_time=0, addl=, hot=0]) > I've masked the actual connection data (addrs and ports), but the error is the same across multiple Bro deployment-- all involve orphan field "addl". > Reporter: Josh Liburdi > -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 22:03:00 2015 From: jira at bro-tracker.atlassian.net (Josh Liburdi (JIRA)) Date: Wed, 29 Apr 2015 00:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1390) Orphaned field addl In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20505#comment-20505 ] Josh Liburdi commented on BIT-1390: ----------------------------------- Ah, you're right! It's a custom script causing this. Thanks Robin. > Orphaned field addl > ------------------- > > Key: BIT-1390 > URL: https://bro-tracker.atlassian.net/browse/BIT-1390 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: I'm running master (current as of 04/21/2015) in a cluster environment and am receiving thousands of these reporter.log errors each minute: > orphan field "addl" in initialization ([uid=ColGFv4htljLxPq9yg, id=[orig_h=, orig_p=/udp, resp_h=, resp_p=/udp], history=Dd, duration=0.03419, start_time=0, addl=, hot=0]) > I've masked the actual connection data (addrs and ports), but the error is the same across multiple Bro deployment-- all involve orphan field "addl". > Reporter: Josh Liburdi > -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Tue Apr 28 22:04:00 2015 From: jira at bro-tracker.atlassian.net (Josh Liburdi (JIRA)) Date: Wed, 29 Apr 2015 00:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1390) Orphaned field addl In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Liburdi updated BIT-1390: ------------------------------ Resolution: Solved Status: Closed (was: Open) Custom script error from the removed field "addl". > Orphaned field addl > ------------------- > > Key: BIT-1390 > URL: https://bro-tracker.atlassian.net/browse/BIT-1390 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Environment: I'm running master (current as of 04/21/2015) in a cluster environment and am receiving thousands of these reporter.log errors each minute: > orphan field "addl" in initialization ([uid=ColGFv4htljLxPq9yg, id=[orig_h=, orig_p=/udp, resp_h=, resp_p=/udp], history=Dd, duration=0.03419, start_time=0, addl=, hot=0]) > I've masked the actual connection data (addrs and ports), but the error is the same across multiple Bro deployment-- all involve orphan field "addl". > Reporter: Josh Liburdi > -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Wed Apr 29 00:00:32 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 29 Apr 2015 00:00:32 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504290700.t3T70WSO004694@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- ------------------------ BIT-1391 [1] Bro Seth Hall - 2015-04-28 - Normal topic/seth/sip-fixes [2] Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ------------------------------------------------------ 1508b00 [3] bro Daniel Thayer 2015-04-28 Update NEWS and code for removal of -O cmd-line option [1] BIT-1391 https://bro-tracker.atlassian.net/browse/BIT-1391 [2] sip-fixes https://github.com/bro/bro/tree/topic/seth/sip-fixes [3] 1508b00 https://github.com/bro/bro/commit/1508b004897d5451025953d767d2c5ce3c755669 From jira at bro-tracker.atlassian.net Wed Apr 29 04:00:02 2015 From: jira at bro-tracker.atlassian.net (yun (JIRA)) Date: Wed, 29 Apr 2015 06:00:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1314) Detect "quantum insert" type of attacks In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20507#comment-20507 ] yun commented on BIT-1314: -------------------------- A patch that fixes rexmit_inconsistency for QI can be found here: https://github.com/fox-it/quantuminsert/blob/master/detection/bro/rexmit_inconsistency-bro-2.3.2.patch > Detect "quantum insert" type of attacks > --------------------------------------- > > Key: BIT-1314 > URL: https://bro-tracker.atlassian.net/browse/BIT-1314 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: David Andr? > > Add detection for "quantum insert" type of attacks. Since the leaked information is classified, I will try to explain in unclassified form what it is about. > The idea is that you have a passive adversary that sniff your TCP sequence numbers and inject its malicious payload faster than the real server. > One of the leaked documents mentions as an alerting mechanism to detect duplicate TCP sequence numbers from same source, where at least 10% of the beginning of the content of the two packets differs. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Wed Apr 29 07:22:00 2015 From: jira at bro-tracker.atlassian.net (Larry Leviton (JIRA)) Date: Wed, 29 Apr 2015 09:22:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1253) Bro 2.3 - 2.3.1 manager dieing on Bivio hardware In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry Leviton updated BIT-1253: ------------------------------- I apologize for not getting back to you sooner, but due to some contractual issues and other problems, I wasn't able to get back to this till now. The probably appears fixed in 2.3.2. Thanks so much for fixing it. On Tue, Mar 17, 2015 at 4:40 PM, Jon Siwek (JIRA) < > Bro 2.3 - 2.3.1 manager dieing on Bivio hardware > ------------------------------------------------ > > Key: BIT-1253 > URL: https://bro-tracker.atlassian.net/browse/BIT-1253 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Bro 2.3 and Bro 2.3.1 > bivio hardwareLinux CPU.2.6.31-45 has curl 7.36 gperftools 2.2 flex 2.5.39 bison 3.0.2 libpcap 1.1 swig 2.0.8 > Reporter: Larry Leviton > Assignee: Johanna Amann > Fix For: 2.4 > > > After starting bro up, the bro manager crashes in less than 60 seconds. > Thanks for any help you can give. > Sent stack trace to vendor (at bottom), and here was their response: > Comment(s): Hello Larry, > We have duplicated a crash in our lab setup that seems to be identical to that experienced by you. The code has changed quite a bit from 2.1 to 2.3.1, and we suspect a bug was introduced. > What is going on, seems to be that a writer thread is being terminated, and the destructor for the Ascii writer is called eventually. However, the destructor code does some checks and finds out that proper cleanup has not been done, so it aborts. This does not seem to be due to any library incompatibility, and looks more like maybe a race condition was introduced. > Since you knows the Bro developers, can you please ask them to take a look this and get back to us? We think it requires their expertise at this point. > Thank You, > Hassan. > > Bivio Case Information: > Bivio Case #: 4566243 > Date Created: 9/02/2014 08:02 AM PDT > Stack trace below: > GNU gdb (GDB) Fedora (6.8.50.20090302-40.fc11) Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "ppc-redhat-linux-gnu". > For bug reporting instructions, please see: > ... > backtrace > [New Thread 25501] > [New Thread 25328] > [New Thread 25378] > [New Thread 25379] > [New Thread 25380] > [New Thread 25381] > [New Thread 25382] > [New Thread 25383] > [New Thread 25384] > [New Thread 25385] > [New Thread 25386] > [New Thread 25389] > [New Thread 25442] > warning: Can't read pathname for load map: Input/output error. > Missing separate debuginfo for /usr/local/lib/libz.so.1 > Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a2/0a0d1fc0d48c2a303af1417ccc03308b9de04a > Missing separate debuginfo for /usr/local/lib/libtcmalloc.so.4 > Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/27/eaf56bc64810920d55b9530156c1e8ffbfd43e > Missing separate debuginfo for /usr/local/lib/libcurl.so.4 > Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a7/9a2cebb4abc156495ec0806b1c18015c8eba01 > Reading symbols from /usr/lib/libpcap.so.1...done. > Loaded symbols for /usr/lib/libpcap.so.1 Reading symbols from /usr/lib/libssl.so.10...done. > Loaded symbols for /usr/lib/libssl.so.10 Reading symbols from /usr/lib/libcrypto.so.10...done. > Loaded symbols for /usr/lib/libcrypto.so.10 Reading symbols from /usr/lib/libbind.so.4...done. > Loaded symbols for /usr/lib/libbind.so.4 Reading symbols from /usr/local/lib/libz.so.1...done. > Loaded symbols for /usr/local/lib/libz.so.1 Reading symbols from /usr/local/lib/libtcmalloc.so.4...done. > Loaded symbols for /usr/local/lib/libtcmalloc.so.4 Reading symbols from /usr/local/lib/libcurl.so.4...done. > Loaded symbols for /usr/local/lib/libcurl.so.4 Reading symbols from /lib/libpthread.so.0...done. > Loaded symbols for /lib/libpthread.so.0 > Reading symbols from /lib/libdl.so.2...done. > Loaded symbols for /lib/libdl.so.2 > Reading symbols from /usr/lib/libstdc++.so.6...done. > Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. > Loaded symbols for /lib/libm.so.6 > Reading symbols from /lib/libgcc_s.so.1...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /usr/lib/libzcp.so...done. > Loaded symbols for /usr/lib/libzcp.so > Reading symbols from /lib/libgssapi_krb5.so.2...done. > Loaded symbols for /lib/libgssapi_krb5.so.2 Reading symbols from /lib/libkrb5.so.3...done. > Loaded symbols for /lib/libkrb5.so.3 > Reading symbols from /lib/libcom_err.so.2...done. > Loaded symbols for /lib/libcom_err.so.2 > Reading symbols from /lib/libk5crypto.so.3...done. > Loaded symbols for /lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...done. > Loaded symbols for /lib/libresolv.so.2 > Reading symbols from /lib/librt.so.1...done. > Loaded symbols for /lib/librt.so.1 > Reading symbols from /lib/ld.so.1...done. > Loaded symbols for /lib/ld.so.1 > Reading symbols from /lib/libbvsp.so...done. > Loaded symbols for /lib/libbvsp.so > Reading symbols from /lib/libbcon.so...done. > Loaded symbols for /lib/libbcon.so > Reading symbols from /lib/libkrb5support.so.0...done. > Loaded symbols for /lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. > Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /usr/lib/libxml2.so.2...done. > Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/libhmlibs.so...done. > Loaded symbols for /lib/libhmlibs.so > Reading symbols from /lib/libhmolddb.so...done. > Loaded symbols for /lib/libhmolddb.so > Reading symbols from /lib/libcf.so...done. > Loaded symbols for /lib/libcf.so > Reading symbols from /lib/libbvsep.so...done. > Loaded symbols for /lib/libbvsep.so > Reading symbols from /usr/lib/libnrddi.so...done. > Loaded symbols for /usr/lib/libnrddi.so > Reading symbols from /lib/libselinux.so.1...done. > Loaded symbols for /lib/libselinux.so.1 > Core was generated by `/var/tmp/bro/spool/tmp/bro -U .status -p broctl -p broctl-live -p local -p mana'. > Program terminated with signal 6, Aborted. > #0 0x0f6cf01c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > in ../nptl/sysdeps/unix/sysv/linux/raise.c > Missing separate debuginfos, use: debuginfo-install e2fsprogs-libs-1.41.9-2.fc11.ppc glibc-2.17-4.fc11.ppc keyutils-libs-1.2-5.fc11.ppc krb5-libs-1.9.3-1.fc11.ppc libbind-6.0-1.fc11.ppc libgcc-4.4.1-2.fc11.ppc libselinux-2.0.80-1.fc11.ppc libstdc++-4.4.1-2.fc11.ppc libxml2-2.7.6-1.fc11.ppc openssl-libs-1.0.1e-37.fc11.1.ppc > (gdb) backtrace > #0 0x0f6cf01c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x0f6d0de0 in *__GI_abort () at abort.c:90 > #2 0x1024be70 in logging::writer::Ascii::~Ascii (this=0x11a87200, __in_chrg=) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/logging/writers/Ascii.cc:186 > #3 0x10236b70 in threading::Manager::Process (this=0x10dae180) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/threading/Manager.cc:171 > #4 0x101a5400 in net_run () at /bivio/scsi/b/levitonl/bro-2.3.1/src/Net.cc:389 > #5 0x100f7554 in main (argc=, argv=) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/main.cc:1165 > Current language: auto; currently minimal > (gdb) > #0 0x0f6cf01c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x0f6d0de0 in *__GI_abort () at abort.c:90 > #2 0x1024be70 in logging::writer::Ascii::~Ascii (this=0x11a87200, __in_chrg=) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/logging/writers/Ascii.cc:186 > #3 0x10236b70 in threading::Manager::Process (this=0x10dae180) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/threading/Manager.cc:171 > #4 0x101a5400 in net_run () at /bivio/scsi/b/levitonl/bro-2.3.1/src/Net.cc:389 > #5 0x100f7554 in main (argc=, argv=) > at /bivio/scsi/b/levitonl/bro-2.3.1/src/main.cc:1165 > (gdb) quit -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From robin at broala.com Wed Apr 29 16:59:07 2015 From: robin at broala.com (Robin Sommer) Date: Wed, 29 Apr 2015 16:59:07 -0700 Subject: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs In-Reply-To: References: <20150417155524.GO55440@icir.org> Message-ID: <20150429235907.GH10338@icir.org> What if we did a combination of what I suggested and your thoughts here? We carry link-level features through to script-land inside the connection record, and in addition allowed to transfer a custom subset over to the connection ID for hashing? The latter could be done later as a second step. Robin On Tue, Apr 28, 2015 at 18:32 +0000, you wrote: > Hi Robin, > > I thought more about your generalized idea and would like to follow up. To > start, adding link-level features to the connection ID hash, while perhaps > useful in some contexts, does not provide us the functionality we desire. > I have an incoming feed of VLAN-tagged traffic (both VLAN and 802.1ah) > with perhaps dozens of different VLANs, and I would like to handle the > connections differently in scripts but also mainly in offline log analysis > depending upon which VLANs the traffic is associated with. > > Initially I had proposed simply adding the VLAN Ids to the conn.log file, > but that is certainly too specific of a solution. What are your thoughts > on exposing link-level features at the script layer for connections? For > example, if all observed VLAN tags for a connection were in a set variable > of the script-level Connection record, I could then label my data by > matching VLAN Ids, then process them differently accordingly. Thoughts? > -- Robin Sommer * Broala, LLC * robin at broala.com * www.broala.com From jira at bro-tracker.atlassian.net Wed Apr 29 20:36:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 29 Apr 2015 22:36:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1391) topic/seth/sip-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1391: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > topic/seth/sip-fixes > -------------------- > > Key: BIT-1391 > URL: https://bro-tracker.atlassian.net/browse/BIT-1391 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > > The branch topic/seth/sip-fixes fixes some issues in the sip analyzer's scripts that were causing over logging in some cases and in other cases didn't log valuable information. > It also corrects some null field access issues that had shown up on some networks. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From noreply at bro.org Thu Apr 30 00:00:33 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 30 Apr 2015 00:00:33 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201504300700.t3U70X02002706@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ------------------------------------------------------------ 26007f4 [1] bro Daniel Thayer 2015-04-29 Update usage output and list of cmd-line options cb91a9c [2] bro Vlad Grigorescu 2015-04-29 A small fix to ssh/geo-data.bro. ssh can now be unset for lo [1] 26007f4 https://github.com/bro/bro/commit/26007f419ee51160717588f34ca7930f831a3761 [2] cb91a9c https://github.com/bro/bro/commit/cb91a9c10157f8fc01397f5f638595e35231e283 From jira at bro-tracker.atlassian.net Thu Apr 30 10:57:00 2015 From: jira at bro-tracker.atlassian.net (jiamo (JIRA)) Date: Thu, 30 Apr 2015 12:57:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1317) Integrate standard plugin into Bro's build and install process In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20509#comment-20509 ] jiamo commented on BIT-1317: ---------------------------- Hi, after I build a base one I want build plugin, but goto the aux/plugins and make get error: make -C dataseries make[1]: Entering directory '/home/ikfb/Git/bro/aux/plugins/dataseries' Build Directory : build Bro Source Directory : /home/ikfb/Git/bro -- Bro executable : /home/ikfb/Git/bro/build/src/bro -- Bro source : /home/ikfb/Git/bro -- Bro build : /home/ikfb/Git/bro/build -- Bro install prefix : /usr/local/bro -- Bro plugin directory: /usr/local/bro/lib/bro/plugins -- Bro debug mode : false -- Could NOT find Lintel (missing: Lintel_LIBRARIES Lintel_INCLUDE_DIR) -- Could NOT find DataSeries (missing: DataSeries_LIBRARIES DataSeries_INCLUDE_DIR) CMake Error at CMakeLists.txt:32 (message): DataSeries not found. Do we have a docement how to build extern plugins and install them now? > Integrate standard plugin into Bro's build and install process > -------------------------------------------------------------- > > Key: BIT-1317 > URL: https://bro-tracker.atlassian.net/browse/BIT-1317 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Robin Sommer > Fix For: 2.5 > > > Right now, plugins in aux/plugins/* need to be build and installed manually. That's fine for those currently there (netmap, elastic search, data series), as they are quite specific. However, once we start moving more standard functionality over into plugins (say, GeoIP support), that will get more cumbersome, as now everybody wanting that stuff will need to do the additional step, which is easy to miss. > However, it's not clear to me right now what's a good way of integrating the plugins more tightly would be. We could turn a few (or all?) on by default and build them along with Bro if their dependencies are satisfied. But that's tough to implement, as the plugin build process is really completely separate from Bro's. So we would need to pass configure parameters over, run their builds, run their installs, run their tests, and catch any errors along the way. > I'm setting this to 2.4 in case we can still come up with a good strategy here. But more likely this is something to punt on right now, as we don't have a pressing use case anyways. There's also the related topic of a broader notion of modules that a future CPAN might manage, and how we combine all that. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000) From jira at bro-tracker.atlassian.net Thu Apr 30 22:59:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 1 May 2015 00:59:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1317) Integrate standard plugin into Bro's build and install process In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20510#comment-20510 ] Seth Hall commented on BIT-1317: -------------------------------- The Dataseries plugin depends on Dataseries being installed and you don't seem to have it installed. Try building a plugin that doesn't require any third party libraries. I have a simple plugin that doesn't have any third party dependencies here: https://github.com/sethhall/bro-approxidate > Integrate standard plugin into Bro's build and install process > -------------------------------------------------------------- > > Key: BIT-1317 > URL: https://bro-tracker.atlassian.net/browse/BIT-1317 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Robin Sommer > Fix For: 2.5 > > > Right now, plugins in aux/plugins/* need to be build and installed manually. That's fine for those currently there (netmap, elastic search, data series), as they are quite specific. However, once we start moving more standard functionality over into plugins (say, GeoIP support), that will get more cumbersome, as now everybody wanting that stuff will need to do the additional step, which is easy to miss. > However, it's not clear to me right now what's a good way of integrating the plugins more tightly would be. We could turn a few (or all?) on by default and build them along with Bro if their dependencies are satisfied. But that's tough to implement, as the plugin build process is really completely separate from Bro's. So we would need to pass configure parameters over, run their builds, run their installs, run their tests, and catch any errors along the way. > I'm setting this to 2.4 in case we can still come up with a good strategy here. But more likely this is something to punt on right now, as we don't have a pressing use case anyways. There's also the related topic of a broader notion of modules that a future CPAN might manage, and how we combine all that. -- This message was sent by Atlassian JIRA (v6.5-OD-01-120#65000)