New installation of Bro crashes and core dumps with error indicating ssh/binpac

Description

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:arse(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] >

Environment

Debian wheezy, Dell 1750 (dual 32-bit Xeon dual-core cpus), capturing on one 100 meg mirrored switch port

Activity

Show:
Ted Llewellyn
April 1, 2015, 12:01 AM

Never mind, I got it. I'm rebuilding now.

Ted

Ted Llewellyn
April 1, 2015, 1:08 AM

I have rebuilt with Jon's patch for binpac and it's running. Other than not crashing is there anything about the install I should check or output I could send in?

Ted

Jon Siwek
April 1, 2015, 2:46 PM

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).

Ted Llewellyn
April 1, 2015, 5:07 PM

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

Ted Llewellyn
April 6, 2015, 11:03 AM

Still running since Wednesday evening (Eastern) with the patch. This appears to be fixed. Thanks, Jon!

Assignee

Robin Sommer

Reporter

Ted Llewellyn

Labels

External issue ID

None

Components

Fix versions

Affects versions

Priority

Normal
Configure