Unable to see the plugin compiled in the custom wireshark run? - wireshark-dissector

I am following the foo example given in the wireshark documentation.
I am able to build the foo code plugin. I am using wireshark 3.0.1 version. In the workroot folder, I have updated the target - PLUGIN_SRC_DIRS - plugins/epan/foo just before gryphon.
I can see that my code builds because I got some compilation error which I was able to fix it.
My foo code lives inside the plugins/epan folder.
I am running custom wireshark - sudo ./run/wireshark
There is a surprise here that I can't see even gryphon protocol field in the running wireshark. So in order to test this, I am typing foo or gryphon in that display filter and it turns red and it say foo is neither a protocol nor a protocol field. I am using Ubuntu 16.04 LTS to build it. The build goes fine.
Here is packet-foo.c
#include "config.h"
#include <epan/packet.h>
#include "packet-foo.h"
static int proto_foo = -1;
static int dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_);
void
proto_register_foo(void)
{
proto_foo = proto_register_protocol (
"FOO Protocol", /* name */
"FOO", /* short name */
"foo" /* abbrev */
);
}
void
proto_reg_handoff_foo(void)
{
static dissector_handle_t foo_handle;
foo_handle = create_dissector_handle(dissect_foo, proto_foo);
dissector_add_uint("udp.port", FOO_PORT, foo_handle);
}
static int
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_)
{
col_set_str(pinfo->cinfo, COL_PROTOCOL, "FOO");
/* Clear out stuff in the info column */
col_clear(pinfo->cinfo,COL_INFO);
return tvb_captured_length(tvb);
}
Here is the packet-foo.h
#define FOO_PORT 1234
The CMakeLists.txt is here, this is actually a copy of gryphon.
So, I am wondering if gryphon wasn't recognised that means foo won't be recognised too. So, this file might be a source of problem.
include(WiresharkPlugin)
# Plugin name and version info (major minor micro extra)
set_module_info(foo 0 0 4 0)
set(DISSECTOR_SRC
packet-foo.c
)
set(PLUGIN_FILES
plugin.c
${DISSECTOR_SRC}
)
set_source_files_properties(
${PLUGIN_FILES}
PROPERTIES
COMPILE_FLAGS "${WERROR_COMMON_FLAGS}"
)
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
register_plugin_files(plugin.c
plugin
${DISSECTOR_SRC}
)
add_plugin_library(foo epan)
target_link_libraries(foo epan)
install_plugin(foo epan)
file(GLOB DISSECTOR_HEADERS RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}" "*.h")
CHECKAPI(
NAME
foo
SWITCHES
-g abort -g termoutput -build
SOURCES
${DISSECTOR_SRC}
${DISSECTOR_HEADERS}
)

Merely changing the plugin isn't sufficient.
You need to modify the top make file so that foo is actually installed.
vim CMakeListsCustom.txt.example
Firstly, uncomment - line number 16
plugins/epan/foo
Since your foo lives inside plugins/epan/foo
Now, rename this example to
mv CMakeListsCustom.txt.example CMakeListsCustom.txt
vim CMakeLists.txt
Insert a line number around 1408-
plugins/epan/foo
After that, do make
and then sudo make install
Here is the working copy -
https://github.com/joshis1/WiresharkDissectorFoo

Related

Linux kernel wl18xx module_init is it generated?

I'm looking at this drivers/net/wireless/ti/wl18xx driver module.
The traditional module_init() is not in the source code. Yet the trace dump shows a wl18xx_driver_init() is called, though that function again is not in the source code.
I can see the wl18xx_driver_init() in the objdump of main.o in that driver directory.
Is it that in late versions of kernels those functions/macros are automatically generated? How is that done?
wl18xx_driver_init is generated here with the expansion of module_platform_driver(wl18xx_driver) macro.
It expands roughly to smth like:
static int __init wl18xx_driver_init(void) {
return platform_driver_register(&(wl18xx_driver));
}
static initcall_t __initcall_wl18xx_driver_init6 __used __attribute__((__section__(".initcall" "6" ".init"))) = wl18xx_driver_init;
static void __exit wl18xx_driver_exit(void) {
platform_driver_unregister(&(wl18xx_driver));
}
static exitcall_t __exitcall_wl18xx_driver_exit __exit_call = wl18xx_driver_exit;
See module_platform_driver macro and module driver macro.
# It would be best to post some source code or links the next time, it would make it easier. Including kernel version would be also a good idea.

Vala error "unknown type name" using enum from camel

I am writing this code in Vala, using Camel
using Camel;
[...]
MimeParser par = new MimeParser();
[...]
par.push_state( MimeParserState.MULTIPART, boundary );
I downloaded the camel-1.2.vapi from github vala-girs (this link), put it in a vapi subdirectory and compiled with
valac --vapidir=vapi --includedir=/usr/include/evolution-data-server/camel --pkg camel-1.2 --pkg posix --target-glib=2.32 -o prog prog.vala -X -lcamel-1.2
Compiling I get this error:
error: unknown type name "CamelMimeParserState"
const gchar* camel_mime_parser_state_to_string (CamelMimeParserState self);
Looking the C output code I see that the CamelMimeParserState type is used several times but it is never defined. It should be a simple enum because the camel-1.2.vapi file says:
[CCode (cheader_filename = "camel/camel.h", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
PRE_FROM,
FROM,
HEADER,
BODY,
MULTIPART,
MESSAGE,
PART,
END,
EOF,
PRE_FROM_END,
FROM_END,
HEADER_END,
BODY_END,
MULTIPART_END,
MESSAGE_END
}
So why doesn't the C output code simply use an enum as the vapi file says (described by cprefix CAMEL_MIME_PARSER_STATE_)?
Is there an error in the .vapi file?
I found the solution. The vapi file is wrong because the cname field is missing. Changing the vapi file adding this cname="camel_mime_parser_state_t":
[CCode (cheader_filename = "camel/camel.h", cname="camel_mime_parser_state_t", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
[...]
works correctly.

Elixir NIF- Hello World example on x64 Mac OSX

Hi I'm trying to get the Hello World example for Erlang NIF (Native Implemented Function) shown here
http://www.erlang.org/doc/man/erl_nif.html
to work from Elixir on OSX 64bit.
First I create the C-code:
/* niftest.c */
#include "erl_nif.h"
static ERL_NIF_TERM hello(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
return enif_make_string(env, "Hello world!", ERL_NIF_LATIN1);
}
static ErlNifFunc nif_funcs[] =
{
{"hello", 0, hello}
};
ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
Then I successfully compile it using gcc for 64 bit architecture as suggested here
Erlang NIF Test -- OS X Lion
gcc -undefined dynamic_lookup -dynamiclib niftest.c -o niftest.so -I /usr/local/Cellar/erlang/R14B02/lib/erlang/usr/include
which produces the necessary file niftest.so that I should be able to interface-into from Erlang/Elixir. My Elixir (niftest.ex) looks like this (inspired by a more complex example reported here):
defmodule Niftest do
#onload :init
def init() do
:erlang.load_nif("./niftest", 0)
:ok
end
def hello() do
"NIF library not loaded"
end
end
Now with niftest.so and niftest.ex in the same directory I fire up elixir using iex and type in Niftest.hello and all I get back is: "NIF library not loaded"
Am I missing a vital step? - please help!
The load of the library is failing silently. You can assert that it succeeds using:
:ok = :erlang.load_nif("./niftest", 0)
This results in an error:
** (MatchError) no match of right hand side value:
{:error, {:bad_lib, 'Library module name \'niftest\' does not match calling module \'\'Elixir.Niftest\'\''}}
niftest.ex:4: Niftest.init/0
That happens because a NIF lib can only be called from its "owning" module. The name of that module is the first argument to the ERL_NIF_INIT macro, so you can fix this by changing that call and recompiling:
ERL_NIF_INIT(Elixir.Niftest,nif_funcs,NULL,NULL,NULL,NULL)
There is also a typo in the load hook. It should be:
#on_load :init

snmpget: No such object available on this agent at this OID

I am trying to add my own MIB-Module into a snmp agent, following this tutorial: http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_MIB_Module
Now, I followed the tutorial step by step and doubled checked everything, searched a really long time but nothing helped me fixing my problem!
I am using net-snmp version 5.7.3
I implemented the following code into the net-snmp/agent/mibgroup directory:
#include <net-snmp/net-snmp-config.h>
#include <net-snmp/net-snmp-includes.h>
#include <net-snmp/agent/net-snmp-agent-includes.h>
#include "nstAgentModuleObject.h"
/*
* the variable we want to tie an OID to. The agent will handle all
** GET and SET requests to this variable changing it's value as needed.
*/
static long nstAgentModuleObject = 42;
/*
* our initialization routine, automatically called by the agent
* (to get called, the function name must match init_FILENAME())
*/
void
init_nstAgentModuleObject(void)
{
static oid nstAgentModuleObject_oid[] =
{ 1, 3, 6, 1, 4, 1, 8072, 2, 4, 1, 1, 1, 0 };
/*
* a debugging statement. Run the agent with -DnstAgentModuleObject to see
* the output of this debugging statement.
*/
DEBUGMSGTL(("nstAgentModuleObject",
"Initializing the nstAgentModuleObject module\n"));
/*
* the line below registers our variables defined above as
* accessible and makes it writable. A read only version of any
* of these registration would merely call
* register_read_only_int_instance() instead. The functions
* called below should be consistent with your MIB, however.
*/
DEBUGMSGTL(("nstAgentModuleObject",
"Initalizing nstAgentModuleObject scalar integer. Default value = %d\n",
nstAgentModuleObject));
netsnmp_register_long_instance("nstAgentModuleObject",
nstAgentModuleObject_oid,
OID_LENGTH(nstAgentModuleObject_oid),
&nstAgentModuleObject, NULL);
DEBUGMSGTL(("nstAgentModuleObject",
"Done initalizing nstAgentModuleObject module\n"));
}
I ran ./configure --with-mib-modules="nstAgentModuleObject", followed by make and make install. So the nstAgentModuleObject should be integrated in the snmpd agent.
The associated MIB NET-SNMP-TUTORIAL-MIB is saved in /usr/local/snmp/mbis, as well as /~/.snmp/mibs.
I added mibs +ALL in the snmpd.conf to make sure the MIB is loaded correctly. Also I used export MIBS=+all, just in case another .conf is read which should not be the case.
Using following commands I get the results shown below:
snmptranslate -Of NET-SNMP-TUTORIAL-MIB:nstAgentModuleObject
.iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.netSnmpTutorialMIB.nstMIBObjects.nstAgentModulesObject
snmptranslate -On NET-SNMP-TUTORIAL-MIB:nstAgentModuleObject
.1.3.6.1.4.1.8072.2.4.1.1.1
Now, running snmpget with the specified OID gives me this error(appending a 0 on the end since its a scalar. Results in the same error without it as well).
snmpget -v2c -c public localhost .1.3.6.1.4.1.8072.2.4.1.1.1.0
NET-SNMPEXAMPLES-MIB::netSnmpExamples.4.1.1.1.0 = No Such Object availaible on this agent at this OID
It seems like the MIB-module is not properly build-in to the agent, but I can't think of a reason why.
I know the same question has been posted before here, but it didn't receive any answer.(snmpget returns "No Such Object available on this agent at this OID")
So I want to try my luck and hope someone can help me out!
I had the exact same issue,
It didn't work with 5.6.2.
How I solved it:
I've upgraded to 5.7.3 , then it started working.
you need to take care for the following:
configure the package (on build) to support agentx) with --with-mib-modules=agentx
this is my configure:
./configure --prefix=/usr --build=i386-linux --host=arm-linux --target=arm-linux --with-ar=arm-arago-linux-gnueabi-ar --with-cc=arm-arago-linux-gnueabi-gcc --with-ld=arm-arago-linux-gnueabi-ld --with-cflags="-O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp" --with-endianness=big --with-ldflags=-Bstatic --enable-mini-agent --with-mib-modules="mibII ip-mib if-mib tcp-mib udp-mib ucd_snmp target agent_mibs notification-log-mib snmpv3mibs notification agentx" --without-openssl --without-perl-modules --disable-embedded-perl --disable-shared --with-default-snmp-version="2" --with-sys-contact="root" --with-sys-location="unknown" --with-logfile="/var/log/snmpd.log" --with-persistent-directory="/var/net-snmp" --disable-manuals
add agentx to snmpd.conf
This is my snmpd.config
master agentx
rocommunity public rwcommunity private
com2sec readonly default public
com2sec readwrite default private
started snmpd with debug, to give more details:
snmpd -f -Lo: -Dagentx
Then start the agentx application
The following tutorial also helped:
http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a_Subagent
I don't think you need to include the trailing 0 when you create your OID array. I use netsnmp_create_handler_registration in my code base instead of netsnmp_register_long_instance, but this is what I generally do.
static oid nstAgentModuleObject_oid[] = { 1, 3, 6, 1, 4, 1, 8072, 2, 4, 1, 1, 1 };

Right way to run the same code twice in v8 (array out-of-bounds fails on second run - deoptimizer)

The following program is based on the example in the v8 Getting Started page. I have made three changes to demonstrate a problem I am encountering:
I create an empty array put it into the global context.
The script being run references the zeroth element in the array, which should return undefined.
I run the compiled script twice.
The first run works fine. The second fails: v8 calls V8_Fatal() in Deoptimizer::DoComputeCompiledStubFrame() because descriptor->register_param_count_ == -1.
Am I doing something wrong here? How can I fix it?
Isolate* isolate = Isolate::New();
Isolate::Scope isolate_scope(isolate);
HandleScope handle_scope(isolate);
Local<Context> context = Context::New(isolate);
Context::Scope context_scope(context);
Local<Array> a = Array::New(isolate);
context->Global()->Set(String::NewFromUtf8(isolate, "a"), a);
Local<String> source = String::NewFromUtf8(isolate, "a[0];");
Local<Script> script = Script::Compile(source);
Local<Value> result = script->Run();
Local<Value> result2 = script->Run();
return 0;
NOTES:
This is the entire body of main().
Other fragments of JavaScript code run twice without a problem. Somehow this relates to the out-of-bound array reference, which is perhaps triggering deoptimization.
I do not want to recompile the script from scratch each time because I am typically running these scripts thousands of times, and sometimes millions of times.
I have tried compiling the script as an UnboundScript and then binding it for each execution, but the result is the same.
I have reported this as a v8 issue, but nobody has responded so I'm hoping that the StackOverflow community can help.
I am seeing this on VS2012 Update 4, but I also see it on VS2008, and in both x64 and x86 and in both Debug and Release builds.
OK, found it. The problem is an uninitialized code stub for dictionary loads - your use case triggers this as a failure as the stub isn't initialized through other means, eg compilation.
Below is a patch against v8 trunk revision 22629 that fixes the problem for me, tested on Windows with VS 2010 and Linux with g++ 4.9. Please let me know how you go with this:
Index: src/code-stubs.cc
===================================================================
--- src/code-stubs.cc (revision 22629)
+++ src/code-stubs.cc (working copy)
## -236,6 +236,8 ##
CODE_STUB_LIST(DEF_CASE)
#undef DEF_CASE
case UninitializedMajorKey: return "<UninitializedMajorKey>Stub";
+ case NoCache:
+ return "<NoCache>Stub";
default:
if (!allow_unknown_keys) {
UNREACHABLE();
## -939,6 +941,13 ##
// static
+void KeyedLoadDictionaryElementStub::InstallDescriptors(Isolate* isolate) {
+ KeyedLoadDictionaryElementStub stub(isolate);
+ InstallDescriptor(isolate, &stub);
+}
+
+
+// static
void KeyedLoadGenericElementStub::InstallDescriptors(Isolate* isolate) {
KeyedLoadGenericElementStub stub(isolate);
InstallDescriptor(isolate, &stub);
Index: src/code-stubs.h
===================================================================
--- src/code-stubs.h (revision 22629)
+++ src/code-stubs.h (working copy)
## -1862,6 +1862,8 ##
virtual void InitializeInterfaceDescriptor(
CodeStubInterfaceDescriptor* descriptor) V8_OVERRIDE;
+ static void InstallDescriptors(Isolate* isolate);
+
private:
Major MajorKey() const { return KeyedLoadElement; }
int NotMissMinorKey() const { return DICTIONARY_ELEMENTS; }
Index: src/isolate.cc
===================================================================
--- src/isolate.cc (revision 22629)
+++ src/isolate.cc (working copy)
## -2000,6 +2000,7 ##
NumberToStringStub::InstallDescriptors(this);
StringAddStub::InstallDescriptors(this);
RegExpConstructResultStub::InstallDescriptors(this);
+ KeyedLoadDictionaryElementStub::InstallDescriptors(this);
KeyedLoadGenericElementStub::InstallDescriptors(this);
}
As a workaround if you don't want to compile your own V8 for now, you could execute some code on each Isolate that uses the KeyedLoadDictionaryElementStub directly, prior to running your code --- this should initialize the stub. Something like the following works for me:
Isolate* isolate = Isolate::New();
Isolate::Scope isolate_scope(isolate);
HandleScope handle_scope(isolate);
Local<Context> context = Context::New(isolate);
Context::Scope context_scope(context);
Local<Array> a = Array::New(isolate);
context->Global()->Set(String::NewFromUtf8(isolate, "a"), a);
// Workaround code for initializing KeyedLoadDictionaryElementStub
Local<String> workaround_source = String::NewFromUtf8(isolate, "Math.random()");
Local<Script> workaround_script = Script::Compile(workaround_source);
Local<Value> workaround_value = workaround_script->Run();
// End workaround
Local<String> source = String::NewFromUtf8(isolate, "a[0]");
Local<Script> script = Script::Compile(source);
// ...and so on

Resources