Re: [Wireshark-dev] SMTP: Extracting parametrs
Dear Abhik, Thank you very much for your help. But, do you think IMF packet always exist in all smtp conversations? Because i need to extract these parameters from all SMTP email communications. Thank you in advance. with best regards, On Wed, Jun 11, 2008 at 11:19 PM, Abhik Sarkar [EMAIL PROTECTED] wrote: Hi Goitom, I am not sure if you still have two requirements as you had earlier (one for extraction of the from, to, subject and date fields and one for display of these in a separate diaglog), but as I have suggested before, I think you are better off using the IMF dissector instead of the SMTP dissector. The IMF dissector supports extraction of all these fields already. So, if you want to setup the tap, I think you are better off tapping IMF. I think the best place would be in the while(!last_field) loop in the dissect_imf function of epan/packet-imf.c. Just compare the value of key against from, to, subject and date (after the part the key has been converted to lower case) and you are on your way! If you want to display the records in a dialog, you will probably want to base the dialog off the expert infos dialog (Analyze Expert Info). You can have columns for Frame number, From, To, Subject and Date. Or, as I have suggested before, you can use the custom columns feature (see the attached screenshot with a sample file from the WS wiki). Unless you have some very specific requirements, I think the above should work for you. I honestly hope this is of some help. Good luck! Abhik PS: While researching this, I came across a bug (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2595) in the SMTP dissector, so be sure to have your coloring rules turned on. On Tue, Jun 10, 2008 at 9:54 PM, goitom kahsay [EMAIL PROTECTED] wrote: 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 ___ 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] Start Dissection from an upper layer?
Eloy Paris a écrit : Give something like this a try (this code snippet assumes all the libwireshark initializations have been done already): [snip] fdata-lnk_t = wtap_pcap_encap_to_wtap_encap(DLT_RAW); [snip] Let us know how it goes. Cheers, Eloy Paris.- netexpect.org Works like a charm, thank you ! ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] problem to register own protoco...
Sub-dissectors can't be added against protocol fields, but against
dissector tables. H225 registers the following tables:
nsp_object_dissector_table =
register_dissector_table(h225.nsp.object, H.225
NonStandardParameter (object), FT_STRING, BASE_NONE);
nsp_h221_dissector_table = register_dissector_table(h225.nsp.h221,
H.225 NonStandardParameter (h221), FT_UINT32, BASE_HEX);
tp_dissector_table = register_dissector_table(h225.tp, H.225
TunnelledProtocol, FT_STRING, BASE_NONE);
gef_name_dissector_table = register_dissector_table(h225.gef.name,
H.225 Generic Extensible Framework (names), FT_STRING, BASE_NONE);
gef_content_dissector_table =
register_dissector_table(h225.gef.content, H.225 Generic Extensible
Framework, FT_STRING, BASE_NONE);
So you have to see which one you need to register against... it is
probably h225.tp. There is also a discussion in this thread:
http://www.wireshark.org/lists/wireshark-dev/200707/msg00214.html
which _might_ be of use.
HTH
Abhik.
On Thu, Jun 12, 2008 at 1:24 PM, H F [EMAIL PROTECTED] wrote:
Hi!!!
I'm writing a plugin for our program's own protocol, which encapsulates a
whole 'q931' package in user-user (look at the end of massage in red )
But I have problem to register own protocol!
I'm missing the dissector_add() in my (sub)dissector
void
proto_reg_handoff_mytype(void)
{
static gboolean initialized = FALSE;
if (!initialized) {
H323UserInformation_handle= find_dissector(h323ui);
ipnet_handle= create_dissector_handle(dissect_mytype, proto_mytype);
dissector_add(h225.messageContent_item,0xFE,mytype_handle);
/*0xFE for identifier my protcol */
initialized = TRUE;
};
};
But when wireshark build !! I get the error:
** ERROR:(packet.c:697):???: assertion failed: (sub_dissectors)
No. TimeSourceDestination Protocol
Info
203 15.094231 10.24.30.13 10.24.30.15 Q.931CS:
setup SETUP
Frame 203 (210 bytes on wire, 210 bytes captured)
Arrival Time: Jun 2, 2008 17:57:50.481268000
[Time delta from previous captured frame: 0.016456000 seconds]
[Time delta from previous displayed frame: 15.094231000 seconds]
[Time since reference or first frame: 15.094231000 seconds]
Frame Number: 203
Frame Length: 210 bytes
Capture Length: 210 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:q931:q931:h225:q931]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: Ericsson_fb:c0:9c (00:01:ec:fb:c0:9c), Dst:
Ericsson_52:f2:14 (00:80:37:52:f2:14)
Destination: Ericsson_52:f2:14 (00:80:37:52:f2:14)
Address: Ericsson_52:f2:14 (00:80:37:52:f2:14)
...0 = IG bit: Individual address (unicast)
..0. = LG bit: Globally unique address
(factory default)
Source: Ericsson_fb:c0:9c (00:01:ec:fb:c0:9c)
Address: Ericsson_fb:c0:9c (00:01:ec:fb:c0:9c)
...0 = IG bit: Individual address (unicast)
..0. = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.24.30.13 (10.24.30.13), Dst: 10.24.30.15
(10.24.30.15)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding;
ECN: 0x00)
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding
(0x2e)
..0. = ECN-Capable Transport (ECT): 0
...0 = ECN-CE: 0
Total Length: 196
Identification: 0xf0fa (61690)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x3836 [correct]
[Good: True]
[Bad : False]
Source: 10.24.30.13 (10.24.30.13)
Destination: 10.24.30.15 (10.24.30.15)
Transmission Control Protocol, Src Port: mxomss (1141), Dst Port:
h323hostcall (1720), Seq: 1, Ack: 1, Len: 156
Source port: mxomss (1141)
Destination port: h323hostcall (1720)
Sequence number: 1(relative sequence number)
[Next sequence number: 157(relative sequence number)]
Acknowledgement number: 1(relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... = Congestion Window Reduced (CWR): Not set
.0.. = ECN-Echo: Not set
..0. = Urgent: Not set
...1 = Acknowledgment: Set
1... = Push: Set
.0.. = Reset: Not set
..0. = Syn: Not set
...0 = Fin: Not set
Window size: 5840
Checksum: 0xc1ad [validation disabled]
[Good Checksum: False]
[Bad
[Wireshark-dev] wireshark 1.0.1?
Hi there! A short question: Do you have any plans to make a new release in the near future? thx Valentin___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Need help on wireshark plugin library path setting and open (on hardware not pc box)
Hi, folks, need help here! I am tasked to integrate tshark to hardware, therefore we can capture and debug packets internally. We build tshark as a 3rd party tool through image combined with other tools, when installing this image to hardware, a path like $IMAGE will add in front of wireshark absolute path by image configure default, say: $(IMAGE)/Wireshark.. As I know, wireshark always look for absoulte path, not relative path, to link libraries, therefore, eventhough the plugin libraries are prefectly build, I can easily find all the .so, .la libraries, but tshark just won't load them..I guess it's due to the absoulte path is changed, because a $(IMAGE) is added to the wireshark absoulte path.. Anyone have met simliar problem, is there any way to test the plugin libraries for tshark, and any way I can set the plugins path as relative path? Any help will be greatly appreciated! Thank you very much! Nan _ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wireshark 1.0.1?
Hi, That is a good question. As you may already have seen we're collecting a lot of bugfixes in the roadmap and eventually roll them into 1.0.1. When that will be is a little hard to predict. Currently there are some infrastructure problems which have to be sorted first. Then there's an assessment to be made of the open bugs to see which have to be sorted out before 1.0.1. And then again, she's only two and a half months old. We might give it some more time. But in the end it's up the our Fearless Leader to make the call. Thanx, Jaap [EMAIL PROTECTED] wrote: Hi there! A short question: Do you have any plans to make a new release in the near future? thx Valentin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Need help on wireshark plugin library path setting and open (on hardware not pc box)
Hi, Run configure with the '-help' option. That shows all the options you can pass to the script to match the build to your target. Thanx, Jaap yenan wrote: Hi, folks, need help here! I am tasked to integrate tshark to hardware, therefore we can capture and debug packets internally. We build tshark as a 3rd party tool through image combined with other tools, when installing this image to hardware, a path like $IMAGE will add in front of wireshark absolute path by image configure default, say: $(IMAGE)/Wireshark.. As I know, wireshark always look for absoulte path, not relative path, to link libraries, therefore, eventhough the plugin libraries are prefectly build, I can easily find all the .so, .la libraries, but tshark just won't load them..I guess it's due to the absoulte path is changed, because a $(IMAGE) is added to the wireshark absoulte path.. Anyone have met simliar problem, is there any way to test the plugin libraries for tshark, and any way I can set the plugins path as relative path? Any help will be greatly appreciated! Thank you very much! Nan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Failure to dissect long SASL wrapped LDAP response
Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP response. Regretfully, I cannot share the capture, but the first packet that is not desgemented or dissected in any way (just shows as TCP payload) is (partial): 00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00 ..J.E[...XE. 0010 05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12 [EMAIL PROTECTED] 0020 dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10 .[...oE..4...P. 0030 fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06 .k..l.`..l.. 0040 09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff .*.H 0050 ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9 ...5/.U. 0060 31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c 1i.+..0...l| 0070 02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67 [EMAIL PROTECTED] 0080 67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d gregate,CN=Schem ... Notice from offeset 0x36 (after the TCP header) - the size of the SASL buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then 0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes less than the SASL buffer, followed by the Kerberos 5 OID, and so on. Please note that previos LDAP request and responses were nicely dissected. It's just this long response that doesn't play nice. The unbind request at the end of all this also looks nice. I'd be happy to work with someone on testing a fix for it. I could test a Windows binary or a source patch in Linux. Thanks in advance, Yaniv. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response
Hi,
Can you test the last buildbot build? You can find it here:
http://www.wireshark.org/download/automated/win32/
Thanx,
Jaap
Kaul wrote:
Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
dissect a pretty long (229959 bytes entire conversation) SASL wrapped
LDAP response. Regretfully, I cannot share the capture, but the first
packet that is not desgemented or dissected in any way (just shows as
TCP payload) is (partial):
00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00 ..J.E[...XE.
0010 05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12 [EMAIL PROTECTED]
0020 dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10 .[...oE..4...P.
0030 fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06 .k..l.`..l..
0040 09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff .*.H
0050 ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9 ...5/.U.
0060 31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c 1i.+..0...l|
0070 02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67 [EMAIL PROTECTED]
0080 67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d gregate,CN=Schem
...
Notice from offeset 0x36 (after the TCP header) - the size of the SASL
buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60,
then 0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes
less than the SASL buffer, followed by the Kerberos 5 OID, and so on.
Please note that previos LDAP request and responses were nicely
dissected. It's just this long response that doesn't play nice. The
unbind request at the end of all this also looks nice.
I'd be happy to work with someone on testing a fix for it. I could test
a Windows binary or a source patch in Linux.
Thanks in advance,
Yaniv.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response
Oh, that may explain it (from packet-ldap.c) marked with
bold/italic/underline:
*/* check for a SASL header, i.e. assume it is SASL if
* 1, first four bytes (SASL length) is an integer
*with a value that must be 64k and 2
*(2 to fight false positives, 0x is a common
*random tcp payload)
* (no SASL ldap PDUs are ever going to be 64k in size?)
*
* 2, we must have a conversation and the auth type must
*be LDAP_AUTH_SASL
*/*
sasl_len=tvb_get_ntohl(tvb, 0);
*if*( sasl_len2 ){
*goto* *this_was_not_sasl*;
}
*if*( sasl_len*65535* ){
*goto* *this_was_not_sasl*;
}
Apparently, the above assumption is wrong.
Y.
On Thu, Jun 12, 2008 at 11:40 PM, Kaul [EMAIL PROTECTED] wrote:
Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP
response. Regretfully, I cannot share the capture, but the first packet that
is not desgemented or dissected in any way (just shows as TCP payload) is
(partial):
00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00 ..J.E[...XE.
0010 05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12 [EMAIL PROTECTED]
0020 dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10 .[...oE..4...P.
0030 fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06 .k..l.`..l..
0040 09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff .*.H
0050 ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9 ...5/.U.
0060 31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c 1i.+..0...l|
0070 02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67 [EMAIL PROTECTED]
0080 67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d gregate,CN=Schem
...
Notice from offeset 0x36 (after the TCP header) - the size of the SASL
buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then
0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes less than
the SASL buffer, followed by the Kerberos 5 OID, and so on.
Please note that previos LDAP request and responses were nicely dissected.
It's just this long response that doesn't play nice. The unbind request at
the end of all this also looks nice.
I'd be happy to work with someone on testing a fix for it. I could test a
Windows binary or a source patch in Linux.
Thanks in advance,
Yaniv.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Teamspeak2 Dissector
Hi wireshark-dev, A few months ago I completed work on a TeamSpeak2 dissector and posted it on the bug tracker (2373). https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2373 No one seems to have had a chance to review it yet but I would appreciate some feedback on the chances of it getting checked in. Thank you Brooss ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] LUA development changing column headers
Over the past few weeks I've been trying to make a LUA script to parse out my header information, open up the packet and display the necessary data in a various tree structure. So far all of that has been done well enough, but I find that the packets that I have dissected come maybe once every 300 packets, which makes it pretty hard to compare packets. What I've been trying to do is either edit the packet column data, such as where the ip source or destination is displayed into my own data, or add a new column of my own type so that I can sort the data, which will then put all of my packets next to each other. I know that on the wiki of lua examples there's an outdated way of doing something similar, but it no longer works with the current 1.0.0 build of wireshark. I was wondering if I could get some help in how the syntax should look, for instance if this would work: using pinfo.cols to grab the packet's columns, and upon that use :_newindex(Msgtype, NameofMsg) to put in a new column named Msgtype where this packets data in that column would be NameofMsg, thus the message would look like pinfo.cols:_newindex(Msgtype,NameofMsg) If anyone can think of another way of doing this, either by adding a new column or changing the text of an existing one, I would be appreciative. Brent Rowswell ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wireshark 1.0.1?
Jaap Keuter wrote: Hi, That is a good question. As you may already have seen we're collecting a lot of bugfixes in the roadmap and eventually roll them into 1.0.1. When that will be is a little hard to predict. Currently there are some infrastructure problems which have to be sorted first. Then there's an assessment to be made of the open bugs to see which have to be sorted out before 1.0.1. And then again, she's only two and a half months old. We might give it some more time. But in the end it's up the our Fearless Leader to make the call. A new release would get the new version of libsmi into the Windows installer, which would stop Wireshark crashing on MIBs containing implicit objects. And also clear the path to removing the known memory leak becase smiFree() is now available on Windows. -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Need help on wireshark plugin library path setting and open (on hardware not pc
Hi, Jaap: Thank you very much! I already searched the configure options, there is a --with-plugin[=DIR] option, but same as --prefix option, it will look for an absolute path, is it possible set it to a relative path? like anything similar to ../../PLUNIN_DIR ? Thank you millions! Very appreciate your help and time! Nan Date: Thu, 12 Jun 2008 22:05:19 +0200 From: [EMAIL PROTECTED] To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] Need help on wireshark plugin library path setting and open (on hardware not pc box) Hi, Run configure with the '-help' option. That shows all the options you can pass to the script to match the build to your target. Thanx, Jaap yenan wrote: Hi, folks, need help here!I am tasked to integrate tshark to hardware, therefore we can capture and debug packets internally. We build tshark as a 3rd party tool through image combined with other tools, when installing this image to hardware, a path like $IMAGE will add in front of wireshark absolute path by image configure default, say: $(IMAGE)/Wireshark.. As I know, wireshark always look for absoulte path, not relative path, to link libraries, therefore, eventhough the plugin libraries are prefectly build, I can easily find all the .so, .la libraries, but tshark just won't load them..I guess it's due to the absoulte path is changed, because a $(IMAGE) is added to the wireshark absoulte path.. Anyone have met simliar problem, is there any way to test the plugin libraries for tshark, and any way I can set the plugins path as relative path?Any help will be greatly appreciated!Thank you very much! Nan___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev _ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wireshark 1.0.1?
Andrew Hood wrote: Jaap Keuter wrote: Hi, That is a good question. As you may already have seen we're collecting a lot of bugfixes in the roadmap and eventually roll them into 1.0.1. When that will be is a little hard to predict. Currently there are some infrastructure problems which have to be sorted first. Then there's an assessment to be made of the open bugs to see which have to be sorted out before 1.0.1. And then again, she's only two and a half months old. We might give it some more time. But in the end it's up the our Fearless Leader to make the call. A new release would get the new version of libsmi into the Windows installer, which would stop Wireshark crashing on MIBs containing implicit objects. And also clear the path to removing the known memory leak becase smiFree() is now available on Windows. and about 50 other issues for which fixes are lined up. The maintenance release is going to be worth while, for sure. Thanx, Jaap ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] buildbot failure in Wireshark (development) on Ubuntu-7.10-x86-64
The Buildbot has detected a new failure of Ubuntu-7.10-x86-64 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Ubuntu-7.10-x86-64/builds/0 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: ubuntu-7.10-x86 Build Reason: The web-page 'force build' button was pressed by '': Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell shell_5 sincerely, -The Buildbot ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
