On Dec 6, 2011, at 7:26 AM, Yegor Yefremov wrote:
> The issue left is milliseconds conversion. AFAIK nsec is an int value, so
> it is not enough even for a second :-(
OK, divide milliseconds by 1000 and add it to secs, and take the remainder,
multiply it by 100, and put it into nsecs.
_
On Tue, Dec 6, 2011 at 2:06 PM, Jaap Keuter wrote:
> On 2011-12-02 16:21, Yegor Yefremov wrote:
>
>> Hi
>>
>> I'm writing a CANOpen dissector
>> (http://en.wikipedia.org/wiki/CANopen). The dissector itself is almost
>> ready. The main problem I have is, how do I hook this dissector on to
>> Socket
On Tue, Dec 6, 2011 at 9:52 AM, Guy Harris wrote:
>
> On Dec 6, 2011, at 12:21 AM, Yegor Yefremov wrote:
>
>> In CANOpen protocol there is a packet type TIME_STAMP. It is
>> constructed in the following way:
>>
>> 1. first 4 bytes are milliseconds since midnight, but in LSB first
>> form (0x10 0x2
Hi,
The array is used to track expanded/collapsed state of the subtree.
What you need to do is the following:
proto_item item = proto_tree_add_item(tree, hf_my_tree, tvb, 0, -1,
ENC_NA)
proto_tree my_tree = proto_item_add_subtree(item, ett_my_tree);
proto_item my_field = proto_tree_a
On 2011-12-02 16:21, Yegor Yefremov wrote:
Hi
I'm writing a CANOpen dissector
(http://en.wikipedia.org/wiki/CANopen). The dissector itself is
almost
ready. The main problem I have is, how do I hook this dissector on to
SocketCan one? CAN has no ports, so I can't decide on this basis. My
sugge
hi everybody,
I've trouble understanding what's the role of
proto_register_subtree_array. Each time I create a subtree, there is
the same message appending on top of the subtree ("Energywise v2")
and I wish it would remain blank. I create my subtrees like this:
proto_item_add_subtree( uuid_item,
On Dec 6, 2011, at 12:21 AM, Yegor Yefremov wrote:
> In CANOpen protocol there is a packet type TIME_STAMP. It is
> constructed in the following way:
>
> 1. first 4 bytes are milliseconds since midnight, but in LSB first
> form (0x10 0x20 0x30 0x40 is actually 0x40 0x30 0x20 0x10)
> 2. next 2 by
In CANOpen protocol there is a packet type TIME_STAMP. It is
constructed in the following way:
1. first 4 bytes are milliseconds since midnight, but in LSB first
form (0x10 0x20 0x30 0x40 is actually 0x40 0x30 0x20 0x10)
2. next 2 bytes are days since 01.01.1984
Is there some build-in method to g
On 2011-12-03 05:47, Chris Maynard wrote:
Some taps, such as tap-comparestat.c and tap-rtp-common.c, make use
of
pinfo->iphdrlen, so shouldn't tap_queue_packet() be called *after*
all
the pinfo
data is assigned by the dissector?
I had already changed this to be the case for IPv4 (see line 207
