[Wireshark-dev] Fwd: Wireshark 1.11.3 on FreeBSD: no plugins are loaded
Hi, If you look in the Folders tab > in the Help->About Wireshark UI it'll show you where it is looking. > > If all else fails, you can always 'truss' (or the FreeBSD equivalent) > Wireshark to see where it is looking for the plugins. > Thank you very much. Using truss and the info dialog, I found out about the folders Wireshark is looking into for plugins. Now it is working as expected! Bye, Jo ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] why is the ack number of several ack frame in tcp transmission is the same?
why is the ack number of several ack frame in tcp transmission the same?Is that the ack of several tcp segments?if so,how to calculate the bytes of data that been received every time?___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Git clone is quite slow on remote end
On 4/6/14 4:47 PM, Matthew Parlane wrote: > remote: Counting objects: 366552, done > remote: Finding sources: 93% (340894/366552) > > The remote count process seems quite slow. In case you guys are not > aware, you should run gc on gerrit every now and again to resolve the > remote count slowdown. > > At work it's simply /ssh gerrit gerrit gc project_name/ > > This gives us quite a decent improvement in remote count on fresh git > clones. > > Then again, maybe your git db is so large and you guys are running gc > already, in which case don't worry :) As The Kids in the Hall might say, "try it now." ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Git clone is quite slow on remote end
Yep, instant now :) Thanks. Matthew Parlane On 8 April 2014 03:46, Gerald Combs wrote: > On 4/6/14 4:47 PM, Matthew Parlane wrote: > > remote: Counting objects: 366552, done > > remote: Finding sources: 93% (340894/366552) > > > > The remote count process seems quite slow. In case you guys are not > > aware, you should run gc on gerrit every now and again to resolve the > > remote count slowdown. > > > > At work it's simply /ssh gerrit gerrit gc project_name/ > > > > This gives us quite a decent improvement in remote count on fresh git > > clones. > > > > Then again, maybe your git db is so large and you guys are running gc > > already, in which case don't worry :) > > As The Kids in the Hall might say, "try it now." > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] why is the ack number of several ack frame in tcp transmission is the same?
On Monday, April 7, 2014, 2:33:08 PM, "ÎÒÏë²»ÎÞÁÄ" wrote: > why is the ack number of several ack frame in tcp transmission the same?Is > that the ack of several tcp segments?if so,how to calculate the bytes of data > that been received every time? Two possible reasons: 1) The data segments got duplicated in transit, or retransmitted due to the sender not receiving an ACK in what it considered a reasonable time. The receiver may ack each duplicate if they all do eventually arrive. 2) The data segments got re-ordered in transit, so the receiver got a segment later than the one it was expecting next. These days it can reply using Selective Acknowledgement, where the ACK field itself contains the latest *contiguously* received sequence number (so will appear to stay the same), but the SACK field (shown under the TCP Options section in Wireshark) show what other non-contiguous data it has received. Then if the sender later decides it does need to retransmit it only has to "fill in the gaps" rather than send the entire window from the ACK point on. (I believe Wireshark displays this as a "Duplicate ACK" rather than out-of-order or such, or at least used to, apparently it doesn't notice the SACK options changing each time.) John -- Dead stars still burn ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
