Show HN: NetSour, CLI Based Wireshark(github.com)
github.com
Show HN: NetSour, CLI Based Wireshark
https://github.com/thegoodduck/NetSour
This code is still in early beta, but i sincerley hope it will become as ubiquitous as VIM on Linux.
43 comments
It kills me every time I see a link to a github project that sounds promising, but there's no screenshot.
Edit: As pointed out by doakes [1], the project is built by a 13 year old. With that context, I want to preface my original comment by congratulating TheGoodDuck on this project. What follows is criticism, but also do not take it too harshly. These are things I'd expect a developer with experience to know, but not a junior. As you might gather, the issues are even common among seasoned developers. So take the comments as a learning opportunity and remember that criticism of a work is not a criticism of you. These are also soft skills which are often not explicitly taught, but critical to growing as an engineer/developer. If you're doing this at this age and you keep up the work and dedication, you will be a force to reckon with in no time. I am not editing my original comment as this is how I would talk peer to peer and you're a peer ;) But I also wanted to give this context and preface because the style of language is a bit strong. Also note that these issues are very solvable and solving them will make your project even better.
The comments are there to help you improve, not to put you down.
---------------------------------------
You're not alone. Even worse when it is a product page. Just how often I see some product or project and are unable to actually determine what the thing does or why I would want to use it or even HOW to use it.
I can give GitHub projects a pass when someone else links them, but the poster is the author so no pass. This is "Show HN". Please __show__. I do like to try out new projects and tools, but where's the hook?
Also, do not underestimate the importance of documentation. Hell, I document predominantly for myself. I know I'm not alone in forgetting how things work if I haven't touched a project in awhile (which can even be going to lunch on bad days). This is also critical for any users. Encourage them to add docs, make it easy, and when addressing issues recognize that just because it is in the docs does not mean it's interpretable from user context.
If you want to demonstrate a CLI or TUI tool, a common helper is asciinema[0]. You can record your terminal and they'll host the output for you. You'll frequently see these on GitHub and even a 10 second video that is clunky/slow with key presses (or way too fast) is better than nothing. UIs matter and aren't as simple/obvious as many think.
Also, drop a license file in there. Not just a line in your README. Come on, GitHub even hands these files to you so it is the same work to write in your README as it is to drop that file in (though you should always mod those licenses headers to be about you and your project). Without the license file, your license is ambiguous and may not actually protect your project as intended. The full text needs to exist.
[0] https://asciinema.org/
[1] https://news.ycombinator.com/item?id=41010519
The comments are there to help you improve, not to put you down.
---------------------------------------
You're not alone. Even worse when it is a product page. Just how often I see some product or project and are unable to actually determine what the thing does or why I would want to use it or even HOW to use it.
I can give GitHub projects a pass when someone else links them, but the poster is the author so no pass. This is "Show HN". Please __show__. I do like to try out new projects and tools, but where's the hook?
Also, do not underestimate the importance of documentation. Hell, I document predominantly for myself. I know I'm not alone in forgetting how things work if I haven't touched a project in awhile (which can even be going to lunch on bad days). This is also critical for any users. Encourage them to add docs, make it easy, and when addressing issues recognize that just because it is in the docs does not mean it's interpretable from user context.
If you want to demonstrate a CLI or TUI tool, a common helper is asciinema[0]. You can record your terminal and they'll host the output for you. You'll frequently see these on GitHub and even a 10 second video that is clunky/slow with key presses (or way too fast) is better than nothing. UIs matter and aren't as simple/obvious as many think.
Also, drop a license file in there. Not just a line in your README. Come on, GitHub even hands these files to you so it is the same work to write in your README as it is to drop that file in (though you should always mod those licenses headers to be about you and your project). Without the license file, your license is ambiguous and may not actually protect your project as intended. The full text needs to exist.
[0] https://asciinema.org/
[1] https://news.ycombinator.com/item?id=41010519
I added a licence and will try to build documentation. (For the record this code is 10 days old!)
No worries, you're all good. Getting the experience to understand expected norms takes time. Just not that often you see such a young developer on the front page of HN, and especially without mention of age in the title.
Thanks for all the positive(and negative) feedback :-)
Thanks for the cool project.
And just remember: never fear pushing back (even against seniors) and never confuse criticism about your work with an attack on you as a person. I mean all our code is shit. If a year from now you don't look back at your code and think "this is shit" then it probably means you are no longer improving (conversely if you are feeling discouraged and like you're getting nowhere, go back and look at your old code because it makes the improvements rather obvious lol).
Good luck. Keep it up and you'll do great. So don't stress and don't forget to have fun (very common mistake, especially by adults)
And just remember: never fear pushing back (even against seniors) and never confuse criticism about your work with an attack on you as a person. I mean all our code is shit. If a year from now you don't look back at your code and think "this is shit" then it probably means you are no longer improving (conversely if you are feeling discouraged and like you're getting nowhere, go back and look at your old code because it makes the improvements rather obvious lol).
Good luck. Keep it up and you'll do great. So don't stress and don't forget to have fun (very common mistake, especially by adults)
Talking about my shit code: https://github.com/thegoodduck/winternet_social Its a social media framework is started builiding maybe 6 months ago now i look at it its just such a mess... I will need to refactor it... It was time when i was working directly on prod server(even on fridays) and occasinally a bug would make the server go down :-)
You might want to put __pycache__ in your .gitignore, check here for example:
https://github.com/github/gitignore/blob/main/Python.gitigno...
I'll do it as soon um off my old unsupporting github phone... in summer camp
FYI: If you can access the website on your phone (I'm assuming you can since you made this comment), you can make small edits like this from there. Navigate to your repo, click on the ".gitignore" file, select the 3 dots to the right, and click "edit in place". You can then add the line and make the commit. But note that this will not remove the __pycache__ file from the repo, though you can also perform that from your browser through a similar process.
done it!!!
I can really recommend
https://termshark.io/
It looks basically exactly like the Wireshark UI, but it's a TUI. So if I need some more interactivity than tcpdump, I use termshark instead.
https://termshark.io/
It looks basically exactly like the Wireshark UI, but it's a TUI. So if I need some more interactivity than tcpdump, I use termshark instead.
I just tried termshark a couple weeks ago. It _was_ just like wireshark, which was nice. However:
* There's a "screensaver" which activates after a couple seconds and requires extra button presses to get back to real data
* In several sessions the TUI output got corrupt
* It has problems with remembering field expansion - I'd expand one field and it'd expand all the other fields after a second delay, while looking at the same message even.
* It felt pretty slow to start up
* I felt like I had some issues with filter accuracy
But it got the job done and most issues were easy enough to work around.
* There's a "screensaver" which activates after a couple seconds and requires extra button presses to get back to real data
* In several sessions the TUI output got corrupt
* It has problems with remembering field expansion - I'd expand one field and it'd expand all the other fields after a second delay, while looking at the same message even.
* It felt pretty slow to start up
* I felt like I had some issues with filter accuracy
But it got the job done and most issues were easy enough to work around.
I commend the effort, it’s always nice seeing people working on usability improvements for staple systems tools. But I have to ask the following since given your ubiquity comment:
What’s the advantage of this over using tcpdump directly?
What’s the advantage of this over using tcpdump directly?
You can extend this with like addons type for detecting ddos...
DDoS is probably not a great example to lead with because odds are your Python application will hang quicker than the hosts network stack.
But that aside, the addons idea is an interesting one.
But that aside, the addons idea is an interesting one.
How would you compare this to termshark / tshark?
It is basically Scapy with 200 lines of code to make it easier to start. That means tshark is alot better as a cli/DSL. Interactiveness is not what Scapy is good at, it is marvelous when you need to e.g. send events to other services based on custom packet event.
EDIT: I wonder if there is some nice TUI debugger interface/IDE that one could reuse for this. Handling traces Live like this has always been a special skill so I guess specialized tools is a must.. But one would think that all the tooling around KUtrace/ebpf/tcpdump could be generalized in some way.
EDIT: I wonder if there is some nice TUI debugger interface/IDE that one could reuse for this. Handling traces Live like this has always been a special skill so I guess specialized tools is a must.. But one would think that all the tooling around KUtrace/ebpf/tcpdump could be generalized in some way.
I don't understand your TUI thing... Can you pls clarify???
Writing "layout next" in GDB gives you a TUI: Text user interface, like midnight commander. There are so many good debuggers in graphical environments I just wondered if there were any better ones for text.
Edit: I really like this simple Scapy wrapper though! Works like a charm.
Edit: I really like this simple Scapy wrapper though! Works like a charm.
I just tried tshark, it outputs just raw packet info without any formatting. My code frmats the packets and gives more usefull insights only when prompted
termshark is a TUI for tshark. So termshark looks a lot like wireshark but in a terminal.
thark doesnt have automatic DOS detection nor MITM setup(beta)
Detecting "DOS" by putting the packets into a Python buffer seems... counterproductive.
... for the reasons the other guy said: https://news.ycombinator.com/item?id=41011627
DoS attacks attempt to overwhelm your system or your system's connection by sheer amount of packets. And here you are capturing those packets and keeping them in memory - this just makes your system fall over faster.
DoS attacks attempt to overwhelm your system or your system's connection by sheer amount of packets. And here you are capturing those packets and keeping them in memory - this just makes your system fall over faster.
If people didn't notice, this was built by a 13 year old. This is a fun space to be building stuff in. Neat little project and I hope you keep it up!
But I don't care how old they are, why did you mention that property as if it's something relevant to how the project should be perceived?
Because this kids writing code a lot better than many professional programmers.
Again: I don't care if they are a kid or an old fart, this should not be anyhow relevant to the post.
Neat project, keep going!
Any thoughts on how to differentiate your work from other cli packet capturing and display utilities such as gosniff or termshark?
Any thoughts on how to differentiate your work from other cli packet capturing and display utilities such as gosniff or termshark?
Any good screnshoting tool for linux on rpi os? I never found one...
I mention asciinema in my other comment[0], but there are a number of tools. The one to use depends on your system and the archwiki has a good list[1]. Assuming you're not using Wayland, ffmpeg is probably going to work[2]. Gimp and ImageMagick also provide tools to help.
[0] https://asciinema.org/ | https://news.ycombinator.com/item?id=41010530
[1] https://wiki.archlinux.org/title/Screen_capture
[2] https://trac.ffmpeg.org/wiki/Capture/Desktop
[0] https://asciinema.org/ | https://news.ycombinator.com/item?id=41010530
[1] https://wiki.archlinux.org/title/Screen_capture
[2] https://trac.ffmpeg.org/wiki/Capture/Desktop
Im using wayland...
slurp + grim
???
Grim can take screenshots, slurp is used for selection. It's a rough equivalent to Maim for Wayland.
I have found that many people will simply ignore a project with no screenshots, it might be a good idea to at least throw one up there.
Have you got an idea how to embed screenshots in README???
You can just use normal markdown format.
For example, if you have your screenshots in a directory in the repo called `docs/images` you can include it with:
For example, if you have your screenshots in a directory in the repo called `docs/images` you can include it with:
Thanks! In the next 24 hours I will add screenshots :-)
I would look at one of the many other projects that have them in their readme and see how they do it, I think it's with a certain markdown syntax but I don't know it off the top of my head. Hope this helps.