Problems with EthernetFrame

Issue #30 resolved
Daniel Probst created an issue

Hello Tobias,

I ran into a few issues while processing EthernetFrames. I’m running the latest version of your library.

First, calculateObjectSize() somitemes gives a wrong value. For instance, in your test_EthernetFrame.blf, the ObjectSize is 67, but the calculated size returns 70. In our files there are some EthernetFrames where there is no problem, but for many of them the calculated size is off by 1 or 2.

Second, there seems to be an issue writing EthernetFrames. I don’t know if it’s related to the issue with the object size. I attached you a small example program.

Running that programm with your test_CanMessage.blf results in the following frames being written:
2459565876494606882 ns: CanMessage: channel=4369 flags=34 dlc=51 id=0x44444444 data=[55 66 77 88 99 aa bb cc]
2459565876494606882 ns: CanMessage: channel=4369 flags=34 dlc=51 id=0x44444444 data=[55 66 77 88 99 aa bb cc]
2459565876494606882 ns: Unknown115: unknown0=0xcccccccccccccccc unknown1=0x0008cccccccccccc unknown2=0x000003e800180008 unknownData=[]

But running it with test_EthernetFrame.blf just writes the first frame:
2459565876494606882 ns: EthernetFrame: sourceAddress=[11 22 33 44 55 66] channel=30583 destinationAddress=[88 99 aa bb cc dd] dir=61166 type=65535 tpid=4369 tci=8738 payLoadLength=5 payLoad=[04 05 06 00 4c]

I tested it using one of our files containing objects of various types. It wrote all objects with no problem, until it got to the first EthernetFrame. After that, no more objects were written. To be clear, the programs runs through without problems, but the resulting blf file ends after the first EthernetFrame.

I hope you can look into it.
Thanks a lot!

Cheers, Daniel

Comments (4)

  1. Tobias Lorenz repo owner
    • changed status to open

    Yes, I can reproduce this. I guess, the padding bytes to the next message are wrongly calculated.

  2. Log in to comment