Re: [Wireshark-dev] How to handle Ethernet frames with FCS, malformed packet in PN dissector

2011-09-27 Thread HPfrommer
Seems to work perfect now!


-Ursprüngliche Nachricht-
Von: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] Im Auftrag von Guy Harris
Gesendet: Montag, 26. September 2011 22:56
An: Developer support list for Wireshark
Betreff: Re: [Wireshark-dev] How to handle Ethernet frames with FCS,malformed 
packet in PN dissector


On Sep 26, 2011, at 12:34 PM, Guy Harris wrote:

 Yes - it's assuming that it's being handed a tvbuff containing the FCS, *even 
 if the dissector for the link layer knows that there's an FCS*.  That's not 
 what link-layer dissectors should be doing; there was a bug, introduced a 
 while ago, where the Ethernet dissector wasn't removing the FCS if it knew it 
 was there, so perhaps that code was written during the period where that bug 
 was present.  I will remove that code from the PN dissector and leave behind 
 a comment explaining why there is no FCS handling code there.

OK, done.  Try it with the current SVN version of Wireshark.

BTW, is there a spec available for PROFINET Real-Time packets, for non-PROFINET 
members, either for free or for a not-too-high fee?
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

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


[Wireshark-dev] How to handle Ethernet frames with FCS, malformed packet in PN dissector

2011-09-26 Thread HPfrommer
Hi,



I'm currently implementing a new pcap link-layer type which contains an
Ethernet frame including the FCS (see LINKTYPE_NETANALYZER on
http://www.tcpdump.org/linktypes.html).

Now I have observed a problem with the PROFINET dissector, I'm not sure
how to deal with it, and I'm not sure if even other dissectors are
affected.



From the pcap file I read:



+--+

+ Link_layer header+

+--+

+  +

+ Ethernet frame data  +

+  +

+- - - - - - - - - - - +

+ Ethernet FCS +

+--+



The WTAP dissector dissects the link-layer header and generates a new
tvb subset containing only the Ethernet frame data + FCS (cuts of the
link-layer header). This tvb subset is passed to the eth_withfcs
dissector.



In pcap_read_post_process() I added the new encap type and set the
pseudo-headers FCS length to 4:

case WTAP_ENCAP_NETANALYZER:

pseudo_header-eth.fcs_len = 4;

break;



Now I open a pcap file containing a PN-PTCP DelayRes frame, which
results in a malformed packet expert info exception occurred. Looking
at the packet-pn-rt.c source code in dissect_pn_rt() there are some
manipulations regarding pinfo-pseudo_header-eth.fcs_len and tbv
reported length.



If I change my assignment in pcap_read_post_process() to

pseudo_header-eth.fcs_len = -1;

the frame can be dissected correctly without error.



Now my question:

I thought I have to set pseudo_header-eth.fcs_len to 4, as the tvb
contains the FCS, but this does result in false dissection of packets.
Am I wrong and do I have to set pseudo_header-eth.fcs_len to -1? Will
this work witch all other dissectors? Or is the behaviour a bug in the
PN dissector?



Regards,

Holger









Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

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

Re: [Wireshark-dev] Enhancement of built-in dissector

2011-08-30 Thread HPfrommer
Hi Guy,

thanks for your feedback, I will request a new LINKTYPE.


-Ursprüngliche Nachricht-
Von: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] Im Auftrag von Guy Harris
Gesendet: Freitag, 26. August 2011 12:09
An: Developer support list for Wireshark
Betreff: Re: [Wireshark-dev] Enhancement of built-in dissector


On Aug 26, 2011, at 2:15 AM, hpfrom...@hilscher.com wrote:

 some time ago I submitted a patch 
 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6082) to enhance some 
 features of a built in dissector.
 Unfortunately, nothing happened so far. I know you guys are quite busy, but I 
 would appreciate if someone could check the patch, to have it available with 
 the next releases.

I checked it, and I refuse to check it in for any release - the very notion of 
a heuristic dissector for the frame dissector makes no sense whatsoever, as the 
contents of the frame depend on the link-layer type of the frame.

As I said in the bug:

The very notion of a heuristic dissector running directly atop the frame 
dissector is nonsensical; the contents of the frame depend on the link-layer 
type of the frame; you don't know whether the frame is an Ethernet frame or an 
802.11 frame or an 802.11 frame with a radiotap header or an 802.11 frame with 
a PRISM header or a Token Ring frame or an FDDI frame or a PPP frame or a BSD 
loopback interface frame or a raw IP frame or an ATM AAL5 frame with some 
particular flavor of pseudo-header or

If Hilscher made the huge mistake of putting into a pcap file with a link-layer 
type of 1 (LINKTYPE_ETHERNET/DLT_EN10MB) frames that have a 
netANALYZER-specific header, followed by a regular Ethernet frame, that's their 
mistake, not ours; if they want to put their frames into pcap files, they 
should request a LINKTYPE_/DLT_ value for their packets from 
tcpdump-work...@lists.tcpdump.org, and contribute code for Wireshark that adds 
a new WTAP_ENCAP_ value for that LINKTYPE_ value, maps that LINKTYPE_ value to 
the new WTAP_ENCAP_ value, and adds a dissector for that WTAP_ENCAP_ value.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

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


[Wireshark-dev] Enhancement of built-in dissector

2011-08-26 Thread HPfrommer
Hi,



some time ago I submitted a patch
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6082) to enhance
some features of a built in dissector.

Unfortunately, nothing happened so far. I know you guys are quite busy,
but I would appreciate if someone could check the patch, to have it
available with the next releases.



Thanks a lot,

Holger





Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

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

[Wireshark-dev] How to determine if Wireshark is x86 or x64

2010-01-14 Thread HPfrommer
Hi,

I've developed a custom dissector which shall be installed to
...\application data\wireshark\plugin automatically during
installation of our product on Windows (Wireshark itself is not included
in this installer).
See http://www.wireshark.org/lists/wireshark-dev/200810/msg00208.html

I've built two plugin DLLs, one for x86 and another for x64, how can the
installer determine if the installed Wireshark is x86 or x64 in order to
select the correct DLL?

Regards,
Holger




Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

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

Re: [Wireshark-dev] [HELP]How to dissect a packet withouta protocol? It can only be digged out by i

2008-02-22 Thread HPfrommer
With this method you have to dissect the whole frame, including the MAC 
addresses, ethertyp, vlan tag, etc..

Maybe someone knows another method to keep the original Ethernet header info?

 



Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von yenan
Gesendet: Freitag, 22. Februar 2008 01:06
An: Developer support list for Wireshark
Betreff: Re: [Wireshark-dev] [HELP]How to dissect a packet withouta protocol? 
It can only be digged out by i

 

 

Thank you very very much, Holger!!
 
 
Using heur_dissector seems I have to dissect whold frame including the 
mac address, even the header is in prefect Ethernet II frame format?
 
Regards
Nan
 





Date: Thu, 21 Feb 2008 09:15:26 +0100
From: [EMAIL PROTECTED]
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [HELP]How to dissect a packet without a 
protocol? It can only be digged out by its Dst Mac or Vlan I



Hi Nan,

 

you can easily register to a MAC address or any other byte in a frame 
by using a heuristic dissector.

 

Register the dissector:

heur_dissector_add(eth, dissect_foo_heur, proto_foo);

 

 

Use this dissector function:

static gboolean dissect_foo_heur(tvbuff_t *tvb, packet_info *pinfo, 
proto_tree *tree)

{

  /* check if destination MAC equals 01:02:03:04:05:06 */

  if ( (tvb_get_guint8(tvb, 0) == 0x01)  

   (tvb_get_guint8(tvb, 1) == 0x02)  

   (tvb_get_guint8(tvb, 2) == 0xa3)  

   (tvb_get_guint8(tvb, 3) == 0x04)  

   (tvb_get_guint8(tvb, 4) == 0x05)  

   (tvb_get_guint8(tvb, 5) == 0x06) )

  { 

/* do dissecting */

  )

  else

  {

/* MAC does not match */

return FALSE;

  }

 

  return TRUE:

}

 

 

This works perfect for me.

 

Holger

 

 

 





Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von yenan
Gesendet: Donnerstag, 21. Februar 2008 02:00
An: wireshark-dev@wireshark.org
Betreff: [Wireshark-dev] [HELP]How to dissect a packet without a 
protocol? It can only be digged out by its Dst Mac or Vlan I

 

Hi folks:
Im writing a plugin for a packet store in the payload of standard 
802.1Q Virtual LAN packet ,this packet does not have protocol itself, it can 
only be digged by its Dst Mac address or Vlan Id, how could I dissect such a 
packet?
I tried to use :
register_dissector_table() in  vlan.c to create dissector table for 
vlan.id, and in the plugin I used dissector_add() tring to call the 
dissector, but wont work! so , should I also use : dissector_try_port(), what 
should I pass in these functions ?
Any information I can read and lean rn for these functions?
 
And last question, if I try to dig out the packet by its dst mac 
address, what should I do? I find out the address are in FT_ETHER type, how can 
I handle such types?
 
I went through readme.develper couple times, still know very little for 
wireshark, are there anymore documents will explain the functions and structure 
in more detail?
 
 
Really need help!Thanks millions!Any information will be greatly 
appreciated!
 
 
Nan





Windows Live Writer,支持离线撰写博客内容,随时随地想写就写。 立即使用! 
http://get.live.cn/product/writer.html 

Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Gesch?ftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com http://www.hilscher.com/ 

 



Windows Live Writer,支持离线撰写博客内容,随时随地想写就写。 立即使用! 
http://get.live.cn/product/writer.html 


Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Gesch?ftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] [HELP]How to dissect a packet without a protocol? It can only be digged out by its Dst Mac or Vlan I

2008-02-21 Thread HPfrommer
Hi Nan,

 

you can easily register to a MAC address or any other byte in a frame by using 
a heuristic dissector.

 

Register the dissector:

heur_dissector_add(eth, dissect_foo_heur, proto_foo);

 

 

Use this dissector function:

static gboolean dissect_foo_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree 
*tree)

{

  /* check if destination MAC equals 01:02:03:04:05:06 */

  if ( (tvb_get_guint8(tvb, 0) == 0x01)  

   (tvb_get_guint8(tvb, 1) == 0x02)  

   (tvb_get_guint8(tvb, 2) == 0xa3)  

   (tvb_get_guint8(tvb, 3) == 0x04)  

   (tvb_get_guint8(tvb, 4) == 0x05)  

   (tvb_get_guint8(tvb, 5) == 0x06) )

  { 

/* do dissecting */

  )

  else

  {

/* MAC does not match */

return FALSE;

  }

 

  return TRUE:

}

 

 

This works perfect for me.

 

Holger

 

 

 



Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von yenan
Gesendet: Donnerstag, 21. Februar 2008 02:00
An: wireshark-dev@wireshark.org
Betreff: [Wireshark-dev] [HELP]How to dissect a packet without a protocol? It 
can only be digged out by its Dst Mac or Vlan I

 

Hi folks:
Im writing a plugin for a packet store in the payload of standard 802.1Q 
Virtual LAN packet ,this packet does not have protocol itself, it can only be 
digged by its Dst Mac address or Vlan Id, how could I dissect such a packet?
I tried to use :
register_dissector_table() in  vlan.c to create dissector table for vlan.id, 
and in the plugin I used dissector_add() tring to call the dissector, but wont 
work! so , should I also use : dissector_try_port(), what should I pass in 
these functions ?
Any information I can read and leanrn for these functions?
 
And last question, if I try to dig out the packet by its dst mac address, what 
should I do? I find out the address are in FT_ETHER type, how can I handle such 
types?
 
I went through readme.develper couple times, still know very little for 
wireshark, are there anymore documents will explain the functions and structure 
in more detail?
 
 
Really need help!Thanks millions!Any information will be greatly appreciated!
 
 
Nan



Windows Live Writer,支持离线撰写博客内容,随时随地想写就写。 立即使用! 
http://get.live.cn/product/writer.html 


Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Gesch?ftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] Including new dissector to wireshark development branch

2008-01-16 Thread HPfrommer
Hello,

 

I've written a dissector for a special analyzer protocol we have
developed here in my company.

I'd like to ask if it's possible to include this dissector into the
Wireshark development branch.

If you're ok with including our dissector, maybe it would be the best if
you can create a path /plugins/hilscher (name of our dissector),

and I will get SVN access to this path, so we will be able to maintain
the dissector by our own and the other developers don't need to worry
about our dissector.

 

If you like to see the dissector's source in advance I can send it to
the mailing list if you like.

 

Regards,

Holger Pfrommer

 


Hilscher Gesellschaft fur Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschaftsfuhrer: Hans-Jurgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Register dissector to MAC address

2007-11-13 Thread HPfrommer
Thanks for your advises, I will check if I can find a way to do
heuristic dissecting.

Holger

 



Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Maynard,
Chris
Gesendet: Montag, 12. November 2007 23:13
An: Developer support list for Wireshark
Betreff: RE: [Wireshark-dev] Register dissector to MAC address

 

At first glance, packet-eth.c seems to have heuristic support, but it
doesn't appear to work, at least not how I expected it to.  For example,
originally for the WOL dissector, I registered as I do for UDP, namely:

heur_dissector_add(eth, dissect_wol, proto_wol);

 

But registering it that way didn't work for me, so it's been changed to:

dissector_add(ethertype, ETHERTYPE_WOL, wol_handle);

 

I didn't dig too deeply into why it failed since I had a reasonable
alternative, but I suppose I should have.  It now seems to me to be a
bug in packet-eth.c, but I'm not entirely sure, based on the comments in
the code.

 

First, compare the way a dissector like packet-udp.c tries the heuristic
dissectors, using the next_tvb:

next_tvb = tvb_new_subset(tvb, offset, len, reported_len);

if (dissector_try_heuristic(heur_subdissector_list, next_tvb, pinfo,
tree))

Now look at how packet-eth.c does it:

if (dissector_try_heuristic(heur_subdissector_list, tvb, pinfo,
parent_tree))
goto end_of_eth;

Notice that there's no next_tvb.  I assumed that this was intentional
when I looked at it before, but now I'm not so sure.  A bug?  It now
sure looks like it to me.  I couldn't find any other dissectors that try
to heuristically register to eth as I tried above.  Perhaps because it
doesn't work?  If it is a bug, then once that's corrected, then that
would be the better way to register both WOL and the original poster's
dissector - heuristically.

 

- Chris

 



From: [EMAIL PROTECTED] on behalf of Stephen Fisher
Sent: Mon 11/12/2007 12:50 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Register dissector to MAC address

On Mon, Nov 12, 2007 at 12:37:10PM -0500, Maynard, Chris wrote:

 Can anyone think of a reason NOT to add heuristic dissection support
 to packet-eth.c?  Or does anyone have a better/alternate way to solve
 this?

My first thought is that the original poster's dissector could be a
heuristic that checks against the MAC address when deciding whether to
acccept the packet or not.  Does this need changes to packet-eth.c?  I'm
not sure, but could find out by researching the code a bit.


Steve

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Hilscher Gesellschaft fur Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschaftsfuhrer: Hans-Jurgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] Register dissector to MAC address

2007-11-12 Thread HPfrommer
Hi,

 

I have an application where I receive specially formed frames from a
specific unique MAC address.

Is it possible to register my dissector to a MAC address? 

 

All I was able to do was registering a dissector to an ethertype like
follows:

dissector_add(ethertype, 0x88ff, test_dissector);

 

But 

dissector_add(eth.src, 01:02:03:04:05:06, test_dissector);

does not work (well actually it can't, because the second parameter
should be guint32). 

 

Is there any possibility to do this?

 

Actually, my packet has no unique ethertype so it would be important to
register to the unique MAC :-( (very special application, you see).

 

Thanks for your help!

 

Best regards,

Holger Pfrommer

 

 


Hilscher Gesellschaft fur Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschaftsfuhrer: Hans-Jurgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Missing export in libwireshark (tap)

2007-07-30 Thread HPfrommer
;-)
Ok, thank you!

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jeff Morriss
Gesendet: Freitag, 27. Juli 2007 16:24
An: Developer support list for Wireshark
Betreff: Re: [Wireshark-dev] Missing export in libwireshark (tap)

[EMAIL PROTECTED] wrote:

 I was trying to use the tap-feature (epan/tap.c) in my dissector.
 
 Unfortunately, the linker cannot find the function fetch_tapped_data.
 
 Is there any reason, why this function is not included the exports of 
 libwireshark.def?

Probably only that nobody ever wanted to use it before.  I added it in 
rev 22412.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] Missing export in libwireshark (tap)

2007-07-27 Thread HPfrommer
Hi,

 

I was trying to use the tap-feature (epan/tap.c) in my dissector.

Unfortunately, the linker cannot find the function fetch_tapped_data.

Is there any reason, why this function is not included the exports of
libwireshark.def?

 

Regards,

Holger

 


Hilscher Gesellschaft fur Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschaftsfuhrer: Hans-Jurgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Bugfix for plugins/profinet

2007-07-24 Thread HPfrommer
Hi,

attached you'll find a short capture of three frames.

Regards,
Holger
 

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Ulf Lamping
Gesendet: Montag, 23. Juli 2007 21:51
An: Developer support list for Wireshark
Betreff: Re: [Wireshark-dev] Bugfix for plugins/profinet

[EMAIL PROTECTED] schrieb:

 Hi,

 I've fixed a bug in the Profinet-Dissector 
 (plugins/profinet/packet-dcerpc-pn-io.c).

 In PROFINET IO DCE RPC write-requests, only the first IR frame dataset 
 in PDIRFrameData was dissected.

 I've fixed the problem, now all IR frame datasets are dissected into 
 individual sub-trees.

 svn diff file is attached.

Would you mind to send a sample capture file so I can test against?

You can send it to me personally, if there are any privacy concerns 
sending it to the list ...

Regards, ULFL
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com



profinet_ir_data.pcap
Description: profinet_ir_data.pcap
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] Bugfix for plugins/profinet

2007-07-23 Thread HPfrommer
Hi,

 

I've fixed a bug in the Profinet-Dissector
(plugins/profinet/packet-dcerpc-pn-io.c).

In PROFINET IO DCE RPC write-requests, only the first IR frame dataset
in PDIRFrameData was dissected.

I've fixed the problem, now all IR frame datasets are dissected into
individual sub-trees.

 

svn diff file is attached.

 

Greetings,

Holger

 


Hilscher Gesellschaft fur Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschaftsfuhrer: Hans-Jurgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com



profinet_patch.gz
Description: profinet_patch.gz
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev