Re: [Wireshark-dev] Push failed after amend (Change 27518)

[Ahmad Fatoum]

> On 11Jun 2018, at 09:28, david_agge...@hispeed.ch wrote:
>  
> ==
> remote: Processing changes: refs: 1, done
> To ssh://code.wireshark.org:29418/wireshark
> ! [remote rejected]   HEAD -> refs/publish/master/dicom-heuristic 
> (duplicate request)
> error: failed to push some refs to 
> 'ssh://david-agge...@code.wireshark.org:29418/wireshark'
> Done
> ==

git push --force-with-lease

--force works as well, but --force-with-lease is good habit (you can't override 
someone else's changes by mistake that way).

Cheers
Ahmad


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng

[Ahmad Fatoum]

> On 5May 2018, at 10:47, Guy Harris  wrote:
> 
> That doesn't require "some authority that allocates protocol identifiers", 
> because it doesn't require protocol identifiers; all that needs to be done is 
> to allocate pcapng block types to those protocols that require some 
> additional information to decrypt its traffic.

I like the idea of a "universal"  key pcapng block more than requiring each 
interested protocol to request its own block.


signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng

[Ahmad Fatoum]

Hi,

> On 5May 2018, at 09:31, Guy Harris  wrote:
> 
> "Support multiple protocols in a capture" in what sense?

multiple protocols with a key block each, e.g. TLS and Tibia interleaved in the 
same capture file. 
> On 4May 2018, at 09:21, Paul Zander  wrote:
> 
> Via fields in this block we can define for which protocol the key is.


> On 5May 2018, at 09:31, Guy Harris  wrote:
>> some authority that allocates protocol identifiers would be desirable
> 
> If this is going to be in pcapng files, the authority would be the pcapng 
> file format maintainers.

Of course, the pcapng maintainers are the authority on the block's structure,
but the protocol identifier would be a field inside the new "Wireshark 
dissector preferences" block and managed by Wireshark, no?


>> and I think Wireshark protocol names are very suited for this (after 
>> renaming SSL to TLS :-).
>> 
>> Maybe:
>> - Standardize some prefs_register_key_preference API for key supplement in 
>> Wireshark that wraps existing UAT/preference use and provides key 
>> preferences in a uniform format
>> - Agree on a specific format for those key preferences inside pcapng blocks
> 
> Once they're in pcapng blocks, unless the block is Wireshark-specific, the 
> preferences would be managed entirely by the pcapng developers, not the 
> Wireshark developers.

The block is Wireshark-specific. Its layout is fixed and versioned. The 
contents vary but Wireshark would commit to a standard format for key 
preferences.


Thinking about it, another alternative would be a generic pcap block but with a 
frame number replacing the protocol name. The frame number can be used to 
identify the protocol "conversation" that the key is associated with and 
alleviates the need to centrally assign protocol identifiers.


Cheers
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng

[Ahmad Fatoum]

> On 4May 2018, at 19:10, Guy Harris  wrote:
> 
> That might *also* be useful, but the advantage of blocks that *aren't* tied 
> to Wireshark is that *other* programs can use the data without having to 
> track Wireshark.

I see, but to support multiple protocols in a capture, some authority that 
allocates protocol identifiers would be desirable
and I think Wireshark protocol names are very suited for this (after renaming 
SSL to TLS :-).

Maybe:
- Standardize some prefs_register_key_preference API for key supplement in 
Wireshark that wraps existing UAT/preference use and provides key preferences 
in a uniform format
- Agree on a specific format for those key preferences inside pcapng blocks
- Implement the new pcapng block and Wireshark preferences support, maybe a 
mergeprefcap(1) as well

I would like if both the Tibia and the EPL dissectors were able to utilize this 
as well. Currently their preferences are:
Tibia: symmetric key (frame number, key_hexstring)
Tibia: asymmetric key (ip_addr, port_num, key_file, password)
EPL: Device Profile (device_id, vendor_id, product_id, path)

This could be generalized as entries of (protocol_name, frame_number, 
key_string).
frame_number would be a packet that uniquely identifies what the key is for 
(handshake packet, IdentifyResponse..) or just some packet in a TCP 
conversation.

Downside of using "key" frames is that this could necessitate relocation when 
editing the capture. What do you think?

Cheers
Ahmad
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng

[Ahmad Fatoum]

> On 4May 2018, at 01:13, Ben Higgins  wrote:
> 
> What I'd like to do is instead create a new pcap-ng block type that we can 
> put SSL keylog file contents into verbatim.

How about a generic "Wireshark dissector preferences" pcapng block with { 
pref.key => value } tuples?
e.g. { ssl.keys_list => "127.0.0.1,4443,http,/home/dirkx/xx/privkey.pem" }


And when the capture file is closed, overridden preferences are reset.

Cheers
Ahmad


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] git question

[Ahmad Fatoum]

In future, better use branches, so you can trim them when they're no longer 
needed.
You can do this now with:
git branch my-change
git reset --hard HEAD~3

After that you can git pull master and decide whether you want to git branch 
--delete my-change

Alternatively, you can also git pull --rebase && git reset --hard HEAD~3 or git 
reset --hard HEAD~3 && git pull
which removes those three commit without saving them to a branch first.

Regards
Ahmad

> On 2Dec 2017, at 23:23, e-mail graham.shanks via Wireshark-dev 
>  wrote:
> 
> After submitting some changes to git review and getting them accepted I get 
> the following message when I do a git status:
> 
> C:\Development\wireshark>git status
> On branch master
> Your branch is ahead of 'origin/master' by 3 commits.
> (use "git push" to publish your local commits)
> nothing to commit, working tree clean
> 
> A search on this message suggests that I need to do a git pull --rebase, but 
> the documentation suggests that this will synchronise with the remote 
> repository (which is what I want to do) but then try to apply the commits 
> (which I don't want to do, I think). The git documentation on rebase doesn't 
> seem to cover what I think the wireshark repository is doing.
> 
> Is git pull --rebase the correct thing to do? Also did I do something wrong 
> to get into this state?
> 
> Regards
> Graham
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Newbie

[Ahmad Fatoum]

Hello Peter,

You could start by implementing/extending a Wireshark dissector for a protocol 
you use in order to get accustomed to the API.
For example, my first Wireshark-related project was writing a protocol 
dissector for a game I used to play.
doc/README.developer and doc/README.dissector have some information to get you 
started.

Cheers,
Ahmad


> On 9Oct 2017, at 17:31, pete...@gmx.de wrote:
> 
> Hello,
> 
> i am Peter from Munich (München) / Germany.
> 
> I am a native german speaker, but i try to write english at my best.
> 
> I would like to work on developing Wireshark from now on.
> 
> This is my first open source project.
> 
> I have to learn the function/using of Wireshark too.
> 
> I have some experience in programming in C/C++ and also (less) QT on windows, 
> LINUX and Solaris.
> I would like to use Windows (8.1) on a 64-bit machine.
> 
> What is the specific problem with QTCreator on windows?
> 
> I habe today made the first build on my machine. Wireshark built on my 
> machine runs.
> 
> Can somebody give me a hint, what i now can do, e.g. what change on sources 
> and/or learning using Wireshark?
> 
> 
> Greetins, Peter
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Intro & first patch

[Ahmad Fatoum]

Hello Brenton,

Welcome! For the packet capture, please open a Bugzilla ticket at 
https://bugs.wireshark.org,
preferably with the same title as your commit and attach your pcap files there.
Afterwards reference the Bugzilla ticket from the commit message of your patch 
on Gerrit by adding
Bug: 123456

Change-related discussions are best done on Gerrit. The cherry-picked commit 
has a link to the Gerrit discussion appended
and it's better to have everything at one place. The mailing list is geared 
more towards general discussions and questions.

Cheers,
Ahmad


> On 9Oct 2017, at 21:41, Brenton Rothchild  wrote:
> 
> Hello everyone,
> 
> My name is Brenton Rothchild. I'm a freelance developer with an embedded 
> C/C++ background.
> 
> I submitted my first patch, a change for Zigbee On/Off commands. I hope I 
> followed all of the procedures correctly according to the Developer's Guide & 
> Wiki. If not, please feel free to help me learn the correct way to submit 
> changes and point out what I can do differently.
> 
> If there's any questions on the change, feel free to ping me via the list, or 
> comments in Gerrit.
> 
> I can also provide a sample capture file I've used for testing (I didn't see 
> any way to post such an attachment to Gerrit directly?)
> 
> Looking forward to being able to contribute at least 1 small patch to such a 
> great project!
> 
> Thanks!
> -Brenton
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Importing raw application protocol data with Wireshark

[Ahmad Fatoum]

There is "Import from Hexdump" in the File menu, which can prefix headers, 
create a pcap and open it in Wireshark.
It's also usable from the command line with the text2pcap utility.

I also had success with Net::PcapWriter from CPAN in the past.

Regards,
Ahmad

> On 14Sep 2017, at 13:28, Jack Guest  wrote:
> 
> Hi,
> 
> Is there any straightforward way of importing from a file
> application-layer protocol data that lacks transport headers (i.e
> lacks link-layer, internet-layer and transport-layer headers) in order
> to be able to use an existing Wireshark protocol dissector to view and
> analyze the application protocol raw data?
> 
> 
> If not, what would it take to add such feature to Wireshark or the other 
> tools?
> 
> Thanks,
> Jack
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checkapi prefs

[Ahmad Fatoum]

prefs_register_*_preference populates a variable with a user-supplied
value. And having more than one preference populate the same variable is
usually not what you want.
But the actual definitions of the function do just that: They use the same
variable name and similar types for the variable.

I will submit a fix shortly. Thanks for reporting.

Cheers,
Ahmad


On Tue, Aug 8, 2017 at 11:33 AM, Dario Lombardo  wrote:

> I've got this error from checkAPI_epan target:
>
> prefs.c: error: found these preference variables used in more than one
> prefs_register_*_preference:
> guint *var, const char **var, , range_t **var
>
> I can't figure out what does it mean. Can anyone help?
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Edit rights to the Wireshark Wiki

[Ahmad Fatoum]

Hello,

Please add Wiki user AhmadFatoum to EditorGroup.
I want to update Protocols/epl documentation with the newly accepted 
preferences.

Thanks
Ahmad


signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Specifying dissectors declaratively

[Ahmad Fatoum]

> On 19Apr 2017, at 13:47, Roland Knall  wrote:
> 
> But in my opinion not really usable for most other protocols which include 
> bigger state machines (like industrial ethernet protocols).

Ye, I am not looking for expressing bigger state machines, rather something 
that can churn out dissectors out of definitions like

coords_t := (u16 X)  (u16 Y) (u8 Z)
command := item_move | player_move
item_move :=  (u8 0x64) (coords_t from) (coords_t to) (u8 stackpos) (u16 itemid)
player_move := (u8 0x90) (coords_t to)

(This goes on for some hundred different commands, with multiple versions for 
each command depending on protocol version)

> - Just use Kaitai syntax but rewrite the parser as a c-library to include 
> with wireshark

I'll consider going this route.

Thanks for your input.

Regards,
Ahmad

> 
> 
> On Wed, Apr 19, 2017 at 11:27 AM, Ahmad Fatoum  <mailto:ah...@a3f.at>> wrote:
> Hello everyone,
> 
> I want to update a game protocol dissector I wrote, and would love to be able 
> to rewrite all those game commands in a declarative manner.
> What I've found so far:
> 
> • ASN.1: asn2wrs, part of Wireshark and supports packed encoding rules (PER), 
> but I believe it's not possible to decode an arbitrary non-ASN.1 encoded 
> protocol [1]. Is that right?
> 
> • Wireshark Generic Dissector: A plugin that can read a DSL and dissect 
> packets accordingly [2].
> 
> • CSjark: C structs to Lua dissectors [5].
> 
> • Kaitai Struct: A declarative language written for decoding arbitrary 
> formats [3]. There's a basic Wireshark LUA dissector generator [4].
> 
> 
> 
> In essence, I want something to turn struct-like definitions for an arbitrary 
> protocol into a dissector. Should support:
> • struct pascal_string { u16 len; u8 bytes[len] };
> • continue till character: e.g. for nul-terminated strings
> • pattern matching: struct { u8 0x64; /* 0x64 specific fields */ }, struct { 
> u8 0x10; /* 0x10 specific fields */ }
> • arbitrary nesting thereof
> • endianness specification
> • code generation: The protocol in question is encrypted. So e.g. the generic 
> dissector plugin is insufficient.
> 
> Having readily available parser generators for the format would be a huge 
> plus. Kind of like lex/yacc, but for binary data and with a Wireshark backend.
> 
> So, what are your experiences with declaratively parsing binary data?
> What are your thoughts on having a declarative format for dissectors? Have 
> you tried it before?
> If the ASN.1 support in Wireshark isn't fit for this task, what would need to 
> be done to make it so?
> Would you be interested in a kaitai2wrs generator? Or maybe 
> another_format2wrs? I'd be willing to try.
> 
> 
> This was raised multiple times before on the mailing list, the most extensive 
> one being this, I think:
> https://www.wireshark.org/lists/wireshark-dev/201207/msg00110.html 
> <https://www.wireshark.org/lists/wireshark-dev/201207/msg00110.html>
> 
> 
> Nevertheless, things might have changed?
> 
> 
> Looking forward to feedback.
> 
> Best regards,
> 
> 
> [1]: https://wiki.wireshark.org/Asn2wrs <https://wiki.wireshark.org/Asn2wrs>
> [2]: http://wsgd.free.fr/ <http://wsgd.free.fr/>
> [3]: http://kaitai.io/ <http://kaitai.io/>
> [4]: https://github.com/joushx/kaitai-to-wireshark 
> <https://github.com/joushx/kaitai-to-wireshark>
> [5]: https://github.com/eventh/kpro9 <https://github.com/eventh/kpro9>
> 
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>  mailto:wireshark-dev-requ...@wireshark.org 
> <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Specifying dissectors declaratively

[Ahmad Fatoum]

Hello everyone,

I want to update a game protocol dissector I wrote, and would love to be able 
to rewrite all those game commands in a declarative manner.
What I've found so far:

• ASN.1: asn2wrs, part of Wireshark and supports packed encoding rules (PER), 
but I believe it's not possible to decode an arbitrary non-ASN.1 encoded 
protocol [1]. Is that right?

• Wireshark Generic Dissector: A plugin that can read a DSL and dissect packets 
accordingly [2].

• CSjark: C structs to Lua dissectors [5].

• Kaitai Struct: A declarative language written for decoding arbitrary formats 
[3]. There's a basic Wireshark LUA dissector generator [4].



In essence, I want something to turn struct-like definitions for an arbitrary 
protocol into a dissector. Should support:
• struct pascal_string { u16 len; u8 bytes[len] };
• continue till character: e.g. for nul-terminated strings
• pattern matching: struct { u8 0x64; /* 0x64 specific fields */ }, struct { u8 
0x10; /* 0x10 specific fields */ }
• arbitrary nesting thereof
• endianness specification
• code generation: The protocol in question is encrypted. So e.g. the generic 
dissector plugin is insufficient.

Having readily available parser generators for the format would be a huge plus. 
Kind of like lex/yacc, but for binary data and with a Wireshark backend.

So, what are your experiences with declaratively parsing binary data?
What are your thoughts on having a declarative format for dissectors? Have you 
tried it before?
If the ASN.1 support in Wireshark isn't fit for this task, what would need to 
be done to make it so?
Would you be interested in a kaitai2wrs generator? Or maybe another_format2wrs? 
I'd be willing to try.


This was raised multiple times before on the mailing list, the most extensive 
one being this, I think:
https://www.wireshark.org/lists/wireshark-dev/201207/msg00110.html


Nevertheless, things might have changed?


Looking forward to feedback.

Best regards,


[1]: https://wiki.wireshark.org/Asn2wrs
[2]: http://wsgd.free.fr/
[3]: http://kaitai.io/
[4]: https://github.com/joushx/kaitai-to-wireshark
[5]: https://github.com/eventh/kpro9


signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Debugging an assertion failure

[Ahmad Fatoum]

Hi,

The message you pasted is the one MSVCRT's abort() prints (unless you 
_set_abort_behavior), so setting a breakpoint there should trigger at g_assert 
failure. https://msdn.microsoft.com/en-us/library/da5kh0wa(v=vs.120).aspx 
<https://msdn.microsoft.com/en-us/library/da5kh0wa(v=vs.120).aspx> tells me you 
can press ctrl+b for that.

Regards,
Ahmad

> On 14Apr 2017, at 13:22, Paul Offord  wrote:
> 
> Hi Ahmed,
> 
> Thanks for the suggestion.  How do I break on abort()?  The assert seems to 
> disappear into glib and abort is part of stdlib.
> 
> Best regards…Paul
> 
> From: wireshark-dev-boun...@wireshark.org 
> <mailto:wireshark-dev-boun...@wireshark.org> 
> [mailto:wireshark-dev-boun...@wireshark.org 
> <mailto:wireshark-dev-boun...@wireshark.org>] On Behalf Of Ahmad Fatoum
> Sent: 14 April 2017 11:54
> To: Developer support list for Wireshark  <mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Debugging an assertion failure
> 
> Hello Paul,
> 
> You could always put a breakpoint on abort(). There is surely some way to 
> configure VS2013 to catch it, but this might be the wrong place to ask about 
> that.
> 
> Best regards,
> Ahmad
> 
> On 14Apr 2017, at 12:41, Paul Offord  <mailto:paul.off...@advance7.com>> wrote:
> 
> Hi,
> 
> I need some advice.  I’m debugging a problem with a dissector I’ve written.  
> Tshark fails with:
> … \epan\prefs.c:414:prefs_register_module_or_subtree: assertion failed: 
> (g_ascii_islower(c) || g_ascii_isdigit(c) || c == '_' || c == '-' || c == '.')
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> 
> If I remove the dissector the problem goes away and so I’m sure it’s the 
> cause.
> 
> Even though I can recreate the problem in a debug build under VS 2013 it 
> doesn’t catch the exception.  I just see the above text flash by in the 
> output command box.  How can I cause execution to break when it throws the 
> exception?
> 
> Thanks and regards…Paul
> 
> __
> 
> This message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system.
> 
> Any views or opinions expressed are solely those of the author and do not 
> necessarily represent those of Advance Seven Ltd. E-mail transmission cannot 
> be guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. 
> The sender therefore does not accept liability for any errors or omissions in 
> the contents of this message, which arise as a result of e-mail transmission.
> 
> Advance Seven Ltd. Registered in England & Wales numbered 2373877 at 
> Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com 
> <http://www.symanteccloud.com/>
> __
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> <mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>
> 
> 
> __
> 
> This message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system.
> 
> Any views or opinions expressed are solely those of the author and do not 
> necessarily represent those of Advance Seven Ltd. E-mail transmission cannot 
> be guaranteed to be secure or error-free as information could be 

Re: [Wireshark-dev] Debugging an assertion failure

[Ahmad Fatoum]

Hello Paul,

You could always put a breakpoint on abort(). There is surely some way to 
configure VS2013 to catch it, but this might be the wrong place to ask about 
that.

Best regards,
Ahmad

> On 14Apr 2017, at 12:41, Paul Offord  wrote:
> 
> Hi,
> 
> I need some advice.  I’m debugging a problem with a dissector I’ve written.  
> Tshark fails with:
> … \epan\prefs.c:414:prefs_register_module_or_subtree: assertion failed: 
> (g_ascii_islower(c) || g_ascii_isdigit(c) || c == '_' || c == '-' || c == '.')
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> 
> If I remove the dissector the problem goes away and so I’m sure it’s the 
> cause.
> 
> Even though I can recreate the problem in a debug build under VS 2013 it 
> doesn’t catch the exception.  I just see the above text flash by in the 
> output command box.  How can I cause execution to break when it throws the 
> exception?
> 
> Thanks and regards…Paul
> 
> __
> 
> This message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system.
> 
> Any views or opinions expressed are solely those of the author and do not 
> necessarily represent those of Advance Seven Ltd. E-mail transmission cannot 
> be guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. 
> The sender therefore does not accept liability for any errors or omissions in 
> the contents of this message, which arise as a result of e-mail transmission.
> 
> Advance Seven Ltd. Registered in England & Wales numbered 2373877 at 
> Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com 
> 
> __
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> 
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> 
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> 


signature.asc
Description: Message signed with OpenPGP
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Adding libxml2 as optional Wireshark dependency

[Ahmad Fatoum]

No, I am using libxml2 for parsing the XML (xdd.c in the linked Github
repository).
Giving the user the option to toggle XSD validation would be a nice thing
to have in a future version though.

On Wed, Apr 5, 2017 at 4:36 PM, Graham Bloice 
wrote:

>
>
> On 5 April 2017 at 15:30, Ahmad Fatoum  wrote:
>
>> I can't comment on the Windows binary distribution issue but Pascal's
>> suggestion of using SUSE's sounds promising. I will attempt building on
>> Windows and comment on the Gerrit issue later today.
>>
>> Ethernet POWERLINK specifies XML Device Description (XDD) as its sole
>> format [1].
>>
>
> I see the format specifies an xsd, are you using LibXml2 in "validation"
> mode to ensure the device XML files are well-formed?
>
>
>> EDS (Windows .ini-like format) files are used occasionally, owing to its
>> CANopen roots, but are much less common in usage. Commercial tools as well
>> as openPOWERLINK generate XML files.
>>
>> The revised dissector [2] also supports EDS via Glib's GKeyFile
>> unconditionally.
>>
>> [1] http://www.ethernet-powerlink.org/en/downloads/technical-doc
>> uments/action/open-download/download/epsg-311-v110-ds-xml-
>> device-description/?no_cache=1
>> [2] https://github.com/epl-viz/dissector (Needs to be converted back to
>> a static dissector)
>>
>> On Wed, Apr 5, 2017 at 3:38 PM, Graham Bloice <
>> graham.blo...@trihedral.com> wrote:
>>
>>>
>>>
>>> On 5 April 2017 at 14:11, Ahmad Fatoum  wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I was advised on Gerrit to post this issue here as to garner wider
>>>> input.
>>>>
>>>> This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e
>>>> 0fa8ed7d783 [1] intending to add libxml2 as optional dependency to
>>>> Wireshark.
>>>>
>>>> I am currently preparing to submit upstream, changes I did to the EPL
>>>> v2 dissector (packet-epl.c).
>>>>
>>>> A significant change is the ability to optionally read in user-supplied
>>>> XML device descriptions and to extract type/description/mapping information
>>>> for aiding the dissection. See this previous submission of mine to the
>>>> mailing list: https://www.wireshark.org/lists/wireshark-dev/201701/m
>>>> sg00154.html
>>>>
>>>>
>>>> Seeing as there also has been interest for libxml2 support in
>>>> dissectors in the past:
>>>>
>>>> https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html
>>>>
>>>> https://ask.wireshark.org/questions/36063/using-libxml2-in-m
>>>> y-own-dissector
>>>>
>>>>
>>>> I think, it would be a good idea to have this as optional dependency as
>>>> Glib's GMarkup may be inadequate or inconvenient for parsing actual XML.
>>>>
>>>>
>>>> Looking forward to your feedback.
>>>>
>>>> Best regards,
>>>> Ahmad Fatoum
>>>>
>>>> [1] https://code.wireshark.org/review/#/c/20912/
>>>>
>>> Thanks for the post,
>>>
>>> 1.  Where will the Windows binaries come from and are these supported
>>> long term?  The  libXml2 downloads page indicates another site provides
>>> Windows binaries [1].  The binaries at that site in the 64 bit directory
>>> seem to be the most recent and are labelled as libXml2-2.9.3 [2].  The
>>> current release of libXml2 is 2.9.4 which has a number of security fixes
>>> among other bug fixes and enhancements [3] so it would appear that the
>>> Windows binaries are not being maintained.
>>>
>>> 2.  According to the diagram at [1], libXml2 depends on iconv and zlib.
>>> We currently build our own zlib, will that be suitable for the libXml2
>>> dependency?  What will be the source of the iconv binary (iconv-1.14 is
>>> available in the same download area as libXml2 [2])?
>>>
>>> 3. The readme.txt in the download area ([2]) has some "interesting" text:
>>>
>>> These are experimental 64bit binaries. For completeness, 32bit binaries
>>> built using the same method are also included.
>>>
>>> The libraries in these packages are made using GCC (MinGW) toolchain. It is
>>> presently not possible to use these libraries with any recent version of the
>>> Microsoft Visual C compiler because of conflicting C-runtimes. To help you
>>> resist the temptation,

Re: [Wireshark-dev] Adding libxml2 as optional Wireshark dependency

[Ahmad Fatoum]

I can't comment on the Windows binary distribution issue but Pascal's
suggestion of using SUSE's sounds promising. I will attempt building on
Windows and comment on the Gerrit issue later today.

Ethernet POWERLINK specifies XML Device Description (XDD) as its sole
format [1].

EDS (Windows .ini-like format) files are used occasionally, owing to its
CANopen roots, but are much less common in usage. Commercial tools as well
as openPOWERLINK generate XML files.

The revised dissector [2] also supports EDS via Glib's GKeyFile
unconditionally.

[1]
http://www.ethernet-powerlink.org/en/downloads/technical-documents/action/open-download/download/epsg-311-v110-ds-xml-device-description/?no_cache=1
[2] https://github.com/epl-viz/dissector (Needs to be converted back to a
static dissector)

On Wed, Apr 5, 2017 at 3:38 PM, Graham Bloice 
wrote:

>
>
> On 5 April 2017 at 14:11, Ahmad Fatoum  wrote:
>
>> Hello everyone,
>>
>> I was advised on Gerrit to post this issue here as to garner wider input.
>>
>> This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e
>> 0fa8ed7d783 [1] intending to add libxml2 as optional dependency to
>> Wireshark.
>>
>> I am currently preparing to submit upstream, changes I did to the EPL v2
>> dissector (packet-epl.c).
>>
>> A significant change is the ability to optionally read in user-supplied
>> XML device descriptions and to extract type/description/mapping information
>> for aiding the dissection. See this previous submission of mine to the
>> mailing list: https://www.wireshark.org/lists/wireshark-dev/201701/
>> msg00154.html
>>
>>
>> Seeing as there also has been interest for libxml2 support in dissectors
>> in the past:
>>
>> https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html
>>
>> https://ask.wireshark.org/questions/36063/using-libxml2-in-
>> my-own-dissector
>>
>>
>> I think, it would be a good idea to have this as optional dependency as
>> Glib's GMarkup may be inadequate or inconvenient for parsing actual XML.
>>
>>
>> Looking forward to your feedback.
>>
>> Best regards,
>> Ahmad Fatoum
>>
>> [1] https://code.wireshark.org/review/#/c/20912/
>>
> Thanks for the post,
>
> 1.  Where will the Windows binaries come from and are these supported long
> term?  The  libXml2 downloads page indicates another site provides Windows
> binaries [1].  The binaries at that site in the 64 bit directory seem to be
> the most recent and are labelled as libXml2-2.9.3 [2].  The current release
> of libXml2 is 2.9.4 which has a number of security fixes among other bug
> fixes and enhancements [3] so it would appear that the Windows binaries are
> not being maintained.
>
> 2.  According to the diagram at [1], libXml2 depends on iconv and zlib.
> We currently build our own zlib, will that be suitable for the libXml2
> dependency?  What will be the source of the iconv binary (iconv-1.14 is
> available in the same download area as libXml2 [2])?
>
> 3. The readme.txt in the download area ([2]) has some "interesting" text:
>
> These are experimental 64bit binaries. For completeness, 32bit binaries
> built using the same method are also included.
>
> The libraries in these packages are made using GCC (MinGW) toolchain. It is
> presently not possible to use these libraries with any recent version of the
> Microsoft Visual C compiler because of conflicting C-runtimes. To help you
> resist the temptation, the import libraries (.LIB) are not provided at all.
> If you need these libraries in an environment which mandates the use of the
> Microsoft toolchain, you will have to build them from source yourself.
>
> and inspection of the download shows this is true, so it appears that
> we'll need to rebuild to obtain the import .lib file.
>
> 4. Microsoft have a Visual Studio porting effort underway called vcpkg
> [4], that does include libXml2, but unfortunately is only for VS2015 or
> later.  If we move to VS2015 for main releases (post 2.4 release) then this
> may be a viable source for libXml2 and other packages we use.  It might be
> possible to use this to build VS2013 libXml2.
>
> 5.  Are there any manufacturers or tools that produce XML device
> description files for the EPL dissector such that choosing XML as the input
> format is the most sensible choice, or would another format be just as
> applicable?
>
>
> [1]: https://www.zlatkovic.com/libxml.en.html
> [2]: ftp://ftp.zlatkovic.com/libxml/64bit/
> [3]: http://xmlsoft.org/news.html
> [4]: https://github.com/Microsoft/vcpkg
>
> --
> Graham Bloice
>
>
> 

[Wireshark-dev] Adding libxml2 as optional Wireshark dependency

[Ahmad Fatoum]

Hello everyone,

I was advised on Gerrit to post this issue here as to garner wider input.

This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e0fa8ed7d783
[1] intending to add libxml2 as optional dependency to Wireshark.

I am currently preparing to submit upstream, changes I did to the EPL v2
dissector (packet-epl.c).

A significant change is the ability to optionally read in user-supplied XML
device descriptions and to extract type/description/mapping information for
aiding the dissection. See this previous submission of mine to the mailing
list: https://www.wireshark.org/lists/wireshark-dev/201701/msg00154.html


Seeing as there also has been interest for libxml2 support in dissectors in
the past:

https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html

https://ask.wireshark.org/questions/36063/using-libxml2-in-my-own-dissector


I think, it would be a good idea to have this as optional dependency as
Glib's GMarkup may be inadequate or inconvenient for parsing actual XML.


Looking forward to your feedback.

Best regards,
Ahmad Fatoum

[1] https://code.wireshark.org/review/#/c/20912/
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] XML library for use in dissector

[Ahmad Fatoum]

Hello Peter,

As OEMs can (and do) provide their own device profiles, restricting loading
to compile-time would be too big a limitation.

For now, I  went the plugin route and edited the build files to include
libxml2.

Kind regards
Ahmad Fatoum

On Mon, Jan 30, 2017 at 1:00 PM, 
wrote:

> Date: Sun, 29 Jan 2017 15:52:09 +0100
> From: Peter Wu 
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] XML library for use in dissector
> Message-ID: <20170129145209.GA19229@al>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Ahmad,
>
> On Sat, Jan 28, 2017 at 08:04:11PM +0100, Ahmad Fatoum wrote:
> > Hello everyone,
> >
> > As part of a school project, we intend to extend the Ethernet POWERLINK
> > (packet-epl.c) dissector in Wireshark to be able to read in the XML
> device
> > description files (XDD) and use that information to dissect the packet
> > payload (The data field is currently displayed as a byte stream).
> >
> > As we would like to have the changes eventually merged into the trunk, we
> > want to check what XML library we should use?
> >
> > We are hesitant to rely on GMarkup, because we don't control the input,
> and
> > don't want to later find out that it doesn't manage some more complex
> > device profiles. Wireshark depends on lex(1), but I wouldn't want to
> > reinvent the wheel and rather use some out-of-the-box parser.
> >
> > So what's the stance on dissectors pulling in dependencies like libxml?
> Any
> > other suggestions?
>
> Some (family of) dissectors are generated from description files (ASN.1,
> PIDL, ...). These "compilers" are Python/Perl/... programs which
> sometimes have additional dependencies at the time of generation, but
> are otherwise just normal C dissectors without additional dependencies
> after generation.
>
> Would this method of generating a dissector help? You can find some
> examples in epan/dissectors/asn1/, epan/dissectors/pidl/,
> epan/dissectors/README.X11.
>
> If the XML files describing the payload vary at runtime, I do not have a
> particular suggestion for an approach.
>
> > With kind regards
> > Ahmad Fatoum
> >
> > ps: Out of curiosity, is there a particular reason e.g. PROFINET is a
> > plugin while Ethernet POWERLINK is statically linked?
>
> Most dissectors are located in epan/dissectors/ (statically linked). I
> guess someone started with the PROFINET dissector as plugin and it just
> continued living there.
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] XML library for use in dissector

[Ahmad Fatoum]

Hello everyone,

As part of a school project, we intend to extend the Ethernet POWERLINK
(packet-epl.c) dissector in Wireshark to be able to read in the XML device
description files (XDD) and use that information to dissect the packet
payload (The data field is currently displayed as a byte stream).

As we would like to have the changes eventually merged into the trunk, we
want to check what XML library we should use?

We are hesitant to rely on GMarkup, because we don't control the input, and
don't want to later find out that it doesn't manage some more complex
device profiles. Wireshark depends on lex(1), but I wouldn't want to
reinvent the wheel and rather use some out-of-the-box parser.

So what's the stance on dissectors pulling in dependencies like libxml? Any
other suggestions?

With kind regards
Ahmad Fatoum

ps: Out of curiosity, is there a particular reason e.g. PROFINET is a
plugin while Ethernet POWERLINK is statically linked?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe