Re: [Wireshark-dev] Build Failure.Please help!!
Hi Do you mean on win32 platform, in the main directory wireshark-1.0.0, the wireshark executable which is created will not work as all the required dlls are not copies to this directory and as a result on launching it complains saying that "some dll files not found"? Its works fine from gtk directories though as of course during in the end build process all dll and required dependencies are xcopied to these gtk directories. Thanks Hemant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Meier Sent: Tuesday, June 10, 2008 4:44 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Build Failure.Please help!! Tobias Wärre wrote: > Hi > I'm not fully immersed of the details of the build process, but I think (well > know, but I'm a > bit modest... ;) ) it has to do with dependencies. > The C:\wireshark-1.0.0\ folder and all subfolders except > for those created during a > build (to see the effect do a 'nmake -f Makefile.nmake distclean' > and then a 'nmake -f Makefile.nmake all' > and watch what folders that are created). In the end of the build, all > necessary files are > copied (using xcopy in windows) into /wireshark-gtk-1 and /wireshark-gtk2 and > in those folders all dependencies are on the right places. > The C:\wireshark-1.0.0\ is only a placeholder of the development files until > the build is ready. > > Was I fussy or (or perhaps even wrong) somewhere? If so, please say that. > You are quite correct: the wireshark-gt? directories are especially created and populated to contain all the dependencies (dlls and etc) required to run wireshark, tshark & etc on Windows in the development environment. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Failure.Please help!!
Tobias Wärre wrote: > Hi > I'm not fully immersed of the details of the build process, but I think (well > know, but I'm a > bit modest... ;) ) it has to do with dependencies. > The C:\wireshark-1.0.0\ folder and all subfolders except > for those created during a > build (to see the effect do a 'nmake -f Makefile.nmake distclean' > and then a 'nmake -f Makefile.nmake all' > and watch what folders that are created). In the end of the build, all > necessary files are > copied (using xcopy in windows) into /wireshark-gtk-1 and /wireshark-gtk2 and > in those folders all dependencies are on the right places. > The C:\wireshark-1.0.0\ is only a placeholder of the development files until > the build is ready. > > Was I fussy or (or perhaps even wrong) somewhere? If so, please say that. > You are quite correct: the wireshark-gt? directories are especially created and populated to contain all the dependencies (dlls and etc) required to run wireshark, tshark & etc on Windows in the development environment. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Ged125 protocol
On Jun 10, 2008, at 2:20 PM, Martin Corraine (mcorrain) wrote: > My second question: Can I call the TCP dissector if the ged125 is > based off of TCP? "Based off of TCP" in what sense? If it runs over TCP, just as, for example, HTTP runs over TCP, the TCP dissector will call *your* dissector (or, as they'd say on Slashdot, "in Soviet Russia, TCP calls you!"). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] DISSECTOR_ASSERT vs. expert_add_info vs. MALFORMED packets
On Jun 10, 2008, at 1:07 PM, [EMAIL PROTECTED] wrote: > In order to better help the end user reading captures, I'm trying to > set hints, when decoding problems arise, due to packet data. > > My first attempt was using DISSECTOR_ASSERT(), but this causes a > 'bug in dissector'. After reading a thread the dev-archive, this is > apparently by design, but about 50% of the DISSECTOR_ASSERT() code > lines I came across are to catch somewhat expected data errors. If that's true, that's a bug. DISSECTOR_ASSERT() is to use to catch dissector *bugs*, i.e. stuff that "shouldn't happen" no matter *what* problems there are in the data, as per http://www.wireshark.org/lists/wireshark-dev/200704/msg00233.html "You should never call DISSECTOR_ASSERT() for bad packet data. DISSECTOR_ASSERT() should only be used to detect bad dissector code(e.g. causing an endless recursion)." and http://www.wireshark.org/lists/wireshark-dev/200704/msg00234.html "You're correct - neither g_assert() nor DISSECTOR_ASSERT() are appropriate for problems with packet data. An assert is something that should be used to test something that should *always* be true - i.e., there's an error in the code if it's not true. That applies to assert(), g_assert(), and DISSECTOR_ASSERT() - and to any DISSECTOR_ASSERT_... macro." > As suggested there, I switched to expert_add_info, but with the > result, that my packets are not marked MALFORMED, which I think is a > pity. The "malformed" indication originally referred only to packets that were too short, so that the dissector, when trying to dissect a field that is supposed to be there, or a variable-length field that has a specified length, or..., gets an exception thrown by the tvbuff code. There is now also the PI_MALFORMED expert information group. The two are, confusingly, not connected. There should probably be a way to look for various expert info indications with a display filter - and that could perhaps replace the existing "malformed" "protocol". The various exceptions that would cause a "malformed" indication could enter an item into the protocol tree with the expert info in question attached to it. > - Is there a 'best practice' to MALFORMED PACKETS without 'bug in > dissector'? There's a *current* practice, which is to lookup the "malformed" protocol and put an entry into the protocol tree for that "protocol". Whether that's the *best* practice is another matter. > - In case nobody is working on 'DISSECTOR_VERIFY_DATA' yet, I'm > willing to contribute code, but so far only worked on a dissector > for a while. In addition I am not really an exception handler > specialist, and I guess, this is pretty core code. A rough hint of > what would need to be done could maybe get me started. Note that not all protocol problems should throw an exception; for example, if a protocol has an "XYZZY" TLV, which always has a 4-byte integer value, but the packet has an XYZZY TLV with a value length of 8, that should be reported as a malformed TLV, *but* the dissector can skip that TLV (as it has the length) and keep dissecting TLVs. Thus, DISSECTOR_VERIFY_DATA() shouldn't *always* be what's used to report packet problems; it should only be used to report packet problems that prevent any further dissection of the packet. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Ged125 protocol
Hello all, I'm trying to write the dissector for Cisco's ged125 protocol. Cisco gave this as my first project. Anyways, I need some help. I'm confused on the general process for writing the dissectors. (I have already built wireshark) I have found skeleton dissector templates and they are pretty good. The part that I'm stuck on is the function that actually dissects the packets. I have the specs on the packets but don't know where to go from there. Can anyone briefly explain the process? My second question: Can I call the TCP dissector if the ged125 is based off of TCP? Again, any advice would be greatly appreciated. Thanks, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] DISSECTOR_ASSERT vs. expert_add_info vs. MALFORMED packets
Hi, The intention is to have Wireshark accept and process every network packet it gets tossed. Still it's software written by humans, so certain cases aren't handled. To cover these problems an exception mechanism was created. The DISSECTOR_ASSERT() and MALFORMED clauses are really for exceptions. The proper way to guide users to detected problems is the expert info system. Using the correct severity level, group and text gives the user the right amount of hints (color coded packet detail line, indicator in status bar [development version] and entry in expert info overview|details). If you must, you can always add text to the tree_item, or in the info column. Thanx, Jaap [EMAIL PROTECTED] wrote: > In order to better help the end user reading captures, I'm trying to set > hints, when decoding problems arise, due to packet data. > > My first attempt was using DISSECTOR_ASSERT(), but this causes a 'bug in > dissector'. After reading a thread the dev-archive, this is apparently by > design, but about 50% of the DISSECTOR_ASSERT() code lines I came across are > to catch somewhat expected data errors. > > As suggested there, I switched to expert_add_info, but with the result, that > my packets are not marked MALFORMED, which I think is a pity. > > And the suggested Macro DISSECTOR_VERIFY_DATA is not written yet. > > The other suggested workaround to ask for a silly amount of data, does not > really sound the way I'd like to go. > > > - Is there a 'best practice' to MALFORMED PACKETS without 'bug in dissector'? > > - In case nobody is working on 'DISSECTOR_VERIFY_DATA' yet, I'm willing to > contribute code, but so far only worked on a dissector for a while. In > addition I am not really an exception handler specialist, and I guess, this > is pretty core code. A rough hint of what would need to be done could maybe > get me started. > > Regards > David ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] DISSECTOR_ASSERT vs. expert_add_info vs. MALFORMED packets
In order to better help the end user reading captures, I'm trying to set hints, when decoding problems arise, due to packet data. My first attempt was using DISSECTOR_ASSERT(), but this causes a 'bug in dissector'. After reading a thread the dev-archive, this is apparently by design, but about 50% of the DISSECTOR_ASSERT() code lines I came across are to catch somewhat expected data errors. As suggested there, I switched to expert_add_info, but with the result, that my packets are not marked MALFORMED, which I think is a pity. And the suggested Macro DISSECTOR_VERIFY_DATA is not written yet. The other suggested workaround to ask for a silly amount of data, does not really sound the way I'd like to go. - Is there a 'best practice' to MALFORMED PACKETS without 'bug in dissector'? - In case nobody is working on 'DISSECTOR_VERIFY_DATA' yet, I'm willing to contribute code, but so far only worked on a dissector for a while. In addition I am not really an exception handler specialist, and I guess, this is pretty core code. A rough hint of what would need to be done could maybe get me started. Regards David ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SMTP: Extracting parametrs
Dear Steve, Thank you very much for you help. Yes, I created gtk/export_object_smtp.c ,gtk/export_object2.c, export_object2.h and packet-smtp.h similar to gtk/export_object_http.c ,gtk/export_object.c,export_object.h and packet-http.h. and it dissplays some thing unreadable characters. But i doubt about retrieving the parameters from the packet-smtp.c(dissect_smtp_data) fuction which is used to display the data line by line to the protocol tree. Do u think it is possible to retrieve these value from that function using tap mechanism? Thank u in advance. with best regards, On Mon, Jun 9, 2008 at 9:10 PM, Stephen Fisher <[EMAIL PROTECTED]> wrote: > On Fri, Jun 06, 2008 at 09:03:43PM +0300, goitom kahsay wrote: > > > I retrieved the parameters from the packet-smtp.c /dissect_smtp_data > > fuction which is used to display the data line by line at the protocol > > tree. i used a tap mechanism as follows. > > > But, the content of the parameter doesnot display on the GUI. Please > > can u help me any idea how to solve this problem. * > > Did you also create a gtk/export_object_smtp.c similar to > gtk/export_object_http.c and also add the new functions in > export_object_smtp.c to the File - Export - Objects menu as "SMTP" ? > > > Steve > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > -- Benice2all ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Failure.Please help!!
Hi I'm not fully immersed of the details of the build process, but I think (well know, but I'm a bit modest... ;) ) it has to do with dependencies. The C:\wireshark-1.0.0\ folder and all subfolders except for those created during a build (to see the effect do a 'nmake -f Makefile.nmake distclean' and then a 'nmake -f Makefile.nmake all' and watch what folders that are created). In the end of the build, all necessary files are copied (using xcopy in windows) into /wireshark-gtk-1 and /wireshark-gtk2 and in those folders all dependencies are on the right places. The C:\wireshark-1.0.0\ is only a placeholder of the development files until the build is ready. Was I fussy or (or perhaps even wrong) somewhere? If so, please say that. Regards, Tobias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kumar, Hemant Sent: den 10 juni 2008 18:42 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Build Failure.Please help!! Hi I am unable to launch wireshark.exe from C:\wireshark-1.0.0\ but able to successfully do it from C:\wireshark-1.0.0\wireshark-gtk1 Or C:\wireshark-1.0.0\wireshark-gtk2. Thanks Hemant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Fisher Sent: Monday, June 09, 2008 9:16 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Build Failure.Please help!! On Fri, Jun 06, 2008 at 10:28:40AM -0700, Kumar, Hemant wrote: > But now on launching the application it says that it is unable to > locate wiretap-0.3.1.dll though it is present in the following > locations:-- > > C:\wireshark-1.0.0\wiretap > C:\wireshark-1.0.0\wireshark-gtk1 > C:\wireshark-1.0.0\wireshark-gtk2 > > Can you please tell what I need to do to overcome this? Are you launching wireshark.exe from the c:\wireshark-1.0.0\wireshark-gtk2\ (or -gtk1) folder? Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
On Tue, Jun 10, 2008 at 04:21:52PM +0200, Guillaume Bienkowski wrote:
> Argh, I just poorly explained myself: I was just confused with Ethernet
> and IP.
>
> So I confirm, I get only "data" from the 3rd layer (IP)
> Actually, it will always be IP datagrams, so I don't have to bother with
> IPX or other fancy 3rd layer protocols).
>
> What I'd like to do now to start the dissection from the 3rd layer, so
> that I only have one modification to do (the "ip" dissector).
You need to use the DLT_RAW encapsulation type. Read pcap(3) to see what
DLT_RAW is.
I don't see why you'd have to modify any dissectors or anything in the
wireshark source code for this task.
Give something like this a try (this code snippet assumes all the
libwireshark initializations have been done already):
--
static void
fill_in_framedata(frame_data *fdata, size_t len, int ll_type)
{
struct timeval ts;
gettimeofday(&ts, NULL);
fdata->next = NULL;
fdata->prev = NULL;
fdata->pfd = NULL;
fdata->num = 0;
fdata->pkt_len = len;
fdata->cum_bytes = 0;
fdata->cap_len = len;
fdata->file_off = 0;
fdata->lnk_t = wtap_pcap_encap_to_wtap_encap(ll_type);
fdata->abs_ts.secs = ts.tv_sec;
fdata->abs_ts.nsecs = ts.tv_usec*1000;
fdata->flags.passed_dfilter = 0;
fdata->flags.encoding = CHAR_ASCII;
fdata->flags.visited = 0;
fdata->flags.marked = 0;
fdata->flags.ref_time = 0;
fdata->color_filter = NULL;
nstime_set_unset(&fdata->rel_ts);
nstime_set_unset(&fdata->del_cap_ts);
nstime_set_unset(&fdata->del_dis_ts);
}
/* Free up all data attached to a "frame_data" structure. */
static void
clear_fdata(frame_data *fdata)
{
if (fdata->pfd)
g_slist_free(fdata->pfd);
}
/* Dissects IP packet with no layer 2 information. */
epan_dissect_t *
pkt_dissect(char *pkt, size_t len)
{
epan_dissect_t *edt;
frame_data fdata;
union wtap_pseudo_header pseudo_header;
memset(&pseudo_header, 0, sizeof(pseudo_header) );
fill_in_framedata(&fdata, len, DLT_RAW);
edt = epan_dissect_new(1 /* create_proto_tree */,
1 /* proto_tree_visible */);
epan_dissect_run(edt, &pseudo_header, pkt, &fdata, NULL);
clear_fdata(&fdata);
return edt;
}
int
main(void)
{
epan_dissect_t *edt;
size_t len;
/* Initialize libwireshark */
...
/* Get a packet */
pkt = pkt_read(..., &len);
/* Dissect packet. Only IP packets without L2 information.
pkt points to the IP header. len is the length of the
packet (size of IP header + size of payload.) */
edt = pkt_dissect(pkt, len);
handle_dissection_results(edt);
epan_dissect_free(edt);
return 0;
}
--
Let us know how it goes.
Cheers,
Eloy Paris.-
netexpect.org
>
> What I don't understand is how to make the IP protocol register itself
> as a "1st layer" protocol (meaning: the dissection should start by
> seeking IP headers).
>
> The packet-ip.c has this:
>
>
> void
> proto_reg_handoff_ip(void)
> {
> dissector_handle_t ip_handle;
>
> data_handle = find_dissector("data");
> ip_handle = find_dissector("ip");
> tapa_handle = find_dissector("tapa");
> dissector_add("ethertype", ETHERTYPE_IP, ip_handle);
> dissector_add("ppp.protocol", PPP_IP, ip_handle);
> dissector_add("ppp.protocol", ETHERTYPE_IP, ip_handle);
> dissector_add("gre.proto", ETHERTYPE_IP, ip_handle);
> dissector_add("gre.proto", GRE_WCCP, ip_handle);
> dissector_add("llc.dsap", SAP_IP, ip_handle);
> dissector_add("ip.proto", IP_PROTO_IPIP, ip_handle);
> dissector_add("null.type", BSD_AF_INET, ip_handle);
> dissector_add("chdlctype", ETHERTYPE_IP, ip_handle);
> dissector_add("osinl.excl", NLPID_IP, ip_handle);
> dissector_add("fr.ietf", NLPID_IP, ip_handle);
> dissector_add("x.25.spi", NLPID_IP, ip_handle);
> dissector_add("arcnet.protocol_id", ARCNET_PROTO_IP_1051,
> ip_handle);
> dissector_add("arcnet.protocol_id", ARCNET_PROTO_IP_1201,
> ip_handle);
> dissector_add_handle("udp.port", ip_handle);
> }
>
> What should I change in there?
>
>
>
> Gilbert Ramirez a écrit :
> >
> > On Tue, Jun 10, 2008 at 7:27 PM, Guillaume Bienkowski
> > <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > What I know is that my packet data will always contain ONLY the 2nd
> > > layer data (Ethernet) and the encapsulated data (TCP, UDP, ...).
> > >
> >
> > I think I misunderstood you. I thought your packets started at IP or
> > IPX. Is that not the case?
> >
> > --gilbert
> > ___
> > Wireshark-dev mailing list
> > Wireshark-dev@wireshark.org
> > https://wireshark.org/mailman/listinfo/wireshark-dev
> >
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> https
[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/builders/Windows-XP-x86/builds/4440 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: windows-xp-x86 Build Reason: Build Source Stamp: HEAD Blamelist: etxrab,jake BUILD FAILED: failed shell_8 sincerely, -The Buildbot ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Failure.Please help!!
Hi I am unable to launch wireshark.exe from C:\wireshark-1.0.0\ but able to successfully do it from C:\wireshark-1.0.0\wireshark-gtk1 Or C:\wireshark-1.0.0\wireshark-gtk2. Thanks Hemant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Fisher Sent: Monday, June 09, 2008 9:16 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Build Failure.Please help!! On Fri, Jun 06, 2008 at 10:28:40AM -0700, Kumar, Hemant wrote: > But now on launching the application it says that it is unable to > locate wiretap-0.3.1.dll though it is present in the following > locations:-- > > C:\wireshark-1.0.0\wiretap > C:\wireshark-1.0.0\wireshark-gtk1 > C:\wireshark-1.0.0\wireshark-gtk2 > > Can you please tell what I need to do to overcome this? Are you launching wireshark.exe from the c:\wireshark-1.0.0\wireshark-gtk2\ (or -gtk1) folder? Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
Argh, I just poorly explained myself: I was just confused with Ethernet
and IP.
So I confirm, I get only "data" from the 3rd layer (IP)
Actually, it will always be IP datagrams, so I don't have to bother with
IPX or other fancy 3rd layer protocols).
What I'd like to do now to start the dissection from the 3rd layer, so
that I only have one modification to do (the "ip" dissector).
What I don't understand is how to make the IP protocol register itself
as a "1st layer" protocol (meaning: the dissection should start by
seeking IP headers).
The packet-ip.c has this:
void
proto_reg_handoff_ip(void)
{
dissector_handle_t ip_handle;
data_handle = find_dissector("data");
ip_handle = find_dissector("ip");
tapa_handle = find_dissector("tapa");
dissector_add("ethertype", ETHERTYPE_IP, ip_handle);
dissector_add("ppp.protocol", PPP_IP, ip_handle);
dissector_add("ppp.protocol", ETHERTYPE_IP, ip_handle);
dissector_add("gre.proto", ETHERTYPE_IP, ip_handle);
dissector_add("gre.proto", GRE_WCCP, ip_handle);
dissector_add("llc.dsap", SAP_IP, ip_handle);
dissector_add("ip.proto", IP_PROTO_IPIP, ip_handle);
dissector_add("null.type", BSD_AF_INET, ip_handle);
dissector_add("chdlctype", ETHERTYPE_IP, ip_handle);
dissector_add("osinl.excl", NLPID_IP, ip_handle);
dissector_add("fr.ietf", NLPID_IP, ip_handle);
dissector_add("x.25.spi", NLPID_IP, ip_handle);
dissector_add("arcnet.protocol_id", ARCNET_PROTO_IP_1051,
ip_handle);
dissector_add("arcnet.protocol_id", ARCNET_PROTO_IP_1201,
ip_handle);
dissector_add_handle("udp.port", ip_handle);
}
What should I change in there?
Gilbert Ramirez a écrit :
>
> On Tue, Jun 10, 2008 at 7:27 PM, Guillaume Bienkowski
> <[EMAIL PROTECTED]> wrote:
>
> >
> > What I know is that my packet data will always contain ONLY the 2nd
> > layer data (Ethernet) and the encapsulated data (TCP, UDP, ...).
> >
>
> I think I misunderstood you. I thought your packets started at IP or
> IPX. Is that not the case?
>
> --gilbert
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> https://wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
On Tue, Jun 10, 2008 at 7:27 PM, Guillaume Bienkowski <[EMAIL PROTECTED]> wrote: > > What I know is that my packet data will always contain ONLY the 2nd > layer data (Ethernet) and the encapsulated data (TCP, UDP, ...). > I think I misunderstood you. I thought your packets started at IP or IPX. Is that not the case? --gilbert ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
Hello,
I *kind of* get what you mean, but I really don't know how to do that.
Let me explain what I do:
I use the wireshark library to analyze the packets I send it. The main
call to the library is done in my code through:
epan_dissect_run(edt, &pseudo_header, FakePacket , &fdata, 0);
where FakePacket is a u_char pointer to a memory place where I have the
packet I'd like to analyze.
After that, FakePacket is changed to point to a new packet which has to
be analyzed as well.
What I know is that my packet data will always contain ONLY the 2nd
layer data (Ethernet) and the encapsulated data (TCP, UDP, ...).
Then what should I do? Modify the packet-eth.c to change the
"wtap_encap" type?
How can I do that? What constant should I choose then?
Thans in advance,
Guillaume
Gilbert Ramirez a écrit :
>
> How do the 2nd-layer dissectors get called normally? Because thy
> register themselves with Wireshark, saying that if "wtap_encap" (the
> wiretap encapsulation) is a certain type, then call them.
>
> for example, from packet-eth.c:
>
>dissector_add("wtap_encap", WTAP_ENCAP_ETHERNET,
> eth_maybefcs_handle);
>
> By whatever method you're feeding your packet traces into Wireshark,
> if you can cause the wiretap encapsulation type to be a new value that
> you create, WTAP_ENCAP_IPX, then you can modify packet-ipx.c to
> register itself against "wtap_encap" == WTAP_ENCAP_IPX. Then the
> dissection will happen start at the IPX level.
>
> --gilbert
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
Hi Guillaume, Perhaps if you can figure out how this mechanism works - http://wiki.wireshark.org/HowToDissectAnything, you could use a similar approach. You could also check wiretap/wtap.h to see if the API you have been provided can produce frames in one of the known types. HTH Abhik. On Tue, Jun 10, 2008 at 3:25 PM, Guillaume Bienkowski <[EMAIL PROTECTED]> wrote: > Hello Guys, > > I have successfully written a program that uses the Wireshark Lib to > dissect some packets. > > The thing is, through the API I was given from my boss, I can only > receive informations from the 3rd layer (IPv4, IPX, ... layer), which > confuses the dissectors, and screws the dissection. > > One solution would be to allocate a temporary buffer which would include > my 3rd layer and above, plus a fake header from the 2 bottom layers; but > this would mean that I'd have to allocate memory for every packet... not > really optimized.. > > Is it possible to use epan_dissect_run() from an upper layer, telling > the library to start dissecting from a packet that has already been > shortened? > > Thanks in advance, > > Guillaume > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] I need help
Dear all, Can anybody tell me that can we change wireshark io_graph plot into -ve x-axis or in -ve y-axis? Please guide me. I am waiting for your answers. Best regards Khurram ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Start Dissection from an upper layer?
How do the 2nd-layer dissectors get called normally? Because thy
register themselves with Wireshark, saying that if "wtap_encap" (the
wiretap encapsulation) is a certain type, then call them.
for example, from packet-eth.c:
dissector_add("wtap_encap", WTAP_ENCAP_ETHERNET, eth_maybefcs_handle);
By whatever method you're feeding your packet traces into Wireshark,
if you can cause the wiretap encapsulation type to be a new value that
you create, WTAP_ENCAP_IPX, then you can modify packet-ipx.c to
register itself against "wtap_encap" == WTAP_ENCAP_IPX. Then the
dissection will happen start at the IPX level.
--gilbert
On Tue, Jun 10, 2008 at 4:55 PM, Guillaume Bienkowski
<[EMAIL PROTECTED]> wrote:
> Hello Guys,
>
> I have successfully written a program that uses the Wireshark Lib to
> dissect some packets.
>
> The thing is, through the API I was given from my boss, I can only
> receive informations from the 3rd layer (IPv4, IPX, ... layer), which
> confuses the dissectors, and screws the dissection.
>
> One solution would be to allocate a temporary buffer which would include
> my 3rd layer and above, plus a fake header from the 2 bottom layers; but
> this would mean that I'd have to allocate memory for every packet... not
> really optimized..
>
> Is it possible to use epan_dissect_run() from an upper layer, telling
> the library to start dissecting from a packet that has already been
> shortened?
>
> Thanks in advance,
>
> Guillaume
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> https://wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Start Dissection from an upper layer?
Hello Guys, I have successfully written a program that uses the Wireshark Lib to dissect some packets. The thing is, through the API I was given from my boss, I can only receive informations from the 3rd layer (IPv4, IPX, ... layer), which confuses the dissectors, and screws the dissection. One solution would be to allocate a temporary buffer which would include my 3rd layer and above, plus a fake header from the 2 bottom layers; but this would mean that I'd have to allocate memory for every packet... not really optimized.. Is it possible to use epan_dissect_run() from an upper layer, telling the library to start dissecting from a packet that has already been shortened? Thanks in advance, Guillaume ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
