Feature request: Export decoded messages to PCAPNG

[jpacov]

Is your feature request related to a problem?

Exporting decoded messages to a standard output file (PCAPNG) is really useful for further analysis.

Describe the solution you'd like

Be able to export decoded messages to PCAPNG.

Describe alternatives you've considered

I saw you have a PCAP.py file, but seems not complete. I propose to use pkg python-pcapng (https://python-pcapng.readthedocs.io/en/latest/index.html) which does all the job to save a PCAPNG compliant file really simple. We could added as a 3rd option in the SaveAs dialog you already have.

If you agree I can make the PR with the changes.

[jopohl]

Back in the day we implemented PCAP support which worked but hit the limit of that file format as an analysis in Wireshark was not suitable (you had to add your own decoder by submitting a PR to the wireshark foundation or so..). If PCAPNG solves that issue - why not! However, I am hesitant to use new dependencies especially for something as simple as writing a file. If you can create a PR without a new dependency I will be happy to accept it.

[jpacov]

I'll create the export PCAP functionality without adding a new dependency, as you requested.

Regarding how useful this PCAP file can be: Me and a bunch of colleagues plan to use your URH to record RF signals, and store them as decoded data in PCAP files. We'll merge them in Wireshark to other PCAPs created in other mediums (LF for example) To interpret them in Wireshark, we'll create our Lua dissectors that make all the magic so that Wireshark interprets frames accordingly.

Anyway, the only open point I have is: timestamps. I see the timestamp is assigned at the moment of processing the message (time.now), and we lose the real timestamp of the signal. Do you know if there is a way to recover that timestamp from the HW (hackrf for example)? Or can we at least use the time.now() at the moment of starting the signal recording instead of later when processing? What do you think?

[jopohl]

To interpret them in Wireshark, we'll create our Lua dissectors that make all the magic so that Wireshark interprets frames accordingly.

Good stuff! Just saw in their wiki how that works, seems like a good route to take, didn't know Wireshark is extensible in that way.

Anyway, the only open point I have is: timestamps. I see the timestamp is assigned at the moment of processing the message (time.now), and we lose the real timestamp of the signal. Do you know if there is a way to recover that timestamp from the HW (hackrf for example)? Or can we at least use the time.now() at the moment of starting the signal recording instead of later when processing? What do you think?

Good point...a relative timestamp for a message should be easy to calculate from the sample rate and the location (=current sample) in the signal. Would that be enough i.e. the signal starts at timestamp 000000? If absolute timestamps are required a straightforward solution that comes to mind is to add a timestamp to the src/urh/signalprocessing/Signal.py class and set it when an object of that class is created.

[jpacov]

Mmmm would be really helpful to have absolute timestamps (then you can drag&drop in Wireshark all pcaps you want and all are ordered in chronological order).

So I'll investigate around your second suggestion (adding the timestamp in Signal.py when Signal objects are created). Are they called on the fly during the measurement? Or until the end?

[jopohl]

There should be only one signal created (if we speak about the record dialog). I do not recall at which time the signal is created:

• when the dialog is opened, or
• when the record button is clicked, or
• or when dialog is closed / save button is pressed

should be easy to find this out through debugging. Maybe it makes sense to update/set the timestamp when the record button is pressed.

[jpacov]

Question: what is the proper way to build repo with HackRf support? I installed first: sudo apt install libhackrf-dev And then when installing setup: python3 setup.py install it says it found it: Found hackrf lib. Will compile with native hackrf support

But in interface still only RTL-TCP can be selected in Device.

I guess a flag when building is missing maybe?

[jopohl]

You need to enable it in Options -> Device.

On Sat, 12 Mar 2022, 15:19 jpacov, @.***> wrote:

Question: what is the proper way to build repo with HackRf support? I installed first: sudo apt install libhackrf-dev And then when installing setup: python3 setup.py install it says it found it: Found hackrf lib. Will compile with native hackrf support

But in interface still only RTL-TCP can be selected in Device.

I guess a flag when building is missing maybe?

— Reply to this email directly, view it on GitHub https://github.com/jopohl/urh/issues/968#issuecomment-1065891500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELAGRRL3W735FI3EROSWI3U7SRYPANCNFSM5QKCTMHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[jopohl]

Closed via #970