Re: [Wireshark-dev] complex problem
On Thu, 13 Oct 2011 09:03:38 -0400, Jeff Morriss jeff.morriss...@gmail.com wrote: Marcel Haas wrote: Hey, maybe the problem isnt so complex to solve but its complex for me to explain. :) I have written my own reassemble code and it seems to work. But i have one big problem. If i set the filter and click apply, it works,because it goes trough every packet. And I get my reassemble msg after the packet but if now click at the reassemble packet there is now reassemble tvb. I know the reason for that cause he interpret every packet one on one Example: Filter is set click at Apply Packet: 1 -frag Packet: 2 -frag Packet: 3 -Reassemble (last frag) If i click at Packet 3 he interprets only packet 3. He doesnt see packet 1 2 and so he bulits now Reass Tvb. The part about not seeing packets 1 and 2 when clicking on packet 3 is correct. You must do all your reassembly in the first pass (read: even when !tree--which it appears you're doing) and it must be stored in such a way that when it's (only) re-dissecting packet 3 it will have the data from packets 1 and 2 available to it. I suspect that your custom reassembly routine isn't doing this latter part. (Yes, this means that Reassembly requires using lots of memory. See http://wiki.wireshark.org/KnownBugs/OutOfMemory .) ___ 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 Hmm okay, but e.g. epan/dissectors/packet-atalk.c use the fragment_add_seq_check function after if(tree) :( So i did with my own reass-algo. Damn reassempling screw me :). And i dont get why fragment_add_seq_check doesnt work for me. im a little bit frustrated.. and that on a friday :D ___ 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] compile warning/error on current svn (make_menu_actions)
Dear all, compiling r39420 fails for me on redhat fc 15. main_menubar.c:3698:1: error: 'make_menu_actions' defined but not used [-Werror=unused-function] In main_menubar.c, the only place where make_menu_actions() is called is inside an #ifdef HAVE_LUA_5_1. Should we have #ifdef HAVE_LUA_5_1 around the function definition as well? Best regards, Martin ___ 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] compile warning/error on current svn (make_menu_actions)
On Oct 14, 2011, at 1:46 AM, Martin Kaiser wrote: Should we have #ifdef HAVE_LUA_5_1 around the function definition as well? Speaking of that, why is this dependent on the Lua *version*? Do we not support adding menu items with earlier versions of Lua? ___ 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] compile warning/error on current svn (make_menu_actions)
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 14 oktober 2011 11:09
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] compile warning/error on current svn
(make_menu_actions)
On Oct 14, 2011, at 1:46 AM, Martin Kaiser wrote:
Should we have #ifdef HAVE_LUA_5_1 around the function definition as
well?
Speaking of that, why is this dependent on the Lua *version*? Do we not
support adding menu items with earlier versions of Lua?
Proposed patch - untested
Index: main_menubar.c
===
--- main_menubar.c (revision 913)
+++ main_menubar.c (working copy)
@@ -3694,6 +3694,8 @@
* Creates an action group for the menu items in xpath, and returns it. The cal
ler should
* use g_object_unref() on the returned pointer if transferring scope.
*/
+#ifdef HAVE_LUA
+/* NOTE currently only used from Lua, remove this ifdef when used outside of #i
fdef LUA */
static GtkActionGroup*
make_menu_actions(const char *path, const menu_item_t *menu_item_data) {
GtkActionGroup *action_group;
@@ -3775,11 +3777,11 @@
return action_group;
}
-
+#endif
static void
merge_lua_menu_items(GList *merge_lua_menu_items_list _U_)
{
-#ifdef HAVE_LUA_5_1
+#ifdef HAVE_LUA
guint merge_id;
GtkActionGroup *action_group;
menu_item_t *menu_item_data;
___
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
___
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] include tvbuff.h failed
Original-Nachricht Datum: Wed, 12 Oct 2011 09:04:42 +0200 Von: Marcel Haas inf...@fh-worms.de An: Developer support list for Wireshark wireshark-dev@wireshark.org Betreff: Re: [Wireshark-dev] include tvbuff.h failed #ifdef HAVE_CONFIG_H #include config.h #endif You should remove the #ifdef HAVE_CONFIG_H, config.h is always used. Regards, Helge -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
On Oct 14, 2011, at 4:03 AM, mart...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39422 User: martinm Date: 2011/10/14 04:03 AM Log: make_menu_items() isn't called without LUA support, so can't be static. Yes, it can; the only reason it couldn't be static would be if it were called from outside gtk/main_menubar.c, which it doesn't appear to be. Its definition might have to protected with the same #ifdef as its use(s), to avoid defined but not used warnings, but that's another matter. ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
On Fri, Oct 14, 2011 at 12:11 PM, Guy Harris g...@alum.mit.edu wrote: On Oct 14, 2011, at 4:03 AM, mart...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39422 User: martinm Date: 2011/10/14 04:03 AM Log: make_menu_items() isn't called without LUA support, so can't be static. Yes, it can; the only reason it couldn't be static would be if it were called from outside gtk/main_menubar.c, which it doesn't appear to be. Its definition might have to protected with the same #ifdef as its use(s), to avoid defined but not used warnings, but that's another matter. Given that its only called from merge_lua_menu_items(), might make_menu_items() be too generic a function name? I don't mind keeping the function static, but protecting the whole definition with #ifdef HAVE_LUA_5_1 While I'm at it shall I rename make_menu_items() to make_lua_menu_items() ? Martin ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Martin Mathieson
Sent: den 14 oktober 2011 14:37
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 39422: /trunk/gtk/
/trunk/gtk/: main_menubar.c
On Fri, Oct 14, 2011 at 12:11 PM, Guy Harris
g...@alum.mit.edumailto:g...@alum.mit.edu wrote:
On Oct 14, 2011, at 4:03 AM,
mart...@wireshark.orgmailto:mart...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39422
User: martinm
Date: 2011/10/14 04:03 AM
Log:
make_menu_items() isn't called without LUA support, so can't be static.
Yes, it can; the only reason it couldn't be static would be if it were called
from outside gtk/main_menubar.c, which it doesn't appear to be.
Its definition might have to protected with the same #ifdef as its use(s), to
avoid defined but not used warnings, but that's another matter.
Given that its only called from merge_lua_menu_items(), might make_menu_items()
be too generic a function name?
I don't mind keeping the function static, but protecting the whole definition
with #ifdef HAVE_LUA_5_1
While I'm at it shall I rename make_menu_items() to make_lua_menu_items() ?
Martin
Perhaps you can use my proposal AND rename the function?
Index: main_menubar.c
===
--- main_menubar.c (revision 913)
+++ main_menubar.c (working copy)
@@ -3694,6 +3694,8 @@
* Creates an action group for the menu items in xpath, and returns it. The cal
ler should
* use g_object_unref() on the returned pointer if transferring scope.
*/
+#ifdef HAVE_LUA
+/* NOTE currently only used from Lua, remove this ifdef when used
+outside of #i
fdef LUA */
static GtkActionGroup*
make_menu_actions(const char *path, const menu_item_t *menu_item_data) {
GtkActionGroup *action_group;
@@ -3775,11 +3777,11 @@
return action_group;
}
-
+#endif
static void
merge_lua_menu_items(GList *merge_lua_menu_items_list _U_) { -#ifdef
HAVE_LUA_5_1
+#ifdef HAVE_LUA
guint merge_id;
GtkActionGroup *action_group;
menu_item_t *menu_item_data;
___
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] working with header data
I've written a dissector for a protocol (ANSI C12.22) which employs cryptography for both assuring the integrity of the message (including the unencrypted header) and the confidentiality of the payload (by encrypting it). It uses what's called an AEAD (Authenticated Encryption with Associated Data) mode. The cryptography part is working just fine, but there have been questions about what the code is doing mucking about in the header, so I'll try to both answer that here and also try to ask if there is any better way to do it. (To be very clear, I'm not asking for crypto help, but Wireshark help!) There is a portion of the code called canonify_unencrypted_header(). In order to cryptographically process the ASN.1 components of the header, the data must be canonified. To do this, the dissector must process the pieces of the header in a particular order no matter what order these were actually sent. Additionally, the entire BER encoding must be processed, and not just the data with a [tag, length, value] triplet. I can think of two ways to do this (and indeed, have done it both ways). First, I can rely on the ASN.1 parser to break things into their respective fields and then process the components. This approach has two problems. The first problem is that because the entire encoding must be processed, the tag and length must be reconstructed which is a bit messy and complex. The more serious problem is that to enable filtering based on crypto results (e.g. c1222.crypto_good == true), the code must also work on packets that haven't yet been parsed. For those reasons, this approach was tried and rejected. The second way to do this is to use the contents of the tvb of the whole packet and do this parsing in a memory copy. This also has some drawbacks. First, because the packet may or may not be parsed, the routine is either handed an unparsed entire packet, or the user_information element within a parsed packet. To accomodate either, the code does a test to see if it's a user_information element, and if so, navigates to the grandmother node which is the entire packet. The code to do that looks like this: if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information) pkt_tree = proto_item_get_parent_nth(tree, 2); else pkt_tree = tree; Second, operating on a copy of the tvb in memory requires intruding deep into the structure of a pnode, which I have isolated to a single line of code, but it's not pretty: /* fetch a memory copy of the data for processing */ hdr = tvb_memdup(PNODE_FINFO(pkt_tree)-ds_tvb, PNODE_FINFO(pkt_tree)-start, PNODE_FINFO(pkt_tree)-length); for (i=0; canonifyTable[i].hf_id != NULL; i++) status |= find_and_copy_element_raw(hdr, PNODE_FINFO(pkt_tree)-length, canonbuff, offset, length, i, key_id); g_free(hdr); This code works and has been fuzz tested as well on multiple platforms (Windows Linux). If there's a better way to do this, please let me know what that might be. For reference the whole of the source code and sample data are here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531 Ed ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
Hi Martin/Anders, Actually, the valid #define for Lua code throughout Wireshark is HAVE_LUA_5_1 (not HAVE_LUA). HAVE_LUA works in Windows but not other OS's (such as OSX). But I do like HAVE_LUA better than a version-specific name because I imagine these names will have to be updated upon switching to newer versions of Lua, especially with 5.2 coming soon (unless there's some version incompatibility). Given that its only called from merge_lua_menu_items(), might make_menu_items() be too generic a function name? It's really named make_menu_actions(). I named the function based on what it does, not based on who calls it. That function (and make_menu_xml()) can easily be used outside the context of Lua menus, and there's nothing about them that fundamentally binds them to Lua. That said, it doesn't matter enough to me if their names include the word lua since they might change at a later point when someone sees wider use for them. -Tony ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
On Fri, Oct 14, 2011 at 4:37 PM, Tony Trinh ton...@gmail.com wrote: Hi Martin/Anders, Actually, the valid #define for Lua code throughout Wireshark is HAVE_LUA_5_1 (not HAVE_LUA). HAVE_LUA works in Windows but not other OS's (such as OSX). But I do like HAVE_LUA better than a version-specific name because I imagine these names will have to be updated upon switching to newer versions of Lua, especially with 5.2 coming soon (unless there's some version incompatibility). Given that its only called from merge_lua_menu_items(), might make_menu_items() be too generic a function name? It's really named make_menu_actions(). I named the function based on what it does, not based on who calls it. That function (and make_menu_xml()) can easily be used outside the context of Lua menus, and there's nothing about them that fundamentally binds them to Lua. That said, it doesn't matter enough to me if their names include the word lua since they might change at a later point when someone sees wider use for them. -Tony Here is the checkin comment (r39424): Make make_menu_actions() static again, but protect with #ifdef HAVE_LUA_5_1 #endif As per discission on wireshark-dev, this function might later see wider use, so don't add 'lua' to the function name. Martin ___ 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] working with header data
On Oct 14, 2011, at 6:03 AM, Ed Beroset wrote: There is a portion of the code called canonify_unencrypted_header(). In order to cryptographically process the ASN.1 components of the header, the data must be canonified. To do this, the dissector must process the pieces of the header in a particular order no matter what order these were actually sent. Additionally, the entire BER encoding must be processed, and not just the data with a [tag, length, value] triplet. I.e., what gets run through the CMAC algorithm is a bunch of BER-encoded data, in a different order than the order in which the data appears in the header? I can think of two ways to do this (and indeed, have done it both ways). First, I can rely on the ASN.1 parser to break things into their respective fields and then process the components. This approach has two problems. The first problem is that because the entire encoding must be processed, the tag and length must be reconstructed which is a bit messy and complex. Could you use #.FN_BODY for each of the fields in question? It looks as if, in the code in question, offset would be the offset of the BER tag for the field; once you've called the appropriate code to dissect the field - %(DEFAULT_BODY) might expand to the function body that would have been there without #.FN_BODY, which might be sufficient - offset will point past it, so you'd have the offset and length of the entire BER-encoded field, and could, for example, copy it with tvb_memcpy(). If you need to wrap BER encodings for sequences, etc. around the individual fields to make a canonicalized composite field, that sounds as if you have to construct a tag in any case. The more serious problem is that to enable filtering based on crypto results (e.g. c1222.crypto_good == true), the code must also work on packets that haven't yet been parsed. Why is that the case? c1222.crypto_good is part of the protocol tree, and gets put there as part of the parsing process. You can put it into the protocol tree at any point in the parsing process, including after all the other parsing has been done. ___ 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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
On Oct 14, 2011, at 8:37 AM, Tony Trinh wrote: Actually, the valid #define for Lua code throughout Wireshark is HAVE_LUA_5_1 (not HAVE_LUA). HAVE_LUA works in Windows but not other OS's (such as OSX). ...which probably means such as UN*Xes; that sounds like a difference between using autoconf and config.nmake. If we don't have a HAVE_LUA definition independent of the Lua version, that sounds like a bug in the configure script. Does CMake define HAVE_LUA, HAVE_LUA_5_1, both, or neither? It's really named make_menu_actions(). I named the function based on what it does, not based on who calls it. That function (and make_menu_xml()) can easily be used outside the context of Lua menus, and there's nothing about them that fundamentally binds them to Lua. That said, it doesn't matter enough to me if their names include the word lua since they might change at a later point when someone sees wider use for them. Someone meaning the Python interface, for example? ___ 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] working with header data
Guy Harris wrote: On Oct 14, 2011, at 6:03 AM, Ed Beroset wrote: There is a portion of the code called canonify_unencrypted_header(). In order to cryptographically process the ASN.1 components of the header, the data must be canonified. To do this, the dissector must process the pieces of the header in a particular order no matter what order these were actually sent. Additionally, the entire BER encoding must be processed, and not just the data with a [tag, length, value] triplet. I.e., what gets run through the CMAC algorithm is a bunch of BER-encoded data, in a different order than the order in which the data appears in the header? It could be, yes. The specification for the standard doesn't prescribe a particular data order for header information, but of course the CMAC algorithm is designed to be sensitive to data order. That leads to the requirement for being able to rearrange the data. I can think of two ways to do this (and indeed, have done it both ways). First, I can rely on the ASN.1 parser to break things into their respective fields and then process the components. This approach has two problems. The first problem is that because the entire encoding must be processed, the tag and length must be reconstructed which is a bit messy and complex. Could you use #.FN_BODY for each of the fields in question? It looks as if, in the code in question, offset would be the offset of the BER tag for the field; once you've called the appropriate code to dissect the field - %(DEFAULT_BODY) might expand to the function body that would have been there without #.FN_BODY, which might be sufficient - offset will point past it, so you'd have the offset and length of the entire BER-encoded field, and could, for example, copy it with tvb_memcpy(). I did two earlier versions of the code that did something like that. One version used knowledge of what the tags are and recalculated the length based on the length of the tvb. The other one looked attempted to verify that the expected tag really was the expected number of bytes ahead of the data. Both versions seemed messy and complex to me. If you need to wrap BER encodings for sequences, etc. around the individual fields to make a canonicalized composite field, that sounds as if you have to construct a tag in any case. The BER encodings (with tag and length) are already part of the incoming data, so they wouldn't need to be constructed for any other purpose. The more serious problem is that to enable filtering based on crypto results (e.g. c1222.crypto_good == true), the code must also work on packets that haven't yet been parsed. Why is that the case? c1222.crypto_good is part of the protocol tree, and gets put there as part of the parsing process. You can put it into the protocol tree at any point in the parsing process, including after all the other parsing has been done. I don't know why that is, but it's what I observe. When I replace this if statement which is in the working code: if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information) pkt_tree = proto_item_get_parent_nth(tree, 2); else pkt_tree = tree; with this one: if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information) pkt_tree = proto_item_get_parent_nth(tree, 2); else return FALSE; The *displayed* values for parsed packets are all correct, but the *filter* does not work. That is, I get a blank screen (no packets selected) no matter what particular value I use in the filter. Maybe you can tell me why this is? Ed ___ 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] working with header data
On Oct 14, 2011, at 1:16 PM, Ed Beroset wrote: I did two earlier versions of the code that did something like that. One version used knowledge of what the tags are and recalculated the length based on the length of the tvb. The other one looked attempted to verify that the expected tag really was the expected number of bytes ahead of the data. Both versions seemed messy and complex to me. So why does not a #.FN_BODY such as int start_offset = offset; int length; $(DEFAULT_BODY) length = offset - start_offset; copy length bytes of stuff starting at start_offset work? No need to know what the tags are, no need to verify anything, from what I can see. The more serious problem is that to enable filtering based on crypto results (e.g. c1222.crypto_good == true), the code must also work on packets that haven't yet been parsed. Why is that the case? c1222.crypto_good is part of the protocol tree, and gets put there as part of the parsing process. You can put it into the protocol tree at any point in the parsing process, including after all the other parsing has been done. I don't know why that is, but it's what I observe. When I replace this if statement which is in the working code: if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information) pkt_tree = proto_item_get_parent_nth(tree, 2); else pkt_tree = tree; with this one: if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information) pkt_tree = proto_item_get_parent_nth(tree, 2); else return FALSE; None of that has anything to do with adding hf_c1222_crypto_good to the protocol tree, which is what is relevant for making a c1222.crypto_good field work; where is the code that adds that to the tree? The *displayed* values for parsed packets are all correct, Where is the c1222.crypto_good field displayed in the protocol tree? (Don't make it a hidden field; making it visible 1) means the user sees it so they don't have to know its name to know how to filter on it in Wireshark - they could just use the add filter and prepare filter menu items; 2) the dissection tells you directly whether the crypto is good or not.) ___ 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] working with header data
Guy Harris wrote:
On Oct 14, 2011, at 1:16 PM, Ed Beroset wrote:
I did two earlier versions of the code that did something like
that. One version used knowledge of what the tags are and
recalculated the length based on the length of the tvb. The other
one looked attempted to verify that the expected tag really was the
expected number of bytes ahead of the data. Both versions seemed
messy and complex to me.
So why does not a #.FN_BODY such as
int start_offset = offset; int length;
$(DEFAULT_BODY)
length = offset - start_offset;
copy length bytes of stuff starting at start_offset
work? No need to know what the tags are, no need to verify anything,
from what I can see.
I understand what you mean, and will experiment. If I can work through
the filter issue, and it works, then this could be a viable replacement.
if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information)
pkt_tree = proto_item_get_parent_nth(tree, 2); else return FALSE;
None of that has anything to do with adding hf_c1222_crypto_good to
the protocol tree, which is what is relevant for making a
c1222.crypto_good field work; where is the code that adds that to
the tree?
It does, but it's a bit indirect. If the call to that function returns
false, it's an indication that the encryption validation failed for some
reason.
The *displayed* values for parsed packets are all correct,
Where is the c1222.crypto_good field displayed in the protocol
tree?
It's around line 889 of packet-c1222-template.c and is only populated if
the packet has a Message Authentication Code (MAC) which is part of how
the cryptography verifies the integrity of the message.
if (hasmac) {
if (tvb_offset_exists(epsem_buffer, local_offset+4-1)) {
yt = proto_tree_add_item(tree, hf_c1222_epsem_mac, epsem_buffer,
local_offset, 4, ENC_NA);
/* now we have enough information to fill in the crypto subtree */
crypto_tree = proto_item_add_subtree(yt, ett_c1222_crypto);
item = proto_tree_add_boolean(crypto_tree,
hf_c1222_epsem_crypto_good, tvb, local_offset, 4, crypto_good);
PROTO_ITEM_SET_GENERATED(item);
item = proto_tree_add_boolean(crypto_tree,
hf_c1222_epsem_crypto_bad, tvb, local_offset, 4, crypto_bad);
PROTO_ITEM_SET_GENERATED(item);
} else {
expert_add_info_format(pinfo, tree, PI_MALFORMED, PI_ERROR,
C12.22 MAC missing);
return offset+len;
}
}
Ed
___
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] [Wireshark-commits] rev 39422: /trunk/gtk/ /trunk/gtk/: main_menubar.c
On Fri, Oct 14, 2011 at 3:50 PM, Guy Harris g...@alum.mit.edu wrote: On Oct 14, 2011, at 8:37 AM, Tony Trinh wrote: Actually, the valid #define for Lua code throughout Wireshark is HAVE_LUA_5_1 (not HAVE_LUA). HAVE_LUA works in Windows but not other OS's (such as OSX). ...which probably means such as UN*Xes; that sounds like a difference between using autoconf and config.nmake. If we don't have a HAVE_LUA definition independent of the Lua version, that sounds like a bug in the configure script. Does CMake define HAVE_LUA, HAVE_LUA_5_1, both, or neither? CMake defines HAVE_LUA_5_1 but not HAVE_LUA. On the other hand, config.nmake defines both, and it's actually the only file to define HAVE_LUA. For reference, there are 3 files that define HAVE_LUA_5_1 and 7 source files that test for it (trivial fix). It's really named make_menu_actions(). I named the function based on what it does, not based on who calls it. That function (and make_menu_xml()) can easily be used outside the context of Lua menus, and there's nothing about them that fundamentally binds them to Lua. That said, it doesn't matter enough to me if their names include the word lua since they might change at a later point when someone sees wider use for them. Someone meaning the Python interface, for example? Yes. Good example. ___ 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
