Re: [Wireshark-dev] [Wireshark-users] termshark: a terminal UI for tshark
(+cc wireshark-dev since some may find this interesting.) Hi Graham, This looks neat, I have added it to the wiki: https://wiki.wireshark.org/Tools Are you aware of sharkd? For interactive use it might be a more suitable backend than tshark. sharkd is part of Wireshark and was developed by Jakub Zawadzki who wrote it for use with Webshark, https://webshark.io/ Use of that interface could make things like Follow Stream much easier since you do not have to manually parse the tshark output and can instead read JSON. As the "d" in sharkd might suggest, this process remains up and running until you force it to quit. The main logic is implemented in https://github.com/wireshark/wireshark/blob/master/sharkd_session.c with corresponding tests in https://github.com/wireshark/wireshark/blob/master/test/suite_sharkd.py If you encounter any limitations or have suggestions, please let us know. Thanks :) Kind regards, Peter On Mon, Apr 22, 2019 at 10:09:17PM -0400, Graham Clark wrote: > Hi everyone - I thought you might be interested in this spare-time project: > > https://termshark.io > > In my professional life I quite often find myself on a remote machine > debugging something, and with a need to look at a pcap. I wrote termshark to > make it easy to scan the pcap immediately and to avoid having to scp it > around. Behind the scenes, tshark provides all the intelligence, so > termshark > depends on tshark being installed. Termshark runs the input pcap through > tshark, and uses the PDML and PSML to provide Wireshark-like views of each > packet. Currently you can view a pcap, sniff on an interface (if permissions > allow), and filter using Wireshark's display filters. There's so much more > it > could do easily through tshark, like stream reassembly, display of > conversations, statistics, etc, but I wanted to push out v1 so this is > where I > drew the line. > > Termshark is written in Go and makes heavy use of the excellent tcell > library > for control of the terminal. Because Go is so naturally portable, there are > versions of termshark on github for Linux (+termux/Android), FreeBSD, macOS > and even Windows. > > The source code with build instructions is here: > https://github.com/gcla/termshark > > I hope you find it useful, and I'm very interested to hear your feedback. > > Graham ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Release lifetime and version number changes?
On 4/11/19 4:54 PM, Gerald Combs wrote: > We currently have three active release branches: 3.0, 2.6, and 2.4. This is > because we support each release branch for a set amount of time (typically 24 > months after the initial .0 release) and our last three .0 releases were less > than 12 months apart. However, having many active branches can sometimes > cause confusion[1] and far fewer people download the "Old Old Stable" release > than the "Old Stable" or "Stable" releases. Would it make sense to have only > two release branches active at any given time, e.g. by adjusting our release > branch lifetimes to "24 months or whenever we have two newer active branches, > whichever comes first"? After reading through everyone's responses I think it would make sense to change my release lifecycle proposal from "24 months or whenever we have two newer active branches, whichever comes first" to "18 months or whenever version X.Y+4 is released, whichever comes *second*". Specifically, the new lifecycle rules would be: * At least two (and preferably exactly two) branches will be supported at any given time. * Starting with 3.0, each release will be supported for a minimum of 18 months. After 18 months, support ends if this is the "Old Old Stable" branch. * Releases preceding a major change will be supported for a longer period of time, e.g. 30 months. As shown in the diagram, below, 3.0 will have guaranteed support for 18 months and support will end when 3.4 is released. Similarly, support for 3.2 will end when 3.4 is released. │ Jan 2019 Dec ││ Jan 2020 Dec ││ Jan 2021 Dec │ ─ 2.4 ──┤ ── 2.6 ───┤ ├── 3.0 ───┤┈┈┈[1] ├── 3.2 ───┤┈┈[2] ├── 3.4 ─ ├─── 3.6 ─ [1] Support for 3.0 ends when 3.4 is released. [2] Support for 3.2 ends when 3.6 is released. > We've also been using odd minor numbers for development releases and even > minor numbers for stable releases[2] for many years now. We don't make very > many development releases and instead tend to have one or more release > candidates after branch is created. Would it make sense to drop the even/odd > scheme and make the next major release 3.1.0? Most people preferred sticking with the current odd = development, even = stable release versioning. I'm OK with that. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
