Highlighted
Knowledge Partner
Knowledge Partner
512 views

Parsing failed errors sine 7.4 update or collector update.

Hi.

Just recently updated a Sentinel Appliance from 7.3.2 to 7.4, and while
at it, also updated the Symantec Collector to the recent one (2011.1r3)

Exatly since then, I occasionally receive internal parsing failed errors
on this collector:

Parsing failed: TypeError: Cannot call method "toLowerCase" of
undefined; original message: Mar 02 16:25:01 SymantecServer srvsep01:
Scan-ID: 1456871554,Start: 2016-03-02 15:19:03,Ende: ,Gestartet,Dauer
(Sekunden): 0,Benutzer1: nsellin,Benutzer2: ,'Scan mit alle Laufwerke
und alle Erweiterungen begonnen',,Befehl: Kein Befehls-Scan
(),Bedrohungen: 0,Infiziert: 0,Gesamtanzahl Dateien: 0,Ãœbergangen:
0,Computer: NB02025,IP-Adresse: 192.168.2.240,Domäne: Standard,Gruppe:
Meine Firma\Standardgruppe,Server: srvsep01

As this is a javascript error, I assume a bug in the collector?

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Parsing failed errors sine 7.4 update or collector update.

On 03/02/2016 09:57 AM, Massimo Rosen wrote:
> Hi.
>
> Just recently updated a Sentinel Appliance from 7.3.2 to 7.4, and while at
> it, also updated the Symantec Collector to the recent one (2011.1r3)
>
> Exatly since then, I occasionally receive internal parsing failed errors
> on this collector:
>
> Parsing failed: TypeError: Cannot call method "toLowerCase" of undefined;
> original message: Mar 02 16:25:01 SymantecServer srvsep01: Scan-ID:
> 1456871554,Start: 2016-03-02 15:19:03,Ende: ,Gestartet,Dauer (Sekunden):
> 0,Benutzer1: nsellin,Benutzer2: ,'Scan mit alle Laufwerke und alle
> Erweiterungen begonnen',,Befehl: Kein Befehls-Scan (),Bedrohungen:
> 0,Infiziert: 0,Gesamtanzahl Dateien: 0,Ãœbergangen: 0,Computer:
> NB02025,IP-Adresse: 192.168.2.240,Domäne: Standard,Gruppe: Meine
> Firma\Standardgruppe,Server: srvsep01
>
> As this is a javascript error, I assume a bug in the collector?
>
> CU,


I would think so, yes. Something in the collector is trying to force some
value to lower-case, and in this particular case the value on which that
method is being called is undefined, perhaps because earlier parsing of
the original string, or something like that, returned a null, or some
branch of logic was not hit leaving a variable unset when it is expected
to be set.

The good news is that troubleshooting these is usually nice and easy
assuming you can get the event that causes the issue. A connector dump
will let you write the events to a file, and then you can replay those
through a test environment's collector with the File connector using a
replay/connector-dump mode pointing to your connector dump file. Of
course, the simpler the connector dump that you replay (preferably having
just the one problem event, maybe repeated a few hundred times to test
over and over) the better for you. If you do not know which event is the
problem, but you know/believe it is in the connector dump, setting a
breakpoint in the section of the collector that handles exceptions and
then looking for that event in the debugger may get you to your error
event quickly, and then you can pull it out to its own file a couple
hundred times for deeper analysis. The goal is to NOT have to work
through valid events to troubleshoot the one problem child.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parsing failed errors sine 7.4 update or collector update.

Aaron,

I'm pretty sure I can find the even causing this, but the rest is way
out of my scope.

CU,
Massimo

Am 02.03.2016 um 18:43 schrieb ab:
> On 03/02/2016 09:57 AM, Massimo Rosen wrote:
>> Hi.
>>
>> Just recently updated a Sentinel Appliance from 7.3.2 to 7.4, and while at
>> it, also updated the Symantec Collector to the recent one (2011.1r3)
>>
>> Exatly since then, I occasionally receive internal parsing failed errors
>> on this collector:
>>
>> Parsing failed: TypeError: Cannot call method "toLowerCase" of undefined;
>> original message: Mar 02 16:25:01 SymantecServer srvsep01: Scan-ID:
>> 1456871554,Start: 2016-03-02 15:19:03,Ende: ,Gestartet,Dauer (Sekunden):
>> 0,Benutzer1: nsellin,Benutzer2: ,'Scan mit alle Laufwerke und alle
>> Erweiterungen begonnen',,Befehl: Kein Befehls-Scan (),Bedrohungen:
>> 0,Infiziert: 0,Gesamtanzahl Dateien: 0,Ãœbergangen: 0,Computer:
>> NB02025,IP-Adresse: 192.168.2.240,Domäne: Standard,Gruppe: Meine
>> Firma\Standardgruppe,Server: srvsep01
>>
>> As this is a javascript error, I assume a bug in the collector?
>>
>> CU,

>
> I would think so, yes. Something in the collector is trying to force some
> value to lower-case, and in this particular case the value on which that
> method is being called is undefined, perhaps because earlier parsing of
> the original string, or something like that, returned a null, or some
> branch of logic was not hit leaving a variable unset when it is expected
> to be set.
>
> The good news is that troubleshooting these is usually nice and easy
> assuming you can get the event that causes the issue. A connector dump
> will let you write the events to a file, and then you can replay those
> through a test environment's collector with the File connector using a
> replay/connector-dump mode pointing to your connector dump file. Of
> course, the simpler the connector dump that you replay (preferably having
> just the one problem event, maybe repeated a few hundred times to test
> over and over) the better for you. If you do not know which event is the
> problem, but you know/believe it is in the connector dump, setting a
> breakpoint in the section of the collector that handles exceptions and
> then looking for that event in the debugger may get you to your error
> event quickly, and then you can pull it out to its own file a couple
> hundred times for deeper analysis. The goal is to NOT have to work
> through valid events to troubleshoot the one problem child.
>



--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parsing failed errors sine 7.4 update or collector update.

Hi.

Am 02.03.2016 um 18:43 schrieb ab:
>
> I would think so, yes. Something in the collector is trying to force some
> value to lower-case, and in this particular case the value on which that
> method is being called is undefined,


Proper analysis. The value it attempts to force to lowercase is (what
the collector believes to be) the hostname of the observer (that it
attempt tolowercase it is a change I disagree with that was introduced
in the latest version of the collector as result of bug 940482, which I
fail to understand why it was implemented, the hostname should stay as
it comes in, there is no proper reason why it should be lowercased
except apparently some weird personal preference of some big customer),

which in return the Symantec Collector has *severe* issues with to
properly determine (via syslog), despite it being really easy, as it's
absolutely static.

The Observer Hostname is *always*, without any exception, in every
single incoming message from Symantec,

"SymantecServer <Hostname>:" e.g "SymantecServer MYSYMANTECBOX:"

Aka, it should be truly trivial to properly set the Observer Hostname to
"MYSYMANTECBOX", as that field is always the same.

*But*, every so often, depending on the remainder of the Messages
delivered to it, the Collector fails to do that, and instead fills the
hostname either with e.g the name of a Workstation that delivered a log
to the Symantec server

(Message: SymantecServer MYSYMANTECHOSTNAME: WSNAME,...." where it gets
incorrectly set to "WSNAME",

Or even worse in this case:

"SymantecServer MYSYMANTECBOX: Scan-Id: 1457078168,Start: ..."

these go unparsed entirely,IMHO because the Collector fails to determine
the hostname (note the format of the field containing the hostname has
never ever changed), and then in the end trips over the "toLowerCase"
function (which per above IMHO shouldn't even be there in the first place).

The whole set of isues with the Symantec Collector currently all start
with the Collector not consistently and properly determining

1. The fact an Observer belongs under the Sysmantec Collector in the
first place (put it under Universal Event instead)

and

2. Still isn't able to handle the Hostname of the Observer properly and
constantly, despite both of it being comparably trivial, as it's totally
static. All that's needed is to strip off the leading "SymantecServer "
from it. What's left then is the proper hostname. And you can also be
100% certain that if a messages come in where this field contains
"SymantecServer "followed by some other string and a colon", that it's,
well, a Symantec Server, and it belogs under the Symantec Collector, and
that other string minus the colon is the Observers Name.

Instead, the UniqueMatchingRule for this Collector is some IMHO
unnecessarily complex Regex monster that's obviously prone to failure:


(Local\:.*Local\:|Site\:.*Server\:|Scan ID\:|Computer
name\:.*Source\:|\,Category\:.*\,.*\,)

Instead, all that would be needed for it to work 100% reliably *and*
independant of the locale of the server (the rest above is not, those
are localized in Symantec), AFAICS is to simply check for
"SymantecServer " 😕


CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parsing failed errors sine 7.4 update or collector update.

Hi.

In case anybody is still following me... 😉

Am 17.03.2016 um 13:29 schrieb Massimo Rosen:
> 1. The fact an Observer belongs under the Sysmantec Collector in the
> first place (put it under Universal Event instead)


This is a localization issue, that's fixed rather easy. The
UniqueMatchingRule of the Symantec Syslog Collector checks for a whole
boatload of (english only) strings in the Symantec Messages. I don't
understand why it doesn't simply check for SymantecServer (like e.g the
ESXi collector check for vmkernel or hosts), but that's how it is.

> and
>
> 2. Still isn't able to handle the Hostname of the Observer properly


That is IMHO still an issue in the Symantec Collector (via Syslog Map
only) as described in my previous message.

Bug 953882 is/was supposed to fix this, but apparently fails to do so.

Symantec messgeas from Syslog all in the first fiel contain
"SymantecServer HOSTNAME", but ever so often the collector puts
SymantecServer as the observer, and "HOSTNAME" as the event name.

I'm trying to find out what's wrong with the code, but fail so far. It's
this part of release.js:

<code>

if (this.CONNECTION_METHOD == "SYSLOG" && this.CONNECTION_MODE == "map") {
e.ReporterIP = this.s_SyslogRelayIp;
if (/SymantecServer\s+(\w+)\:/.test(this.s_raw_message2)) {
this.observer = (RegExp.$1).parseHost();
}
/*
* this.observer = this.s_MessageOriginatorHost.parseHost(); if
* (this.s_HostName) { this.observer = this.s_HostName.parseHost(); }
*/
e.ObserverServiceComponent = instance.MAPS.syslogFac
.lookup(this.i_syslog_facility);

</code>

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parsing failed errors sine 7.4 update or collector update.

FWIW, I opened a SR on this.

Am 02.03.2016 um 17:57 schrieb Massimo Rosen:
> Hi.
>
> Just recently updated a Sentinel Appliance from 7.3.2 to 7.4, and while
> at it, also updated the Symantec Collector to the recent one (2011.1r3)


CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.