Re: [Wireshark-dev] JXTA dissector memory leak?
On Wed, 28.Mar.07 16:41:59 -0700, Stephen Fisher wrote:
The dissector file packet-jxta.c has a comment saying that an allocation
is a memory leak:
if (NULL != found_addr) {
found_addr-type = AT_URI;
found_addr-len = strlen(*current_token);
/* FIXME 20050605 bondolo THIS ALLOCATION IS A MEMORY LEAK! */
found_addr-data = g_strdup(*current_token);
}
Anyone familiar enough with this dissector to fix it easily?
Should be enough just to change g_strdup to ep_strdup or se_strdup.
See README.malloc for more details.
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Expert info missing entries
Team, I came across a problem that is described in posting http://www.wireshark.org/lists/wireshark-dev/200607/msg04326.html I can confirm that the change as described there works, e.g. in expert_dlg_init() I call: cf_redissect_packets(cfile); instead of cf_retap_packets(cfile, FALSE); I was not able to locate any followup on the posting. Is this problem not important? I am adding many expert infos in my dissector, and would like to understand if they should appear in the expert info list or not. Alternatively, can someone try to figure out why the expert_item value is null when performing a retap (this is from the comment in expert_comp_dlg.c)? I am afraid I would need too much time for it. Thanks in advance Andrej ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Getting destination IP
Is your question somehow related to development of Wireshark? I am afraid you are not asking at the best place. Purpose of Wireshark is to analyze packets. The command mentioned below gives brief display of the data. If you do not need all that info, consider using other commands to process it further. Good candidate would be cut. I am not sure what you mean by DNS proxy. I would assume it is some kind of application that will be listening for requests on udp port 53. There should be system calls available to get the address info needed. Hope this helps Andrej On Tue, 20.Mar.07 20:34:09 +0900, sara vanan wrote: Hi, I am doing a DNS proxy for IPV6. For this I have to get the destination IP(DNS Sever IP stored in the client PC. I am trying to use Wireshark source code for getting the desdtination IP. for example client IP - 192.168.16.67DNS ( destination IP) - 192.168.16.106 By using the Wireshark GUI I use DNS filter and it displays source IP destination IP 192.168.16.67192.168.16.106 Request http://192.168.16.106/ then 192.168.16.106 192.168.16.67 Responsehttp://192.168.16.67/ And in LINUX when I am executing with the command /home/saravanan/ethereal- 0.99.0/tethereal -c 10 port 53 [EMAIL PROTECTED] ethereal-0.99.0 ]# /home/saravanan/ethereal-0.99.0/tethereal -c 5 port 53 Capturing on eth0 0.00 192.168.16.67 - 192.168.16.106 DNS Standard query A www.samedi.org 0.004528 192.168.16.106 - 206.51.233.130 DNS Standard query A www.samedi.org 0.177348 206.51.233.130 - 192.168.16.106 DNS Standard query response A 206.51.233.130 0.178324 192.168.16.106 - 192.168.16.67 DNS Standard query response A 206.51.233.130 6.968992 192.168.16.67 - 192.168.16.106 DNS Standard query A statse.webtrendslive.com 6.970539 192.168.16.106 - 220.73.220.4 DNS Standard query A statse.webtrends.akadns.net 7.028039 220.73.220.4 - 192.168.16.106 DNS Standard query response A 63.236.111.50 it displays (www.google.co.in) URL link IP. Instead of this I want to filter only the source IP and destination IP. For this what kind of filters should I use. Kindly help me regarding this. Thanks Saravanan ___ 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] Fun with Cisco DLT-value usage
I believe the issue could be reported to Cisco TAC requesting correction, instead of hacking heuristics. At the other hand, did they announce somewhere that they are using libpcap format? I was googling a bit and found indications how to convert the file http://www.gossamer-threads.com/lists/engine?post=56109;list=cisco In one post is mentioned also that upcoming SW release is expected to create pcap files. Andrej On Thu, 15.Mar.07 20:30:01 -0700, Guy Harris wrote: On Mar 15, 2007, at 8:06 PM, Jeff Morriss wrote: I suppose you'll need heuristics like those described in the (long) comments in wiretap/libpcap.c. Or like the ones in epan/dissectors/packet-null.c. Now, if only the fine folks at Cisco had seen some other comments in that file, such as /* * Either LBL NRG wasn't an adequate central registry (e.g., because of * the slow rate of releases from them), or nobody bothered using them * as a central registry, as many different groups have patched libpcap * (and BPF, on the BSDs) to add new encapsulation types, and have ended * up using the same DLT_ values for different encapsulation types. * * For those numerical encapsulation type values that everybody uses for * the same encapsulation type (which inclues those that some platforms * specify different DLT_ names for but don't appear to use), we map * those values to the appropriate Wiretap values. * * For those numerical encapsulation type values that different libpcap * variants use for different encapsulation types, we check what * pcap.h defined to determine how to interpret them, so that we * interpret them the way the libpcap with which we're building * Wireshark/Wiretap interprets them (which, if it doesn't support * them at all, means we don't support them either - any capture files * using them are foreign, and we don't hazard a guess as to which * platform they came from; we could, I guess, choose the most likely * platform). * * Note: if you need a new encapsulation type for libpcap files, do * *N*O*T* use *ANY* of the values listed here! I.e., do *NOT* * add a new encapsulation type by changing an existing entry; * leave the existing entries alone. * * Instead, send mail to tcpdump-workers@tcpdump.org, asking for a new * DLT_ value, and specifying the purpose of the new value. When you * get the new DLT_ value, use that numerical value in the dlt_value * field of pcap_to_wtap_map[]. */ or /* * To repeat: * * If you need a new encapsulation type for libpcap files, do * *N*O*T* use *ANY* of the values listed here! I.e., do *NOT* * add a new encapsulation type by changing an existing entry; * leave the existing entries alone. * * Instead, send mail to tcpdump-workers@tcpdump.org, asking for * a new DLT_ value, and specifying the purpose of the new value. * When you get the new DLT_ value, use that numerical value in * the dlt_value field of pcap_to_wtap_map[]. */ or, in the bpf.h that comes with libpcap: /* * Data-link level type codes. * * Do *NOT* add new values to this list without asking * tcpdump-workers@tcpdump.org for a value. Otherwise, you run the * risk of using a value that's already being used for some other purpose, * and of having tools that read libpcap-format captures not being able * to handle captures with your new DLT_ value, with no hope that they * will ever be changed to do so (as that would destroy their ability * to read captures using that value for that other purpose). */ ___ 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] [patch] address_to_str_buf not checking available buffer length
Accepted or not, I needed to do something to get my working copy compiled. Attached is the patch if you like to use it. Thanks Andrej On Wed, 31.Jan.07 12:29:30 +0100, Andrej Mikus wrote: On Mon, 29.Jan.07 12:49:00 -0800, Gerald Combs wrote: Andrej Mikus wrote: In file to_str.c I notice function address_to_str_buf that takes buf_len as argument, but does not use it for IPv4 and IPv6 addresses: Unfortunately, there wasn't a mechanism to ensure that the buffer was big enough. I've checked in a change (r20607) that should fix this. It looks like this could potentially affect the ISUP statistics, so I'll add it to the advisory list for 0.99.5. I was planning to propose a patch already (attached), so this allowed me to see how Subversion handles conflicts :-) IMO, the function should return an error string instead of cowardly bailing out with an empty string. inet_ntop does the latter by default, so it does not need any additional check, just passing buf_len instead of INET6_ADDRSTRLEN. At the other side I like the check you made into ip_to_str_buf. My proposal would be to combine the patches and use MAX_IP_STR_LEN, and approach below for both IPv4 and IPv6 in address_to_str_buf. case AT_IPv6: + .mine +if ( inet_ntop(AF_INET6, addr-data, buf, buf_len) == NULL ) /* Returns NULL if no space and does not touch buf */ + g_snprintf ( buf, buf_len, ); /* Let the unexpected value alert user */ If accepted, I am ready to supply a patch on top of current rev .r20649 Let me know pls. Andrej ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev my_patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Bogus length reported for reassembled UDP packets
Hi, Wireshark complains about bogus udp length when processing last fragment of UDP data. It compares length field from UDP header with payload size of last fragment. Attached is my attempt to fix this by referring to tvp-length instead of pinfo-iplen - pinfo-iphdrlen. Not entirely sure if it is the best way, but appears to work for me. Attached is also sample capture file. With reference to my earlier message, do not worry about output above UDP layer. http://www.wireshark.org/lists/wireshark-dev/200701/msg00265.html Regards Andrej wccpfrag.pcap Description: Binary data udplen.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] packet statistics screen
My suggestion would be tshark -z io,stat,60 -q -r capturefile and then sort accordingly. I am new here, but I feel that this type of question is perhaps better for user list rather than dev. Andrej On Wed, 31.Jan.07 12:12:05 -0500, Aamer Akhter wrote: Hello, I'm looking at the ethereal screen in Statistics-Summary and was wondering if there is a way to calculate the highest pps and bitrate within a 1 min window. Right now, the stats seem to be over the entire length of the file... Any other tools that might do this? -- Aamer Akhter / [EMAIL PROTECTED] ___ 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] Prevent recursive IP dissector to fill summary columns
The change is unfortunately not working with HTTP, the dissector is setting COL_INFO as not writable and further modification of the info field fails. Will try to set fence before running sub dissector. Andrej On Sat, 27.Jan.07 02:54:45 +0100, Andrej Mikus wrote: Hi, In the meantime I found Wireshark wishlist and I find my question related to first topic in dissection section at http://wiki.wireshark.org/WishList#head-415ef1ebe1134681b1db49769aa1d8bf027db057 Further check in header files reveals much more info compared to README files. Found that the functionality I was looking for it (partially) achieved by flag in_error_pkt. Also found information about modification of info column. To conclude, the attached patch would be acceptable? Thanks Andrej On Mon, 22.Jan.07 10:37:20 +0100, Andrej Mikus wrote: Team, While troubleshooting wccp traffic it is very useful that Wireshark goes deep into gre redirected packet and pulls the IP address from it. It makes it easy to follow tcp stream also when server responses are not GRE encapsulated. There are however also situations when the IP information from top level is interesting (what router redirected the packet to what wccp client) and I would like to implement a preference setting to get this kind of information. Some questions: - Where this preference should be most logical to place? (ip, gre, wccp) - How to actually implement it? It requires that packet-ip.c when called for second time should not update columns (and fields for display filter), but still continues to build tree for detailed display. Is there any way to find out if the packet being dissected is raw IP packet, or comes from GRE payload? I would like to modify the Info column in all cases to indicate that the packet is redirected, for example by prepending char '' to the info, regardless of dissector that produced it. Is this feasible? I notice that dissectors call col_clear all the time. Is it possible to modify the column after packet is completely dissected? In next step I am thinking of using '' to indicate packet returned back to router, but at this point still need to work out some protocol details. Attached is an example of packet I am concerned about. I hope it would help to assist. Output I would like to get after my changes is as follows: With new preference disabled (current operation): No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19510.254.108.228DCERPC Request: call_id: 1 opnum: 16 ctx_id: 0 New preference enabled (show top level info in summary for wccp redirected frames) No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19410.254.214.82 GREWCCP Redirected frame Frame 1 (282 bytes on wire, 282 bytes captured) Ethernet II, Src: Cisco_3a:ab:40 (00:0f:35:3a:ab:40), Dst: Ibm_28:99:a8 (00:14:5e:28:99:a8) Internet Protocol, Src: 10.254.127.194 (10.254.127.194), Dst: 10.254.214.82 (10.254.214.82) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 268 Identification: 0xac83 (44163) Flags: 0x00 Fragment offset: 0 Time to live: 253 Protocol: GRE (0x2f) Header checksum: 0xa42e [correct] Source: 10.254.127.194 (10.254.127.194) Destination: 10.254.214.82 (10.254.214.82) Generic Routing Encapsulation (WCCP) Flags and version: Protocol Type: WCCP (0x883e) Redirect header 0... = Well-known service .0.. = Alternative bucket not used Service ID: Unknown (0x59) Primary bucket index: 72 Internet Protocol, Src: 10.254.127.195 (10.254.127.195), Dst: 10.254.108.228 (10.254.108.228) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 240 Identification: 0x9114 (37140) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xa650 [correct] Source: 10.254.127.195 (10.254.127.195) Destination: 10.254.108.228 (10.254.108.228) Transmission Control Protocol, Src Port: 1291 (1291), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 188 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1 Ctx: 0 Many thanks for your cooperation Andrej Mikus ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark
Re: [Wireshark-dev] Warning about radius directory
Hi, Thank you guys. Looks like I overlooked the difference in runtime environment. For real use I have still installed Ethereal, and Wireshark is indeed run from build directory only. Sorry for the noise. I hope someone can help me further in main main issue about filling display columns from dissectors at various layers. Andrej On Sat, 27.Jan.07 03:52:25 +0100, Luis Ontanon wrote: On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote: Thanks for comments. Of course, I removed the message to stop coming out after I realized that it is coming before preferences. Creating file in my system does not address this problem for others. Yep but Others usually install either with make install or from a package that has the dictionary. On Fri, 26.Jan.07 18:59:29 -0800, Stephen Fisher wrote: On Sat, Jan 27, 2007 at 12:36:55AM +0100, Andrej Mikus wrote: I notice that wireshark emits unconditionally warning mentioning that it Could not find the radius directory. I assume that you are running Wireshark from its build directory without having a version installed? Guy recently added a feature whereby you can set the environment variable WIRESHARK_RUN_FROM_BUILD_DIRECTORY to 1 in your shell and it will use the directory wireshark is run from as the data directory (where there is a radius/ directory). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Warning about radius directory
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict = radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius directory);
}
g_free(dir);
Thanks
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent recursive IP dissector to fill summary columns
Hi, In the meantime I found Wireshark wishlist and I find my question related to first topic in dissection section at http://wiki.wireshark.org/WishList#head-415ef1ebe1134681b1db49769aa1d8bf027db057 Further check in header files reveals much more info compared to README files. Found that the functionality I was looking for it (partially) achieved by flag in_error_pkt. Also found information about modification of info column. To conclude, the attached patch would be acceptable? Thanks Andrej On Mon, 22.Jan.07 10:37:20 +0100, Andrej Mikus wrote: Team, While troubleshooting wccp traffic it is very useful that Wireshark goes deep into gre redirected packet and pulls the IP address from it. It makes it easy to follow tcp stream also when server responses are not GRE encapsulated. There are however also situations when the IP information from top level is interesting (what router redirected the packet to what wccp client) and I would like to implement a preference setting to get this kind of information. Some questions: - Where this preference should be most logical to place? (ip, gre, wccp) - How to actually implement it? It requires that packet-ip.c when called for second time should not update columns (and fields for display filter), but still continues to build tree for detailed display. Is there any way to find out if the packet being dissected is raw IP packet, or comes from GRE payload? I would like to modify the Info column in all cases to indicate that the packet is redirected, for example by prepending char '' to the info, regardless of dissector that produced it. Is this feasible? I notice that dissectors call col_clear all the time. Is it possible to modify the column after packet is completely dissected? In next step I am thinking of using '' to indicate packet returned back to router, but at this point still need to work out some protocol details. Attached is an example of packet I am concerned about. I hope it would help to assist. Output I would like to get after my changes is as follows: With new preference disabled (current operation): No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19510.254.108.228DCERPC Request: call_id: 1 opnum: 16 ctx_id: 0 New preference enabled (show top level info in summary for wccp redirected frames) No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19410.254.214.82 GREWCCP Redirected frame Frame 1 (282 bytes on wire, 282 bytes captured) Ethernet II, Src: Cisco_3a:ab:40 (00:0f:35:3a:ab:40), Dst: Ibm_28:99:a8 (00:14:5e:28:99:a8) Internet Protocol, Src: 10.254.127.194 (10.254.127.194), Dst: 10.254.214.82 (10.254.214.82) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 268 Identification: 0xac83 (44163) Flags: 0x00 Fragment offset: 0 Time to live: 253 Protocol: GRE (0x2f) Header checksum: 0xa42e [correct] Source: 10.254.127.194 (10.254.127.194) Destination: 10.254.214.82 (10.254.214.82) Generic Routing Encapsulation (WCCP) Flags and version: Protocol Type: WCCP (0x883e) Redirect header 0... = Well-known service .0.. = Alternative bucket not used Service ID: Unknown (0x59) Primary bucket index: 72 Internet Protocol, Src: 10.254.127.195 (10.254.127.195), Dst: 10.254.108.228 (10.254.108.228) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 240 Identification: 0x9114 (37140) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xa650 [correct] Source: 10.254.127.195 (10.254.127.195) Destination: 10.254.108.228 (10.254.108.228) Transmission Control Protocol, Src Port: 1291 (1291), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 188 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1 Ctx: 0 Many thanks for your cooperation Andrej Mikus ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev my_patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Prevent recursive IP dissector to fill summary columns
Team, While troubleshooting wccp traffic it is very useful that Wireshark goes deep into gre redirected packet and pulls the IP address from it. It makes it easy to follow tcp stream also when server responses are not GRE encapsulated. There are however also situations when the IP information from top level is interesting (what router redirected the packet to what wccp client) and I would like to implement a preference setting to get this kind of information. Some questions: - Where this preference should be most logical to place? (ip, gre, wccp) - How to actually implement it? It requires that packet-ip.c when called for second time should not update columns (and fields for display filter), but still continues to build tree for detailed display. Is there any way to find out if the packet being dissected is raw IP packet, or comes from GRE payload? I would like to modify the Info column in all cases to indicate that the packet is redirected, for example by prepending char '' to the info, regardless of dissector that produced it. Is this feasible? I notice that dissectors call col_clear all the time. Is it possible to modify the column after packet is completely dissected? In next step I am thinking of using '' to indicate packet returned back to router, but at this point still need to work out some protocol details. Attached is an example of packet I am concerned about. I hope it would help to assist. Output I would like to get after my changes is as follows: With new preference disabled (current operation): No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19510.254.108.228DCERPC Request: call_id: 1 opnum: 16 ctx_id: 0 New preference enabled (show top level info in summary for wccp redirected frames) No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19410.254.214.82 GREWCCP Redirected frame Frame 1 (282 bytes on wire, 282 bytes captured) Ethernet II, Src: Cisco_3a:ab:40 (00:0f:35:3a:ab:40), Dst: Ibm_28:99:a8 (00:14:5e:28:99:a8) Internet Protocol, Src: 10.254.127.194 (10.254.127.194), Dst: 10.254.214.82 (10.254.214.82) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 268 Identification: 0xac83 (44163) Flags: 0x00 Fragment offset: 0 Time to live: 253 Protocol: GRE (0x2f) Header checksum: 0xa42e [correct] Source: 10.254.127.194 (10.254.127.194) Destination: 10.254.214.82 (10.254.214.82) Generic Routing Encapsulation (WCCP) Flags and version: Protocol Type: WCCP (0x883e) Redirect header 0... = Well-known service .0.. = Alternative bucket not used Service ID: Unknown (0x59) Primary bucket index: 72 Internet Protocol, Src: 10.254.127.195 (10.254.127.195), Dst: 10.254.108.228 (10.254.108.228) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 240 Identification: 0x9114 (37140) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xa650 [correct] Source: 10.254.127.195 (10.254.127.195) Destination: 10.254.108.228 (10.254.108.228) Transmission Control Protocol, Src Port: 1291 (1291), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 188 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1 Ctx: 0 Many thanks for your cooperation Andrej Mikus grepacket.pcap Description: Binary data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Wccp dissector update
Team, I started creating an update for wccp dissector, trying to add support for mask assignment and it looks like that fragment reassembly will be also needed. Thinking also of adding some more possibilities to filter, http://www.wireshark.org/docs/dfref/w/wccp.html Is someone is doing this already, we could perhaps cooperate. I've got source tree downloaded, compiled with some changes and running under Linux. My Windows development experience is quite limited, I used just Cygwin so far. In the documentation I see that gcc under Cygwin can compile Wireshark. Most of users around me are using Windows build of Ethereal or Wireshark. I have also found information about builing Windows binary with Cygwin gcc that does not need cygwin.dll. Is it possible to build an independent plugin with this environment? Many thanks for any cooperation. Andrej Mikus ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build with Cygwin
On Mon, 15.Jan.07 00:09:55 +0100, Ulf Lamping wrote: Andrej Mikus wrote: I've got source tree downloaded, compiled with some changes and running under Linux. My Windows development experience is quite limited, I used just Cygwin so far. In the documentation I see that gcc under Cygwin can compile Wireshark. Where did you read that. It should contain a warning that this won't work out of the box. I've read the note at http://www.wireshark.org/docs/wsdg_html_chunked/ChToolsCompiler.html#ChToolsGCC It says that mainline is using MS compiler for several reasons, but no real info about the reasons themselves. You might do yourself a favour and don't try to build with cygwin/gcc, as this is very experimental. Point taken, idea dropped. Thanks for the early warning. This was just an attempt to facilitate debugging, my final objective is to replace dissector that is currently built in. Andrej ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
