Hi Peter, while I didn't manage so far to find the exact cause of Wireshark missing packets, I reproduced the very same problem.
I was tracing on a P4 2GHz with 512MB RAM, acting as an ethernet bridge in my small test environment. I had "Update list of packets in real time" activated, which usually makes the GUI unable to react to clicking the stop button in a passable timespan if there is more than low traffic. As the result of overburdening the machine, I found a gap of about 0.3s in the captured TCP (sic!) traffic which happened definitely only in the traces, not in the transmission itself. I'm going to look deeper into this topic as soon as I can spare some time. It'll for sure be hard to avoid overload caused losses in capturing, but it might be possible to detect them. Best regards, Martin On 3/4/08, Martin Peylo <[EMAIL PROTECTED]> wrote: > Hi, > > I'll try to help with the Wireshark side of this problem. > > > On 3/4/08, Jon Maloy <[EMAIL PROTECTED]> wrote: > > Strangely enough, node 1.1.12 continues to ack packets > > which we don't see in wireshark (is it possible that > > wireshark can miss packets?). It goes on acking packets > > up to the one with sequence number 53967, (on of the > > "invisible" packets, but from there on it is stop. > > > I've never encountered Wireshark missing packets so far. While it > sounds as it wouldn't be a problem with the TIPC dissector, could you > please send me a trace file so I can definitely exclude this cause of > defect? I've tried to get it from the link quoted in the mail from Jon > but it seems it was already removed. > > > [...] > > > > As a sum of this, I start to suspect your Ethernet > > driver. It seems like it sometimes delivers packets > > to TIPC which it does not deliver to Wireshark, and > > vice versa. This seems to happen after a period of > > high traffic, and only with messages beyond a certain > > size, since the State messages always go through. > > Can you see any pattern in the direction the links > > go stale, with reference to which driver you are > > using. (E.g., is there always an e1000 driver involved > > on the receiving end in the stale direction?) > > Does this happen when you only run one type of driver? > > > I've not yet gone that deep into package capture, so I can't say much > about that. Peter, could you send a mail to one of the Wireshark > mailing lists describing the problem? Have you tried capturing other > kinds of high traffic with less ressource hungy capture frontends? > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Xpl++ [mailto:[EMAIL PROTECTED] > > Sent: March 3, 2008 3:38 PM > > To: Jon Maloy > > Subject: Re: [tipc-discussion] Link related question/issue > > > > I can sucessfuly open the dump with wireshark Version 0.99.8 (SVN Rev > > 24492) under winxp (my desktop) > > and the dump was created by: > > --- > > # wireshark -v > > wireshark 0.99.4 > > > > Copyright 1998-2006 Gerald Combs <[EMAIL PROTECTED]> and > > contributors. > > This is free software; see the source for copying conditions. There is > > NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > > > Compiled with GTK+ 2.8.20, with GLib 2.12.4, with libpcap 0.9.5, with > > libz 1.2.3, with libpcre 6.7, without UCD-SNMP or Net-SNMP, with ADNS, > > without Lua, with GnuTLS 1.4.4, with Gcrypt 1.2.3, with MIT Kerberos, > > with PortAudio <= V18, without AirPcap. > > > > Running on Linux 2.6.20.4-SE-2+1.7.5, with libpcap version 0.9.5. > > > > Built using gcc 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). > > -- > > and it also opens properly using: > > -- > > # wireshark -v > > wireshark 0.99.2 > > > > Copyright 1998-2006 Gerald Combs <[EMAIL PROTECTED]> and > > contributors. > > This is free software; see the source for copying conditions. There is > > NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > > > Compiled with GTK+ 2.6.4, with GLib 2.6.4, with libpcap 0.8.3, with libz > > 1.2.2, with libpcre 4.5, without UCD-SNMP or Net-SNMP, with ADNS, > > without Lua. > > > > Running with libpcap version 0.8.3 on Linux 2.6.24.2-SE. > > -- > > > > I don't trust email for large file transfer, so please check this url: > > > > http://www.100webspace.com/xpl/JoNmAlOy/capture.2.gz > > > > This downloads and opens ok with all wiresharks I have :) > > > > Regards, > > Peter. > > > > Jon Maloy ??????: > > > > > > Hi, > > > I don't know how what information wireshark/ethereal stores when > > > creating a dump file, but when I open yours I get a dump describing a > > > TIPCv0 message, which is useless because the TIPC in Linux is version > > > 2. > > > I'm pretty sure that my wireshark version is not the problem, so it > > > must be the dump. > > > Could you resend it based on your newer wireshark version? > > > > > > Regards > > > ///jon > > > > > > > > > -----Original Message----- > > > From: Xpl++ [mailto:[EMAIL PROTECTED] > > > Sent: March 3, 2008 12:06 PM > > > To: Jon Maloy > > > Subject: Re: [tipc-discussion] Link related question/issue > > > > > > well, I've tried to track those sequence numbers .. and it seems that > > > either I have no idea what I'm looking at, or those ids change in a > > > weird manner > > > > > > Peter. > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > tipc-discussion mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
