Hello,
When rolling a Gentoo ebuild for 2.1, I ran into a parse error
in the auto-generated build/cmake_install.cmake file, due to
insufficient quoting (so empty strings disappeared from the argument
list in an if() statement).
Sorry if this is a known issue and/or only occurs because of some
peculiarity of my build environment.
The below patch, applied between compilation and installation, fixes it.
But it's not the right fix--I did not trace backward to the creation of
the build/cmake_install.cmake file and fix that.
--- build/cmake_install.cmake.orig 2012-09-30 18:49:31.669030129 -0400
+++ build/cmake_install.cmake 2012-09-30 18:49:07.145028834 -0400
@@ -34,7 +34,7 @@
IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
- if (NOT STREQUAL $ENV{USER} AND NOT $ENV{USER} STREQUAL root)
+ if (NOT "" STREQUAL "$ENV{USER}" AND NOT "$ENV{USER}" STREQUAL root)
message(STATUS "WARNING: Install is being performed by user "
"'$ENV{USER}', but the build directory was configured by "
"user ''. This may result in a permissions error "
When rolling a Gentoo ebuild for 2.1, I ran into a parse error
in the auto-generated build/cmake_install.cmake file, due to
insufficient quoting (so empty strings disappeared from the argument
list in an if() statement).
Thanks, Hank. The odd thing in your environment looks like the USER variable isn't set, but I've fixed the string quoting in cmake/UserChangedWarning.cmake (pending a git merge) so an error won't occur even in that case.
Jon
I don't think TEREDO is working correctly. It is filling up the known_services.log with entries for local host ports that I know are closed just because there was a TEREDO packet sent to that port.
I don't think TEREDO is working correctly. It is filling up the known_services.log with entries for local host ports that I know are closed just because there was a TEREDO packet sent to that port.
It's not so much Teredo working incorrectly as it is the combination of how it works with the way known-services.bro decides something is a service, which could be improved.
I've created a ticket to track the issue: http://tracker.bro-ids.org/bro/ticket/890
Jon
I’ve been looking at known-services.bro for other reasons, and found the following line:
(“DNS” in c$service && c$resp$size == 0) ) # for dns, require that the server talks.
I’m a bit surprised that only DNS requires that both sides of the conversation talk - I would expect that in the case of UDP protocols especially one would want to see both sides of the conversation.
DNS is the only UDP service that is included in known-services.log right now. For example, since we only support UDP Syslog at the moment and syslog servers never send any data and can't be confirmed it's not included.
I suspect this is another area where we could improve the semantics of ProtocolViolation and ProtocolConfirmation because the DNS protocol is confirmed for a single parsed DNS message so it calls the ProtocolConfirmation method for the request and the response which is pretty vague as a confirmation.
I believe that most of the TCP analyzers require some amount of conversation back and forth between the server and client prior to confirming the protocol.
.Seth