[HN Gopher] tcpdump is amazing (2016)
___________________________________________________________________
tcpdump is amazing (2016)
Author : sandebert
Score : 261 points
Date : 2023-02-02 08:04 UTC (14 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| bojanbabic wrote:
| Seems like OP fell in love with tshark
| nimrody wrote:
| Is there a way to place the BPF filter _after_ IP packet
| reassembly?
|
| Otherwise, matching for TCP port, etc. fails to capture fragments
| which do not have the TCP header and the resulting file is
| missing some data.
| johnnny wrote:
| TCP tries really hard to avoid fragmentation, by setting the DF
| flag and reducing the MSS when it sees a PTB error.
|
| Of course that sometimes fails, so if you still have TCP
| fragmented segments, the next best thing is to filter by
| source/destination address, saving to a PCAP file, then run
| tshark on that file with the "-2" flag which does packet
| reassembly.
|
| (I don't know if tshark can be made to do on-the-fly
| reassembly, that would require keeping a buffer of un-
| reassembled fragments until the rest of the packets are seen.)
| toast0 wrote:
| I'm not sure, but you can probably just capture all ip
| fragments and do a second pass with something later?
|
| When I was running a webserver with worldwide audience and 40+
| Gbps traffic (most of that was our apk though), I saw no more
| than a couple fragments per second; unless there was some UDP
| reflection DDoS going on and I was getting fragments from that.
|
| Lots of high profile sites don't even accept ip fragmentation
| because it's too costly to deal with.
| tptacek wrote:
| The direct answer to your question is "no", because tcpdump
| isn't stateful. It reads fragments one at a time, prints them,
| and forgets about them.
| foobarbecue wrote:
| What's the [Berke]?
| Reubensson wrote:
| I suppose it should be a link to some resource about Berkeley
| Packet Filters
| (https://en.m.wikipedia.org/wiki/Berkeley_Packet_Filter).
| kitd wrote:
| I'd imagine it's the Berkeley Packet Filter which underpins
| tcpdump, but he got distracted half way through?
|
| Filter rules syntax is here:
|
| https://biot.com/capstats/bpf.html
| fstokesman wrote:
| She* - this is Julia Evans blog.
| kitd wrote:
| Oops, apologies to her.
| dang wrote:
| Discussed at the time:
|
| _Tcpdump is amazing_ -
| https://news.ycombinator.com/item?id=11302992 - March 2016 (102
| comments)
| badrabbit wrote:
| You know what else is neat? netsh on windows. Let's you do
| circular size limited packet captures and associate every packet
| with the originating/destination process.
|
| But yes, tcpdump and strace/ltrace are the ultimate tool for "I
| have no idea what the problem is, let me find out exactly what is
| happening" when troubleshooting.
| pjc50 wrote:
| Huh, I never had any idea that netsh existed.
| badrabbit wrote:
| That's what you use for managing the windows firewall,
| setting up tunnels/port forwarding too. Pretty nifty for a
| windows cli tool.
| EvanAnderson wrote:
| I used to use netsh to capture on Windows boxes but the
| workflow for getting the data into pcap format was awful.
| Lately I've been using RawCap[0]. It's a single EXE that works
| on stock versions of Windows and produces pcap files. It has no
| capture-time filtering options, which is a bummer, but it's
| quicker for me to get data to look at than the netsh / convert
| to pcap workflow.
|
| [0]
| https://www.netresec.com/?page=Blog&month=2020-01&post=RawCa...
| hamburglar wrote:
| > tcpdump and strace/ltrace are the ultimate tool for "I have
| no idea what the problem is, let me find out exactly what is
| happening" when troubleshooting.
|
| And the ability to do that type of troubleshooting when the
| shit hits the fan is becoming more and more rare. I regularly
| run into devs, even so-called "senior" devs, these days who
| don't know how it's useful to look at packets or system calls
| and whose minds are blown that anyone would know details that
| far down the stack. It would be depressing if it wasn't so good
| for job security.
| eddieroger wrote:
| tcpdump is the kind of tool I'm glad is in my toolbox, but I hate
| when I have to get it out. Not because it's hard to use, and this
| article / Julia does a great a job at explaining the basics, but
| every time I've had to use it in the past was because something
| was really wrong and none of the partner teams I've had to work
| with either knew how to troubleshoot or had the tools to do it.
| If you run any kind of network connected infra, it's worth the
| investment in learning how tcpdump and Wireshark work.
| lbriner wrote:
| I've realised this recently reading various stories about what
| seem like amazing debug stories but boiled down to
| understanding how to use tcpdump or wireshark or some other
| profiling/logging tool but they are amazing because most devs
| simply don't know how to use them (or even if to use them).
|
| This is probably part of the reason why Google is super fast
| and most software is super slow.
|
| Same for IT teams. I should be able to assume that any answer
| to a network question includes the relevant info from the
| wireshark trace not just, "I can't see anything wrong with it"!
| eddieroger wrote:
| It's not even that the best debug stories boil down to
| understanding and using tcpdump, but there's a real, giant
| divide between people who know how to troubleshoot and those
| who don't. Slinging code is relatively easy if you know the
| language, but odds are your app talks to a database, or makes
| a web call, or uses memory, and knowing how you interact at
| that layer is the difference between good and bad
| experiences, and uptime or not when things fail. I'm no
| electrician, but I know how to check my circuit box when
| something in my house won't power on, and then how to swap
| power cables, etc.
| waynesonfire wrote:
| absolutely. the tcpdump is as simple as possible and no
| simpler.
| soheil wrote:
| Yeah but it's pretty useless for tracking what https requests get
| made or pretty much anything that uses encryption. You can filter
| by https GET requests but you won't be able to see what's inside
| them.
| hoherd wrote:
| Sure, but https is not the only protocol. tcpdump is also
| pretty useless at debugging OpenGL.
|
| https is only one protocol. There are hundreds or thousands of
| other protocols that tcpdump works fine with. Some of these
| protocols are underneath https, including tcp, which is in the
| name of the tool. So while tcpdump may not function as a
| tlsdump and can't see into your tls connection, it does a lot
| of other things great.
|
| You may as well complain that your screwdriver is no good for
| cutting wood. Clearly you need a different tool.
| jdsnape wrote:
| you shouldn't even be able to see the method (GET/POST etc.) as
| that is inside the encrypted TLS body. You will be able to see
| timings and approximate sizes, as well as potentially the
| hostname from the SNI but that's about it.
| password4321 wrote:
| SSLKEYLOGFILE can help.
| LinuxBender wrote:
| Also SSLDump [1]
|
| [1] - https://linux.die.net/man/1/ssldump
| MAGZine wrote:
| i used to use tcpdump all of the of time for local development.
|
| with everything moving to https, sometimes even local
| environments, it's basically been useless now however.
| benburwell wrote:
| I wrote about how I decrypt TLS streams in Wireshark for
| debugging purposes here:
| https://www.benburwell.com/posts/intercepting-golang-tls-wit...
|
| It won't apply to every situation, but might provide some
| building blocks you can adapt to your environment.
| pm2222 wrote:
| Highly recommend documentation by F5 it's a goldmine, e.g.
|
| K2289: Using advanced tcpdump filters
| https://support.f5.com/csp/article/K2289
| choult wrote:
| What a nice coincidence - I used it for debugging a UDP
| connection earlier today.
|
| > sudo tcpdump -n udp port 8125 -v -X -i lo
| scottlamb wrote:
| > I mentioned really briefly that tcpdump lets you save pcap
| files. This is awesome because literally every network analysis
| tool in the universe understands pcap files. pcap files are like
| freshly baked chocolate chip cookies. Everybody loves them.
|
| OMG, yes, very well put. When I get a bug report with a pcap file
| I'm happy because I know I'll be able to see exactly what
| happened.
|
| Speaking of which: for one of my libraries, I want to make a
| diagnostic tool that replays an interaction. My library mostly
| operates at the TCP level (also some UDP), so I need to
| reconstruct the TCP flows in my tool to feed to my library.
| Either I need an easy-to-use Rust library to do that directly
| from pcap files [1] or some format that represents bytes moving
| over the flow (like sets of lines with a timestamp, flow id, and
| pretty hexdump of the bytes) with a tool that produces it from
| pcap. This seems like something that should exist? Wireshark's
| "Analyze > Follow > TCP Stream"'s "Save As...", "entire stream",
| "hex dump" is kind of what I want, but it doesn't have
| timestamps, and it doesn't have a way to put everything (multiple
| flows, UDP packets also) in one file. Seems like there should be
| something under "Export Packet Dissections" [2] but I haven't
| found quite the right thing there either.
|
| [1] https://crates.io/crates/pnet looks promising but it wasn't
| as obvious as I hoped how to plug it in for what I want.
|
| [2]
| https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportS...
| hacb wrote:
| Now I know that some people get pcap files with bug report and
| I'm jealous
| vdm wrote:
| https://tcpreplay.appneta.com
| scottlamb wrote:
| Does that help? I don't want to replay the packets on a
| network. Instead, I want to feed them to my library without
| having to deal with reconstructing the TCP stream from the
| packets myself. I don't see anything for that in that suite.
|
| tcpflow (mentioned in another thread here) seems much closer
| in that it does reconstruct TCP flows from pcap, but it
| doesn't timestamp stuff (it'd be nice to have an idea if some
| client->server data or some server->client data came first as
| well as just relate to timeouts), and I'd prefer to put
| everything in one file (both directions of TCP data, UDP
| packets).
|
| Maybe I "just" need to figure out that Rust library I
| mentioned in the grandparent, and maybe create my own
| intermediate format that has just the data I want for my
| library. (I can discard TCP retransmissiony stuff, MACs, etc.
| to focus on what a library sees through the kernel socket
| interfaces.)
| dTal wrote:
| Shoutout to the lesser-known tcpflow, which reassembles the
| complete contents of a TCP connection by paying attention to
| sequence numbers. Very handy!
| RickHull wrote:
| I used tcpflow extensively about 17 jobs ago. I had a Linux box
| on a hub segment with Windows servers running a .NET
| application, used for realtime capture and monitoring
| application traffic in a test environment. I had an independent
| implementation of the framing protocol and message format
| written in Ruby, and if my decoder choked, then it was either
| my problem or their problem. Early on, it was always my
| problem, but after about 6 weeks, it was their problem 70% of
| the time. Great way to uncover subtle bugs, at the upfront cost
| of a 2nd independent implementation.
| mr_mitm wrote:
| Obligatory advice that you shouldn't run tcpdump, tshark or
| wireshark as root or with sudo. Instead, set up least privileges
| (e.g. with capabilities) or at least use the tcpdump flag `-Z`
| (may be enabled by default at compile time in your distribution).
| Debian has a group called "wireshark" for this use case by
| default.
| soheil wrote:
| So you're just gonna make a claim and pretend you don't need to
| give a reason why?
| cwaffles wrote:
| Quick reference to add permissions:
| https://wiki.archlinux.org/title/Wireshark#Capturing_privile...
| mattrighetti wrote:
| Why is that?
| mr_mitm wrote:
| These tools are parsing untrusted input (tshark and wireshark
| are parsing a very large number of different protocols), and
| considering these are all written in a memory unsafe language
| (C), they are at a high risk of remote command execution
| vulnerabilities. And since they don't actually require root
| permissions, just permission to access raw sockets and a few
| other network related things, it's simply best practices to
| use as little privileges as possible and only as much as
| necessary.
| client4 wrote:
| At the defcon ctf in 2016(?) One of the teams used a
| Wireshark 0day to pwn another team and see/use all of their
| flags.
| rixrax wrote:
| Sometimes when no other options exist, and I need to
| capture untrusted traffic as root, I use 'tcpdump -i eth0
| -s0 -n -w some.pcap' to save the packets to a .pcap. Just
| recording the frames _shouldn 't_ (invoke any parsing code
| although I have never actually checked). Then I open the
| .pcap with wire/tshark or even tcpdump in some safer
| sandbox.
| hamburglar wrote:
| You can also send the pcap to stdout and pipe it to stdin
| of a tshark running as non-root. And if you provide the
| right capture filters on tcpdump you can even have the
| tcpdump in an ssh session piping to a local tshark so you
| don't even have to have tshark on the server.
| lexh wrote:
| I was delighted when I discovered that you can also pipe
| stdin into Wireshark (GUI). I've not seen a lot of GUI
| applications that support this flow.
|
| e.g. > wireshark -k -i <(ssh -l root
| remote-host "dumpcap -P -w - -f 'not tcp port 22'")
|
| https://wiki.wireshark.org/CaptureSetup/Pipes.md#remote-
| capt...
| hamburglar wrote:
| I prefer a 'not host <x>' filter using info found in
| $SSH_CONNECTION to filtering all port 22 out, but yeah,
| good stuff.
| mr_mitm wrote:
| Wireshark is also able to capture traffic of remote
| interfaces over ssh.
| varjag wrote:
| While the principle itself is sound, this is seriously
| exaggerating the threat. I mean sure the tools are written
| in C, but so is your whole network stack.
|
| Have your prod boxes set up with proper permissions for
| sure but there's hardly a practical risk doing this in
| dev/testing.
| bbarnett wrote:
| Tcpdump is a unique codebase, has its own flaws/issues,
| and most certainly can be vulnerable, even if the overall
| stack is not.
|
| Run nothing as root, unless absolutely required. And this
| had nothing to do with C or rust, running rust based
| software, any software as root, when not required,is
| unnecessary, and risky as well.
|
| Nothing is safe. Behave that way, or you do your oeg, and
| yourself, wrong. And its not OK to treat a dev env as
| fine to get compromised.
|
| Many orgs get borked by someone taking over dev machines,
| or infra, and sliding in that way.
| jeroenhd wrote:
| I think the point is that so what if you don't run these
| tools as root?
|
| If a malicious actor compromises your normal user
| account, they can also compromise your configuration
| files and alias sudo or set up a keylogger or do all
| kinds of nasty stuff.
|
| Going from standard user to root isn't much of a
| challenge for all but the most minimal infections in
| almost every standard setup for common Linux
| distributions.
|
| Malicious hackers don't need anything other than your
| current user permissions anyway; your API/ssh keys/crypto
| wallets are all stored in your home directory or other
| places a malicious program can get access to.
|
| There are exceptions, but I very much doubt that most
| people develop on QubesOS levels of Linux security.
|
| There is no practical antivirus software on Linux that
| will catch anyone sophisticated enough to exploit
| tcpdump. You need a LOT of know-how to run a "safe" Linux
| system that you're more likely to learn as a sysadmin
| than as a developer. Security is hard, especially on the
| Linux desktop, and it will be as long as attempts to add
| it are met with responses like "they're trying to take
| our freedom away".
|
| Common internet resources aren't much better ("just
| disable selinux") and current solutions for usability
| problems in this space (i.e. sandboxed applications not
| being able to access the directories you chose because
| they don't correspond to what the dev expected) aren't
| very great either.
|
| I definitely think we should use the resources for secure
| desktop computing that we do have, which includes running
| tshark and friends at the lowest level of privilege
| possible, but I can definitely understand why people ask
| "why should I bother" when most of their setup runs at
| Windows XP levels of security out of the box.
| bawolff wrote:
| > Malicious hackers don't need anything other than your
| current user permissions anyway; your API/ssh keys/crypto
| wallets are all stored in your home directory or other
| places a malicious program can get access to.
|
| I mean, are you really running tcpdump on your local
| computer? I imagine you would be running it on the server
| you are trying to debug. So the security setup would
| plausibly be a bit different than that.
|
| But generally i agree. Good practise not to run things as
| root, especially this type of tooling, but its not
| exactly putting your private key into a public git repo
| level of insecurity by any means.
| jeroenhd wrote:
| > I mean, are you really running tcpdump on your local
| computer?
|
| I did several times when I needed to debug or record some
| traffic because I couldn't figure out why some
| application wasn't communicating right. Wireshark quickly
| got overwhelmed with packets so I used tcpdump instead.
|
| I'm most likely running tcpdump on (near) production
| servers because it's often a tool of last result, but
| sometimes it's just the right tool for the job (or just
| as good a tool as the fancier ones, and why not stick to
| the universal solution?).
| lelanthran wrote:
| > Run nothing as root, unless absolutely required.
|
| Good advice, to be sure. Especially anything getting
| network input[1].
|
| In a reddit thread once, I pointed out that there is no
| need for any server/service program to have any access to
| the file holding the startup configuration. There really
| isn't.
|
| If the user needs to write that configuration, use a
| different program with elevated privileges that do
| nothing but write that file.
|
| When the server starts up and needs to read config, it
| should start up as a user with elevated privileges, read
| the entire file in the first 3 lines of `main()`, then
| drop privileges and continue execution as normal. It will
| never be able to access that file during the rest of its
| execution.
|
| I don't think I've ever had a comment downvoted on reddit
| so hard!
|
| [1] No need to say "untrusted network input" - all input
| is untrusted unless you are literally in control of both
| parties.
| kqr wrote:
| This would add complexity and in particular couple the
| application to a specific combination of operating
| system/privileges model/file system. How great is the
| benefit, really? How many things are exploited by the
| application writing to its own startup config?
| lelanthran wrote:
| > This would add complexity
|
| It would add fair bit of _code_ , sure, but nicely
| isolated and not complex: It's three extra lines of code
| in the main function, and a separate utility to write the
| config.
|
| Balance that against the fact that the server then never
| writes its own config - that code is moved into the
| configuration-writing application, which removes
| complexity from the server application.
|
| > and in particular couple the application to a specific
| combination of operating system/privileges model/file
| system.
|
| It does indeed couple it to those systems that are
| sufficiently POSIX-like; however if you are writing a
| server that doesn't run on a Linux or BSD-derived system,
| you are out in the left field anyway.
|
| > How great is the benefit, really? How many things are
| exploited by the application writing to its own startup
| config?
|
| Well, the comment I made was in a thread discussing a
| vulnerability in the Microsoft Teams application[1] which
| was exploitable to retrieve the user's secrets[2] from
| their config file.
|
| So, that particular comment was very much on-topic and
| in-context.
|
| [1] Not sure if it was on all platforms or not.
|
| [2] Or something - I forget exactly what was leaked.
| bawolff wrote:
| most methods of getting persistence involve writing to
| some config file somewhere. Having your app not have
| rights to write to any sort of config or code files
| probably is fairly beneficial.
|
| How much is probably going to depends on how everything
| is configured, what your threat model is, what service it
| is, and a million other things.
| msm_ wrote:
| Interesting idea, I quite like it. At the same time we
| have things like kubernetes, where most people store
| secrets in the environment variables that _every single
| process_ in the container can read.
| tptacek wrote:
| tcpdump is risky because it parses (way, way) more
| protocols than your network stack does, and because
| tcpdump's parsers are tooling-grade code, not kernel
| network code.
| varjag wrote:
| I mean yes it's relatively more risky but no it's not
| risky enough for me to not do occasional sudo tcpdump -X
| on an unconfigured machine in a problematic spot. The
| risk of me getting targeted by tcpdump zero-day while
| diagnosing some UDP broadcast problem on a LAN is
| diminutively low. Your situation is likely very
| different.
| tptacek wrote:
| No, I mean, I generally agree, it's not high on my list
| of threat vectors, but the general advice to be mindful
| about a giant memory-unsafe blob of tooling-grade
| protocol parsers written by hundreds of different people
| over 3 decades seems astute.
| mr_mitm wrote:
| I find it even more convenient to just add my user
| account to the correct group. Now I can call tcpdump
| anytime without having to invoke sudo. I get more
| security and convenience at the same time, so why not do
| it? I recommend giving the nmap binary the right
| capabilities for exactly the same reason.
|
| Sure, the attack surface of tcpdump is much smaller than
| wireshark, so the issue is not as pronounced, but
| wireshark indeed had a lot of vulnerabilities in the
| past: https://www.cvedetails.com/vulnerability-
| list/vendor_id-4861...
|
| It has tons of dissectors which aren't nearly as battle
| tested as my network stack.
| msm_ wrote:
| I agree in theory, but on my personal machine (and
| probably most other peoples' machines) all the
| interesting things are accessible by my account anyway.
| I'm not worried about malware changing my system
| configuration, I'm worried about a trojan stealing my
| passwords, keylogger watching what I type, stealer
| exfiltrating my data, or ransomware encrypting it. All of
| these don't really need a root account. Maybe the
| solution would be to use `sudo -u safe_tcpdump_user
| tcpdump`?
|
| I'm also going to add that I have passwordless sudo, so
| there's no meaningful difference in my case.
| [deleted]
| varjag wrote:
| Root escalation was kinda Big Deal in the days of multi-
| user systems and cohosting. Now I think it's mostly
| important in the context of breaking out from
| unprivileged services that would normally have no access
| to broader filesystem.
| jamal-kumar wrote:
| Weird security posture to be advertising to the world
| when two clicks gets me your first and last name
|
| Assuming you care about infosec from your profile,
| privilege escalation is definitely something you want to
| avoid especially if you're using these tools in for
| example a CTF engagement where the first thing I'll be
| doing is enumerating my adversaries
| yakubin wrote:
| You're parsing untrusted input. Doing it with the smallest
| set of privileges possible seems like a common sense thing to
| do.
| ye-olde-sysrq wrote:
| These other responses are great justification to _always_ dig
| into what someone 's threat model is. I've had so many
| "security" conversations get resolved something like this:
|
| other dev: this is insecure
|
| me: what's your threat model?
|
| other dev: <convoluted, opportunistic-only highly-timing-
| sensitive scenario that assumes attacker has gained internal
| network access>
|
| me: you do realize all our boxes have an
| "admin:password"-esque standard login available and
| passwordless sudo. if they're on our network they can already
| just do basically anything.
|
| People (well, devs) _love_ to think about security in very
| fine-grained detail, and honestly that 's good. We should all
| be thinking about this. But your security is only as good as
| your weakest link, and when your security policy already
| literally codifies "we will trust the firewall to make
| intranet security less annoying/complicated" then unless you
| want to go change that or your threat model is describing an
| attack on that security model, then please don't try to get
| overly clever.
|
| Now - that said - I do wish more orgs just did defense-in-
| depth from the beginning. It's so easy to provision certs
| nowadays that there's almost no reason not to do mTLS etc
| even in something like a homelab setting.
| tptacek wrote:
| This isn't a convoluted, timing-sensitive scenario; it's
| more like, there is the possibility that if you have
| tcpdump running anywhere, an attacker can strobe a packet
| that will trip a memory corruption vulnerability in some
| tcpdump printer, which is not, like, out of the realm of
| possibility.
| toast0 wrote:
| On FreeBSD, tcpdump runs with Capsicum, which may be sufficient
| sandboxing.
| iso1631 wrote:
| I used tcpdump a fair bit, with -T rtp, to pull our RTP sequence
| numbers, which I could then look for any discontinuities.
|
| It's a great way of finding shitty network devices like Juniper
| SRXs which just randomly and silently drop packets in the middle
| of flows.
| krupan wrote:
| I recently discovered netsniff-ng and it's really great too. It
| seems to recognize more protocols than tcpdump, like PTP. I use
| them both now.
| stonepresto wrote:
| You don't need wireshark to view packet data, use -X and -XX
| ye-olde-sysrq wrote:
| this is my favorite use of tcpdump, as a "just show me basic
| prints" live version of wireshark, which is like 90% of the
| time mostly what I want. Usually when I'm debugging stuff and
| am reaching for wireshark/tcpdump, I'm mostly just trying to
| figure out if traffic is hitting the right ports at all, and
| then only sometimes do I even care about metadata (packet size
| / count etc) and it's very rare I care about actual payload
| (not that you can even usually see it easily nowadays anyway
| since everything is TLS).
|
| recent example: used tcpdump -X to debug why my wireguard setup
| wasn't working, since with UDP you just kind of get a shrug as
| to _why_ or at what hop the udp packet got lost or filtered. So
| I ssh 'd to all the middle boxes and just tcpdumped the UDP
| ports I was interested in.
| netfortius wrote:
| Somehow related - can't praise enough ntopng [1]. I've used it
| not only in the more traditional manner, as active traffic
| analysis, but also as forensic tool, by passing it traffic
| capture files, and obtaining clear relationships and contributing
| end points apps and security issues. Highly recommend it.
|
| Edit: Forgot the nprobe [2] (same author), allowing flow data
| creation and export, expecially where L3 flow capable devices are
| not usable (e.g. intra-VLAN)
|
| [1] https://www.ntop.org/products/traffic-analysis/ntop/
|
| [2] https://www.ntop.org/products/netflow/nprobe/
| zX41ZdbW wrote:
| It is especially great, because it allows fast analytics on
| historical data with ClickHouse:
| https://www.ntop.org/ntop/historical-traffic-analysis-at-sca...
| seanw444 wrote:
| Kind of an unfortunate name. At first I thought it was "NToPNG"
| and was slightly confused.
| sneak wrote:
| Their website says it's GPL but I ran into some issue the last
| time I tried to try it out, it wanted a paid proprietary
| license or something?
| bhgtopt wrote:
| Nice
| 4ggr0 wrote:
| Just as a heads up if you wonder why your comment is gray and
| has a negative score.
|
| HN really doesn't like or wants comments saying "agree",
| "nice", "+1" etc., because they add nothing to the
| conversation. Just upvote a comment/post if you agree or like
| it :)
| PenguinCoder wrote:
| tcpdump is amazing. Question though; does anyone know why an ACK
| flag is displayed as a . instead of as A? I've not been able to
| find the reason for that.
| tptacek wrote:
| Probably because it would be visually noisy to do anything
| else, since ACK is set on almost every segment.
| [deleted]
___________________________________________________________________
(page generated 2023-02-02 23:02 UTC)