Wireshark C dissector error when filling subtree - c

I have a simple Wireshark dissector which throws the following bug warning when it is run against a capture:
13:04:12 Warn Dissector bug, protocol usbserial, in packet 353: /wireshark/epan/proto.c:5504:
failed assertion "idx >= 0 && idx < num_tree_types"
The protocol registration function looks like this:
static gint ett_myproto = -1;
void
proto_register_myproto(void)
{
/* Set up field array */
static hf_register_info hf[] = {
{ &hf_myproto_payload,
{"Payload", "myproto.payload", FT_BYTES, BASE_NONE, NULL,
0x0, NULL, HFILL }},
};
/* Register protocol */
proto_myproto = proto_register_protocol("My Protocol", "myproto", "myproto");
/* Register protocol fields */
proto_register_field_array(proto_myproto, hf, array_length(hf));
/* Register the dissector */
register_dissector("myproto", dissect_myproto, proto_myproto);
}
The dissector does some general munging of data, but the core of the problem area seems to be:
static int
dissect_myproto(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
void *data _U_)
{
proto_item *ti;
proto_tree *myproto_tree;
/* Create top tree and add to the item */
ti = proto_tree_add_protocol_format(tree, proto_myproto, tvb, 0, -1,
"My Protocol");
myproto_tree = proto_item_add_subtree(ti, ett_myproto);
proto_tree_add_bytes_format(myproto_tree, hf_myproto_payload,
tvb, 0, payload_len,
NULL, "Payload");
}
What do I need to do to get the protocol to fill the subtree correctly?

The problem here is a failure to register the subtree as part of a subtree array (hint from here).
This is done in the protocol registration function, and requires "packaging" the subtree variables (of which there is only one here: ett_myproto) into an array, and then registering that array using proto_register_subtree_array:
static gint ett_myproto = -1;
void
proto_register_myproto(void)
{
/* Set up field array */
static hf_register_info hf[] = {
....
};
/* Register protocol */
proto_myproto = proto_register_protocol("My Protocol", "myproto", "myproto");
/* Register protocol fields */
proto_register_field_array(proto_myproto, hf, array_length(hf));
/* Setup and register all protocol subtrees */
static gint *ett[] = {
&ett_myproto,
};
proto_register_subtree_array(ett, array_length(ett));
/* Register the dissector */
register_dissector("myproto", dissect_myproto, proto_myproto);
}
The ett variables are indices used to refer to GUI information about the state of the subtree (e.g. expanded or not).

Related

Cannot move camera using libuvc

I'm trying to control my camera using libuvc.
I tried this code I modified from the example:
#include <libuvc/libuvc.h>
#include <stdio.h>
#include <unistd.h>
int main() {
uvc_context_t *ctx;
uvc_device_t *dev;
uvc_device_handle_t *devh;
uvc_stream_ctrl_t ctrl;
uvc_error_t res;
/* Initialize a UVC service context. Libuvc will set up its own libusb
* context. Replace NULL with a libusb_context pointer to run libuvc
* from an existing libusb context. */
res = uvc_init(&ctx, NULL);
if (res < 0) {
uvc_perror(res, "uvc_init");
return res;
}
puts("UVC initialized");
/* Locates the first attached UVC device, stores in dev */
res = uvc_find_device(
ctx, &dev,
0, 0, NULL); /* filter devices: vendor_id, product_id, "serial_num" */
if (res < 0) {
uvc_perror(res, "uvc_find_device"); /* no devices found */
} else {
puts("Device found");
/* Try to open the device: requires exclusive access */
res = uvc_open(dev, &devh);
if (res < 0) {
uvc_perror(res, "uvc_open"); /* unable to open device */
} else {
puts("Device opened");
uvc_print_diag(devh, stderr);
//uvc_set_pantilt_abs(devh, 100, 100);
int result = uvc_set_pantilt_abs(devh, 5, 50);
printf("%d\n", result);
//sleep(5);
/* Release our handle on the device */
uvc_close(devh);
puts("Device closed");
}
/* Release the device descriptor */
uvc_unref_device(dev);
}
/* Close the UVC context. This closes and cleans up any existing device handles,
* and it closes the libusb context if one was not provided. */
uvc_exit(ctx);
puts("UVC exited");
return 0;
}
I tried both uvc_set_pantilt_abs and uvc_set_pantilt_rel and both are returning 0 so it means the action is successful. Except the camera does not move.
I'm sure the camera uses UVC because uvc_print_diag indicates
VideoControl:
bcdUVC: 0x0110
Am I doing something wrong? If not how can I troubleshoot it?
I found the answer a while ago but forgot to put it here.
I stumbled upon this project which controls a camera using a commandline tool with libuvc.
After playing a bit with it and compared it with my code I got what I did wrong. He was getting the pantilt data from the camera and then using it to send requests. It seems cameras need to receive a number which must be a multiple of the "step" provided by the camera as the movement unit.
Here's the part where he requests the pantilt information:
int32_t pan;
int32_t panStep;
int32_t panMin;
int32_t panMax;
int32_t tilt;
int32_t tiltStep;
int32_t tiltMin;
int32_t tiltMax;
// get current value
errorCode = uvc_get_pantilt_abs(devh, &pan, &tilt, UVC_GET_CUR);
handleError(errorCode, "Failed to read pan/tilt settings - possibly unsupported by this camera?\n");
// get steps
errorCode = uvc_get_pantilt_abs(devh, &panStep, &tiltStep, UVC_GET_RES);
handleError(errorCode, "Failed to read pan/tilt settings - possibly unsupported by this camera?\n");
// get min
errorCode = uvc_get_pantilt_abs(devh, &panMin, &tiltMin, UVC_GET_MIN);
handleError(errorCode, "Failed to read pan/tilt settings - possibly unsupported by this camera?\n");
// get max
errorCode = uvc_get_pantilt_abs(devh, &panMax, &tiltMax, UVC_GET_MAX);
handleError(errorCode, "Failed to read pan/tilt settings - possibly unsupported by this camera?\n");
Here's the full code

How to send messages in PM server Minix

So I'm trying to create a new system call on PM server. My question is, how can I send some kind of message to function.
in IPC server all I had to do is add my system call to the list, because all functions there were defined as (*func)(message *)
(...)/servers/ipc/main.c
static struct {
int type;
int (*func)(message *);
int reply; /* whether the reply action is passed through */
} ipc_calls[] = {
(...)
{ IPC_MYNEWSIGNAL, do_something, 1 },
};
but in PM in table.c functions are defined as
(...)/servers/pm/table.c
int (* const call_vec[NR_PM_CALLS])(void) = {
(...)
CALL(PM_GETSYSINFO) = do_getsysinfo
}
and if I try to pass function with signature
int do_something(message *m)
I will get error:
Incompatible pointer types: initializing int (*const)(void) with int (message *)
What is the correct way to create signal on PM server if I need to receive some kind of information?
As far as I understood from the question, you want to receive arguments inside the syscall handler. Let's take as an example the library function clock_settime from libc.
int clock_settime(clockid_t clock_id, const struct timespec *ts)
{
message m;
memset(&m, 0, sizeof(m));
m.m_lc_pm_time.clk_id = clock_id;
m.m_lc_pm_time.now = 1; /* set time immediately. don't use adjtime() method. */
m.m_lc_pm_time.sec = ts->tv_sec;
m.m_lc_pm_time.nsec = ts->tv_nsec;
if (_syscall(PM_PROC_NR, PM_CLOCK_SETTIME, &m) < 0)
return -1;
return 0;
}
As you can see it writes the args inside message struct and passes to _syscall. OK, now have a look at syscall handler for PM_CLOCK_SETTIME which is mounted in table.c.
int do_gettime()
{
clock_t ticks, realtime, clock;
time_t boottime;
int s;
if ( (s=getuptime(&ticks, &realtime, &boottime)) != OK)
panic("do_time couldn't get uptime: %d", s);
switch (m_in.m_lc_pm_time.clk_id) {
case CLOCK_REALTIME:
clock = realtime;
break;
case CLOCK_MONOTONIC:
clock = ticks;
break;
default:
return EINVAL; /* invalid/unsupported clock_id */
}
mp->mp_reply.m_pm_lc_time.sec = boottime + (clock / system_hz);
mp->mp_reply.m_pm_lc_time.nsec =
(uint32_t) ((clock % system_hz) * 1000000000ULL / system_hz);
return(OK);
}
It becomes clear that the argument is a global variable named m_in. A little bit more search shows that it comes from glo.h
/* The parameters of the call are kept here. */
EXTERN message m_in; /* the incoming message itself is kept here. */
I suppose that MINIX will handle setting and accessing the global variable, so you don't need to explicitly write to it.
Have a look at point 7 Passing a parameter to a system call here. To understand how to compile the kernel correctly refer to this post.

What is the use of of_device_id and i2c_device_id?

I was understanding an I2C driver for adxl34x sensor.
If I only keep of_device_id, my probe does not gets called, but if I include i2c_device_id probe gets called.
I checked for some explanation but I get to know that i2c_device_id is used for legacy purpose or board file matching.
Here I am using device tree.
How is it possible that i2c_device_id is making the device recognised?
Is there a dependency in I2C drivers to use both i2c_Device_id and of_device_id??
here is my understanding on this top
id_table is used for legacy i2c devices. See in this code
static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id *id,
const struct i2c_client *client)
{
while (id->name[0]) {
if (strcmp(client->name, id->name) == 0)
return id;
id++;
}
return NULL;
}
There is no device id table reference, while of_device_id
/**
* of_match_device - Tell if a struct device matches an of_device_id list
* #ids: array of of device match structures to search in
* #dev: the of device structure to match against
*
* Used by a driver to check whether an platform_device present in the
* system is in its list of supported devices.
*/
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
if ((!matches) || (!dev->of_node))
return NULL;
return of_match_node(matches, dev->of_node);
}
Uses dev->of_node
So its safe to say both mechanism are isolated and does not depend on each other.
Then why my driver is not getting probed by only using this,
/*
static const struct i2c_device_id adxl34x_id[] = {
{ "adxl345", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, adxl34x_id);
*/
#ifdef CONFIG_OF
static const struct of_device_id adxl34x_of_id[] = {
/*
* The ADXL346 is backward-compatible with the ADXL345. Differences are
* handled by runtime detection of the device model, there's thus no
* need for listing the "adi,adxl346" compatible value explicitly.
*/
{ .compatible = "adi,adxl345", },
/*
* Deprecated, DT nodes should use one or more of the device-specific
* compatible values "adi,adxl345" and "adi,adxl346".
*/
{ .compatible = "adi,adxl34x", },
{ }
};
MODULE_DEVICE_TABLE(of, adxl34x_of_id);
#endif
static struct i2c_driver adxl34x_driver = {
.driver = {
.name = "adxl34x",
//.pm = &adxl34x_i2c_pm,
.of_match_table = of_match_ptr(adxl34x_of_id),
},
.probe = adxl34x_i2c_probe,
.remove = adxl34x_i2c_remove,
//.id_table = adxl34x_id, /*commented i2c_device_id*/
};
Here are some links that I have gone through in order to get some understanding
https://patches.linaro.org/patch/16873/
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/131965.html
https://i2c.wiki.kernel.org/index.php/OF_Modalias
I understood that first of_* style match will happen, then i2c_device_id type match.
In my case, then how of_* is not able to bind then?
Why i2c_device_table is needed if its legacy thing?
You are right. It is true that you need to pass id_table along with the driver structure for I2C if you are using probe callback.
This is because the earlier I2C driver framework used older style of probe function signature that required i2c_device_id to be passed as the second parameter. However, this has now been replaced with i2c_probe_new callback whose function signature shows that it no more needs i2c_device_id parameter anymore.
Here is a link to this code change for reference:
https://elixir.bootlin.com/linux/v5.16.9/source/include/linux/i2c.h#L281

G_Signals handling non-Gobject types?

The only example I was able to find for creating and emitting new signals was on the gnome developer site which provides the following example:
file = g_object_new (MAMAN_FILE_TYPE, NULL);
g_signal_connect (file, "changed", G_CALLBACK (changed_event), NULL);
maman_file_write (file, buffer, strlen (buffer));
/* ------------------ */
file_signals[CHANGED] =
g_signal_newv ("changed",
G_TYPE_FROM_CLASS (gobject_class),
G_SIGNAL_RUN_LAST | G_SIGNAL_NO_RECURSE | G_SIGNAL_NO_HOOKS,
NULL /* closure */,
NULL /* accumulator */,
NULL /* accumulator data */,
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE /* return_type */,
0 /* n_params */,
NULL /* param_types */);
/* ------------------ */
void maman_file_write (MamanFile *self, const guchar *buffer, gssize size)
{
/* First write data. */
/* Then, notify user of data written. */
g_signal_emit (self, file_signals[CHANGED], 0 /* details */);
}
One thing I'm wondering is whether it's possible to emit signals which don't have a GObject as a source -- and whether it's possible to pass non-Gobject structures.
For simplicity sake suppose I have a function that creates point objects and I want to emit a signal when a point has been created (suppose there is some GtkWidget that displays something when a point is created):
struct point {
int x,y;
};
struct point *new_point(int x, int y) {
struct point *my_point = malloc(sizeof(point));
my_point->x= x;
my_point->y= y;
/* ???
g_signal_emit "point-created"
send pointer to my_point as a parameter to listeners
*/
return my_point;
}
Is there a way to make something akin to the lower work without all of the boiler plate that goes into creating a new G_OBJECT_TYPE ?

Run C Code Block in Erlang

How to Run C Code Block from Erlang? ( Or Call a C function from erlang? )
This is for creating a driver
Firstly you'll need to create the C/C++ files to do it.
They will need to include
#include "erl_driver.h"
#include "ei.h"
Then you'll need to set up the driver mapping
/* mapping of the drivers functions */
static ErlDrvEntry driver_entry = {
NULL, /* init */
startup_function_name, /* startup */
shutdown_function_name, /* shutdown */
NULL, /* output */
NULL, /* ready_input */
NULL, /* ready_output */
driver_name, /* the name of the driver */
NULL, /* finish */
NULL, /* handle */
NULL, /* control */
NULL, /* timeout */
outputv_function_name, /* outputv */
NULL, /* ready_async */
NULL, /* flush */
NULL, /* call */
NULL, /* event */
ERL_DRV_EXTENDED_MARKER, /* ERL_DRV_EXTENDED_MARKER */
ERL_DRV_EXTENDED_MAJOR_VERSION, /* ERL_DRV_EXTENDED_MAJOR_VERSION */
ERL_DRV_EXTENDED_MAJOR_VERSION, /* ERL_DRV_EXTENDED_MINOR_VERSION */
ERL_DRV_FLAG_USE_PORT_LOCKING /* ERL_DRV_FLAGs */
};
DRIVER_INIT(driver_name){
return &driver_entry;
}
Note: if you are trying to run C++ code instead of C you'll need
extern "C" {
DRIVER_INIT(driver_name){
return &driver_entry;
}
}
And you will need to cast any literal string with (char *)
Then it's good to define a struct that'll contain the port information
typedef struct
{
ErlDrvPort port;
} port_data;
Lastly, you'll want to set up all the functions
static ErlDrvData startup_function_name(ErlDrvPort port, char *doc)
{
/* Plus any other start up methods you need */
port_data* d = (port_data*)driver_alloc(sizeof(port_data));
d->port = port;
return (ErlDrvData)d;
}
/* Plus any other shutdown methods you need */
static void shutdown_function_name(ErlDrvData handle)
{
driver_free((char*)handle);
}
static void outputv_function_name(ErlDrvData handle, ErlIOVec *ev)
{
port_data* d = (port_data*)handle;
char* inputstring = ev->binv[1]->orig_bytes;
ErlDrvTermData spec[] = {
ERL_DRV_ATOM, driver_mk_atom("ok"),
ERL_DRV_BUF2BINARY, inputstring, strlen(inputstring)
ERL_DRV_TUPLE, 2
};
driver_send_term(d->port,driver_caller(d->port),spec,sizeof(spec)/sizeof(spec[0]));
}
You'll want to compile this C/C++ code into a shared object and link it with the erl interface
g++ -fpic -rdynamic -shared file_name -lerl_interface -lei
Now from erlang you'll want to do a couple things:
You'll need to load the driver
erl_ddll:load_driver("./location/of/driver", driver_name).
Then you'll open a port to the driver
Port = open_port({spawn, driver_name}, [binary]).
And lastly you can sent data to the port
port_command(Port, <<"String to Echo Back"),
receive
{ok, String} -> io:format("Received ~p back from the driver")
end.
The newest approach would consider NIFs http://www.erlang.org/doc/man/erl_nif.html (be careful, it can crash VM). Regular way to do it involves linked in drivers (google up the link, because anti-spam holds it)

Resources