Re: [Wireshark-dev] how do you get SDP dissector info to useitwithanew dissector?
Hi Luis, Anders,
I was initially looking at using tap info from sdp:
tap_id = find_tap_id(sdp);
if (tap_id){
if (check_col(pinfo-cinfo, COL_INFO) ) {
col_add_fstr( pinfo-cinfo, COL_INFO, SDP tap found);
col_set_fence(pinfo-cinfo, COL_INFO);
}
tap_data =fetch_tapped_data(tap_id,); // what is packet
index?
// hopefully I would have been able to use tap_data for sdp
and get the myprotocol parameters here
}
But right now I'm stuck. A tap_id for SDP is found, but then I'm not sure what
to feed as the index value...is it the same value as shown at the RTP level
i.e. rtp.setup-frame number?
Perhaps the more sensible approach (although this becomes protocol specific) is
to follow example code in SDP where RTP parameters are found and made available
to the RTP dissector. Just as the RTP dissection window shows Stream setup bu
SDP (frame x)] and then the relevant information. The only strange thing in
my opinion is to be modifying the SDP dissector to do that, it would have been
nice if the actual protocol dissector could have declared the relevant
information to the SDP dissector e.g. AMR SDP parameter info in AMR dissector,
RTP SDP info in RTP dissector, guess wireshark is designed otherwise.
Given SDP is not exactly huge, could one perhaps have access to all the info
decoded by SDP via e.g. tap or perhaps conversation ?
i.e. do functionally something like
if find (sdp_data-sdp.fmtp.parameter, nameofprotocolparameter)
string = getstring(nameofprotocolparameter)
parametervalue = getvalue(string)
Isn't there a way for me to get the SDP packet index as e.g. shown at the RTP
dissector level below my protocol (myprotocol/RTP/UDP/IP)(is this done via
subdissection?) and then have access to all the dissected SDP parameters in
that SDP frame i.e. point back at the frame containing the SDP info, have
access to all the relevant parametersis this possible? How?
It seems I have several potential options, I would appreciate your
recommendation on which is best:
1- add newprotocol parameters directly within sdp dissector, make them
available (follow RTP example)
2- use SDP tap to get the fmtp parameter info (is this possible?)
3- within my own packet, work down to the RTP layer, check whether stream setup
by SDP is present, get rtp.setup-frame, call that frame, dissect it, get the
SDP info back
Thanks for any thoughts,
David
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Luis EG Ontanon
Envoyé : mercredi 23 avril 2008 16:09
À : Developer support list for Wireshark
Objet : Re: [Wireshark-dev] how do you get SDP dissector info to useitwithanew
dissector?
beware:
if the dissector gets called in a different way pinfo-private_data may contain
who knows what...
This might be true for all dissectors,
neither the DLT_USER nor K12 do anything with pinfo-private_data and if the
dissector is registered by name they could call it without calling RTP's first.
On Wed, Apr 23, 2008 at 3:53 PM, Anders Broman [EMAIL PROTECTED] wrote:
Hi,
If I understand you correctly (using AMR as example) you have SDP like:
:
a=rtpmap:96 AMR/8000/1\r\n
a=fmtp:96 octet-align=1\r\n
:
Today the SDP dissector reads 96 and connects in to PT 96 which is used by
the RTP dissector to find the PT dissector, AMR in this case.
You would like your PT dissetor to also receive the fmtp parameter, which
actually could be useful for AMR as well.
First I would look into adding this info into the struct:
typedef struct {
gint32 pt[SDP_MAX_RTP_PAYLOAD_TYPES];
gint8 pt_count;
GHashTable *rtp_dyn_payload;
} transport_media_pt_t;
In packet-sdp.c it could then be read out in packet-rtp.c before calling the
PT subdissector and sent as pinfo-private data.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: den 23 april 2008 10:51
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] how do you get SDP dissector info to useitwitha
new dissector?
Hi,
Thanks for your replies.
To (hopefully) clarify the problem statement, here's something more explicit:
Captured packets:
Example 1: no SDP
=
RTP Payload Type 96 (unkown)
RTP Payload Type 97 (unkown)
:
:
:
:
RTP PT 96 (unkown)
RTP PT 97 (unkown)
My plugin has as a preference Payload Type to force dissection, so I use the
following in my code (it works):
dissector_add(rtp.pt, dynamic_payload_type, myprotocol_handle);
So if I enter 96 as my payload type, I get the following for my capture:
MYPROTOCOL (RTP Payload Type 96 (unkown)) - decoded using MYPROTOCOL setup
parameters 1,2,3, from myprotocol_preferences etc.
RTP Payload Type 97 (unkown (unkown))
:
:
:
:
MYPROTOCOL RTP PT 96
Re: [Wireshark-dev] packet-mmse (want to complete OMA 1.2 and add OMA1.3 headers)
Hi Anders, ok I will start working on this then. Thanks for a prompt reply. Regards, Jorge Sanchez On Fri, Apr 25, 2008 at 1:36 PM, Anders Broman [EMAIL PROTECTED] wrote: Hi, The dissector was written by Olivier Biot and hasn't been seeing much change latly I think. You are welcome to submit patches trough bugzilla http://bugs.wireshark.org/bugzilla/ supplying Trace files to verify changes and dong fuzz testing would probably speed up the process Of applying the patches. Adding sample traces and info to the wiki pages are also encouraged. http://wiki.wireshark.org http://wiki.wireshark.org/Multimedia_Messaging_Service_Encapsulation Regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jorge sanchez Sent: den 25 april 2008 13:28 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] packet-mmse (want to complete OMA 1.2 and add OMA1.3 headers) Hi all, need to know who is maintaining this dissector (packet-mmse.c) as it seems that there are missing some OMA 1.2 headers. Also there are no OMA 1.3 headers in this dissector, who is the person to ask cause I would like to add these missing headers to dissector. Regards, Jorge Sanchez ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25170: /trunk/ /trunk/: config.h.win32
[EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25170 User: etxrab Date: 2008/04/24 11:42 PM Log: Flex (v 2.5.35) uses this symbol to exclude unistd.h Directory: /trunk/ ChangesPath Action +5 -0 config.h.win32Modified Unfortunately this only works for some of the lex files. I've fixed the others as described in the bug #2493 comments. I haven't yet committed the changes for this bug because there is still other generated code causing compiler warnings (eg: 'signed/unsigned mismatch'; I'm working through these and hope to commit everything today. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25170: /trunk/ /trunk/:config.h.win32
Hi, Sorry 'bout that but I thought I'd commit my small contribution to get it out of the way... Regards Anders Från: [EMAIL PROTECTED] genom Bill Meier Skickat: fr 2008-04-25 14:36 Till: wireshark-dev@wireshark.org Ämne: Re: [Wireshark-dev] [Wireshark-commits] rev 25170: /trunk/ /trunk/:config.h.win32 [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25170 User: etxrab Date: 2008/04/24 11:42 PM Log: Flex (v 2.5.35) uses this symbol to exclude unistd.h Directory: /trunk/ ChangesPath Action +5 -0 config.h.win32Modified Unfortunately this only works for some of the lex files. I've fixed the others as described in the bug #2493 comments. I haven't yet committed the changes for this bug because there is still other generated code causing compiler warnings (eg: 'signed/unsigned mismatch'; I'm working through these and hope to commit everything today. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev winmail.dat___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how do you get SDP dissector info touseitwithanew dissector?
Perhaps the more sensible approach (although this becomes protocol specific)
is to follow example code in SDP where RTP parameters are found and made
available to the RTP dissector. Just as the RTP dissection window shows
Stream setup bu SDP (frame x)] and then the relevant information. The only
strange thing in my opinion is to be modifying the SDP dissector to do that,
it would have been nice if the actual protocol dissector could have
declared the relevant information to the SDP dissector e.g. AMR SDP
parameter info in AMR dissector, RTP SDP info in RTP dissector, guess
wireshark is designed otherwise.
I'm not sure what you mean, each packet is dissected individually and ech
dissector only has access to the tvb handed to it by the previous dissector.
The packets are ony dissected sequentially the first time the file or capture
is read.
So for a payload dissector to have access to information from a previous packet
with for instance SDP some special measures has to be taken,
Or even lower down in the protocol stack.
The way to go here I think is for the SDP dissector to extract the info and
store it in the conversation data.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: den 25 april 2008 10:25
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] how do you get SDP dissector info touseitwithanew
dissector?
Hi Luis, Anders,
I was initially looking at using tap info from sdp:
tap_id = find_tap_id(sdp);
if (tap_id){
if (check_col(pinfo-cinfo, COL_INFO) ) {
col_add_fstr( pinfo-cinfo, COL_INFO, SDP tap found);
col_set_fence(pinfo-cinfo, COL_INFO);
}
tap_data =fetch_tapped_data(tap_id,); // what is packet
index?
// hopefully I would have been able to use tap_data for sdp
and get the myprotocol parameters here
}
But right now I'm stuck. A tap_id for SDP is found, but then I'm not sure what
to feed as the index value...is it the same value as shown at the RTP level
i.e. rtp.setup-frame number?
Perhaps the more sensible approach (although this becomes protocol specific) is
to follow example code in SDP where RTP parameters are found and made available
to the RTP dissector. Just as the RTP dissection window shows Stream setup bu
SDP (frame x)] and then the relevant information. The only strange thing in
my opinion is to be modifying the SDP dissector to do that, it would have been
nice if the actual protocol dissector could have declared the relevant
information to the SDP dissector e.g. AMR SDP parameter info in AMR dissector,
RTP SDP info in RTP dissector, guess wireshark is designed otherwise.
Given SDP is not exactly huge, could one perhaps have access to all the info
decoded by SDP via e.g. tap or perhaps conversation ?
i.e. do functionally something like
if find (sdp_data-sdp.fmtp.parameter, nameofprotocolparameter)
string = getstring(nameofprotocolparameter)
parametervalue = getvalue(string)
Isn't there a way for me to get the SDP packet index as e.g. shown at the RTP
dissector level below my protocol (myprotocol/RTP/UDP/IP)(is this done via
subdissection?) and then have access to all the dissected SDP parameters in
that SDP frame i.e. point back at the frame containing the SDP info, have
access to all the relevant parametersis this possible? How?
It seems I have several potential options, I would appreciate your
recommendation on which is best:
1- add newprotocol parameters directly within sdp dissector, make them
available (follow RTP example)
2- use SDP tap to get the fmtp parameter info (is this possible?)
3- within my own packet, work down to the RTP layer, check whether stream setup
by SDP is present, get rtp.setup-frame, call that frame, dissect it, get the
SDP info back
Thanks for any thoughts,
David
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Luis EG Ontanon
Envoyé : mercredi 23 avril 2008 16:09 À : Developer support list for Wireshark
Objet : Re: [Wireshark-dev] how do you get SDP dissector info to useitwithanew
dissector?
beware:
if the dissector gets called in a different way pinfo-private_data may contain
who knows what...
This might be true for all dissectors,
neither the DLT_USER nor K12 do anything with pinfo-private_data and if the
dissector is registered by name they could call it without calling RTP's first.
On Wed, Apr 23, 2008 at 3:53 PM, Anders Broman [EMAIL PROTECTED] wrote:
Hi,
If I understand you correctly (using AMR as example) you have SDP like:
:
a=rtpmap:96 AMR/8000/1\r\n
a=fmtp:96 octet-align=1\r\n
:
Today the SDP dissector reads 96 and connects in to PT 96 which is used by
the RTP dissector to find the PT dissector, AMR in this case.
You would like your PT dissetor to also receive the fmtp parameter, which
[Wireshark-dev] Development environment on Windows XP
Hello everybody, I've read on the wiki that the installation of an development environment as mentioned in the developer's guide doesn't work. Is it right or not? Is it possible? And how? Thanks in advance Julien ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Development environment on Windows XP
Hi, Eh what? It is supposed to work. What wiki page are you referring too? Thanx, Jaap Auvray Julien wrote: Hello everybody, I’ve read on the wiki that the installation of an development environment as mentioned in the developer’s guide doesn’t work. Is it right or not? Is it possible? And how? Thanks in advance Julien ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
[EMAIL PROTECTED] wrote: Log: Fixed some old problems found while starting to add R7 support. +186 -33 packet-umts_fp.cModified I expect that the next buildbot Windows compile of packet-umts_fp will fail (since it does on my Windows system): packet-umts_fp.c(861) : warning C4244: 'function' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible s of data Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
Bill Meier wrote: I expect that the next buildbot Windows compile of packet-umts_fp will fail (since it does on my Windows system): packet-umts_fp.c(861) : warning C4244: 'function' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible s of data Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' If credits is really 11 bits long (i.e., if that call to proto_tree_add_bits_ret_val() will never put a value 2047 into credits), it could be cast to a guint (with a comment explaining this), which should suppress the warning. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Fri, Apr 25, 2008 at 8:08 PM, Guy Harris [EMAIL PROTECTED] wrote: Bill Meier wrote: I expect that the next buildbot Windows compile of packet-umts_fp will fail (since it does on my Windows system): packet-umts_fp.c(861) : warning C4244: 'function' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible s of data Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' If credits is really 11 bits long (i.e., if that call to proto_tree_add_bits_ret_val() will never put a value 2047 into credits), it could be cast to a guint (with a comment explaining this), which should suppress the warning. Yes, have done now (you shamed me into going back to add a comment). Does anyone know of a gcc flag we can add to catch cases like this? It (obviously) compiled clean on my work machine. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] 1.0.0 source code build failure in Visual C++ 6 on Win XP
Hello I'm following the Win32 step-by-step guide in developer's guide. I repeat the guide on 3 different Win XPs and get the same build error. The last PC has Windows freshly installed. I've searched around the mailing list but haven't found a solution. I get the following errors when doing nmake -f Makefile.nmake all. If requested, I can attach a log of all commands I did. I do have Visual Studio Service Pack 6 installed. And I did do a distclean before all. I also tried wireshark-1.0.99-SVN-25163.tar.gz on one of the PC and got the same error messages. I have python 2.5 native installed. Any help is appreciated! Generating Code... Compiling... ascend-grammar.c ascend-scanner.c ascend-scanner.c(1737) : error C2220: warning treated as error - no object file generated ascend-scanner.c(1737) : warning C4003: not enough actual parameters for macro ' ascendwrap' ascend-scanner.c(2072) : warning C4003: not enough actual parameters for macro ' ascendwrap' k12text.c k12text.c(967) : fatal error C1083: Cannot open include file: 'unistd.h': No suc h file or directory file_util.c Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~4\VC98\BIN\NMAKE.EXE' : return co de '0x2' Stop. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] 1.0.0 source code build failure in Visual C++ 6 on Win XP
Hi, I think you been bitten by this bug: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493 Thanx, Jaap net dude wrote: Hello I'm following the Win32 step-by-step guide in developer's guide. I repeat the guide on 3 different Win XPs and get the same build error. The last PC has Windows freshly installed. I've searched around the mailing list but haven't found a solution. I get the following errors when doing nmake -f Makefile.nmake all. If requested, I can attach a log of all commands I did. I do have Visual Studio Service Pack 6 installed. And I did do a distclean before all. I also tried wireshark-1.0.99-SVN-25163.tar.gz on one of the PC and got the same error messages. I have python 2.5 native installed. Any help is appreciated! Generating Code... Compiling... ascend-grammar.c ascend-scanner.c ascend-scanner.c(1737) : error C2220: warning treated as error - no object file generated ascend-scanner.c(1737) : warning C4003: not enough actual parameters for macro ' ascendwrap' ascend-scanner.c(2072) : warning C4003: not enough actual parameters for macro ' ascendwrap' k12text.c k12text.c(967) : fatal error C1083: Cannot open include file: 'unistd.h': No suc h file or directory file_util.c Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~4\VC98\BIN\NMAKE.EXE' : return co de '0x2' Stop. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] 1.0.0 source code build failure in Visual C++ 6 on Win XP
Jaap Keuter wrote: Hi, I think you been bitten by this bug: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493 Unfortunately this is a problem related to the use of cygwin flex 2.5.35 which was very recently noticed. Please see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493. The Wireshark source code has been changed to fix the build errors as of a little while ago. You can either 1. apply one of the work-arounds given in comment #15 of the bug report or: 2. Down load a current source tarball from http://www.wireshark.org/download/automated/src/ Note that you will need a source tarball for SVN 25178 or greater. This should appear at the above URL within an hour or two. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
Martin Mathieson wrote: Does anyone know of a gcc flag we can add to catch cases like this? It (obviously) compiled clean on my work machine. I have a vague memory that newer versions of GCC (4.2? 4.3?) might have a -W flag to catch implicit narrowing conversations, but I didn't see anything obvious in the 4.3 manual; I might instead be remembering a discussion that adding support for this would be a good idea, such as http://www.cs.berkeley.edu/~wychen/cs261/proposal.htm or http://gcc.gnu.org/ml/gcc/2004-06/msg01365.html ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Preference to display hidden protocol items
[EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25108 User: stig Date: 2008/04/17 11:14 PM Log: Added an option to display hidden protocol items. Should this be an item in the View menu, and saved in the recent file? Are there any other preference items that might belong in the View menu? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
Guy Harris wrote: Martin Mathieson wrote: Does anyone know of a gcc flag we can add to catch cases like this? It (obviously) compiled clean on my work machine. I have a vague memory that newer versions of GCC (4.2? 4.3?) might have a -W flag to catch implicit narrowing conversations, but I didn't see anything obvious in the 4.3 manual; I might instead be remembering a discussion that adding support for this would be a good idea, such as http://www.cs.berkeley.edu/~wychen/cs261/proposal.htm If Figure 1 is really a problem then my understanding of C just went out the window... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] buildbot failure in Wireshark (development) on Windows-XP-x86
The Buildbot has detected a new failure of Windows-XP-x86 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/Windows-XP-x86/builds/4281 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: windows-xp-x86 Build Reason: Build Source Stamp: HEAD Blamelist: martinm,wmeier BUILD FAILED: failed shell_5 sincerely, -The Buildbot ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] 1.0.0 source code build failure in Visual C++ 6 on Win XP
Jaap Tried gnuwin32 flex according comment #15 and it works flawlessly. Thanks! On Fri, Apr 25, 2008 at 12:37 PM, Bill Meier [EMAIL PROTECTED] wrote: Jaap Keuter wrote: Hi, I think you been bitten by this bug: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493 Unfortunately this is a problem related to the use of cygwin flex 2.5.35 which was very recently noticed. Please see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493. The Wireshark source code has been changed to fix the build errors as of a little while ago. You can either 1. apply one of the work-arounds given in comment #15 of the bug report or: 2. Down load a current source tarball from http://www.wireshark.org/download/automated/src/ Note that you will need a source tarball for SVN 25178 or greater. This should appear at the above URL within an hour or two. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Fri, Apr 25, 2008 at 10:17 PM, Jeff Morriss
[EMAIL PROTECTED] wrote:
Guy Harris wrote:
http://www.cs.berkeley.edu/~wychen/cs261/proposal.htm
If Figure 1 is really a problem then my understanding of C just went out
the window...
I wouldn't have got this by myself without the explanation but if you
read the code as:
typedef unsigned short uid_t;
void dowork(uid_t u);
int main() {
int x = read_from_network();
// Squish root (it's not safe to execute dowork() with uid 0)
if ( (x 0x) == 0) exit(1);
// ^
dowork(x);
}
you would have noticed the issue.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Fri, Apr 25, 2008 at 7:49 PM, Luis EG Ontanon [EMAIL PROTECTED] wrote:
On Fri, Apr 25, 2008 at 10:17 PM, Jeff Morriss
[EMAIL PROTECTED] wrote:
Guy Harris wrote:
http://www.cs.berkeley.edu/~wychen/cs261/proposal.htmhttp://www.cs.berkeley.edu/%7Ewychen/cs261/proposal.htm
If Figure 1 is really a problem then my understanding of C just went out
the window...
I wouldn't have got this by myself without the explanation but if you
read the code as:
typedef unsigned short uid_t;
void dowork(uid_t u);
int main() {
int x = read_from_network();
// Squish root (it's not safe to execute dowork() with uid 0)
if ( (x 0x) == 0) exit(1);
// ^
dowork(x);
}
you would have noticed the issue.
I get what he's saying but I just don't get it: why would the compiler
convert from int to unsigned short *before* it has to send the value into
the call to dowork()? E.g., 'x' should be an int until I (explicitly or
implicitly) cast it to something else, non? Actually it should still be an
int after the call to dowork(); it just won't be an int when dowork() gets
it.
Maybe I need to go back to school because I'm feeling very noobish right
now.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Sat, Apr 26, 2008 at 3:34 AM, Jeff Morriss [EMAIL PROTECTED] wrote: I get what he's saying but I just don't get it: why would the compiler convert from int to unsigned short *before* it has to send the value into the call to dowork()? E.g., 'x' should be an int until I (explicitly or implicitly) cast it to something else, non? Actually it should still be an int after the call to dowork(); it just won't be an int when dowork() gets it. Maybe I need to go back to school because I'm feeling very noobish right now. function arguments are automatically cast when passed, you can see the reason why this is done in printf when you pass a long long instead of an int for a %i or a %d. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171:/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
Does this help - in particular the read_from_network() function and
comments I added?
- Chris
#include stdio.h
#include stdlib.h
typedef unsigned short uid_t;
static void dowork(uid_t u);
static int read_from_network(void);
int main(int argc, char **argv)
{
int x;
x = read_from_network();
/* Squish root (it's not safe to execute dowork() with uid(0) */
if ( x == 0 )
{
printf(Uid %u not allowed.\n, x);
exit(1);
}
dowork(x);
return (0);
} /* main() */
static void dowork(uid_t u)
{
printf(Doing work as uid %u.\n, u);
} /* dowork() */
static int read_from_network(void)
{
/* I'm a sneaky guy and exploited the fact that the return value
* is an int, although I know only the lower 16 bits will be used.
* This is how I can end up doing work as root. */
return (0x);
} /* read_from_network() */
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Morriss
Sent: Friday, April 25, 2008 9:34 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
25171:/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Fri, Apr 25, 2008 at 7:49 PM, Luis EG Ontanon [EMAIL PROTECTED]
wrote:
On Fri, Apr 25, 2008 at 10:17 PM, Jeff Morriss
[EMAIL PROTECTED] wrote:
Guy Harris wrote:
http://www.cs.berkeley.edu/~wychen/cs261/proposal.htm
http://www.cs.berkeley.edu/%7Ewychen/cs261/proposal.htm
If Figure 1 is really a problem then my understanding of C just went
out
the window...
I wouldn't have got this by myself without the explanation but if you
read the code as:
typedef unsigned short uid_t;
void dowork(uid_t u);
int main() {
int x = read_from_network();
// Squish root (it's not safe to execute dowork() with uid 0)
if ( (x 0x) == 0) exit(1);
// ^
dowork(x);
}
you would have noticed the issue.
I get what he's saying but I just don't get it: why would the compiler
convert from int to unsigned short *before* it has to send the value
into the call to dowork()? E.g., 'x' should be an int until I
(explicitly or implicitly) cast it to something else, non? Actually it
should still be an int after the call to dowork(); it just won't be an
int when dowork() gets it.
Maybe I need to go back to school because I'm feeling very noobish right
now.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
