# Packet Sender: a GUI and CLI for sending TCP, UDP, SSL and HTTP packets

> Packet Sender is a cross-platform Qt desktop tool plus command line interface for crafting and receiving raw TCP, UDP and SSL traffic and HTTP requests. It is built for engineers who need to reproduce a protocol exchange by hand, and its main constraint is that it is a manual instrument, not a test harness.

**dannagle/PacketSender** — Network utility for sending / receiving TCP, UDP, SSL, HTTP

- Repository: https://github.com/dannagle/PacketSender
- Website: https://packetsender.com
- Stars: 2,681 · Forks: 397
- Language: C++
- License: GPL-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/dannagle-packetsender

## The problem Packet Sender solves: bytes on the wire without writing a client

Most network debugging starts with a question that a full application cannot answer cleanly. Did the device actually receive the payload, or did the socket accept it and drop it? Is the server replying with a status line the client never parses? Writing a throwaway Python or Go client to find out costs twenty minutes and usually hides the very framing detail you are chasing, because your client library normalises it away.

Packet Sender's answer is a table of saved packets, each with a name, a destination address, a port and a payload. The README describes domain names as being resolved just before sending, which matters when you are testing against a host that changes address or a service that only resolves inside a VPN. Payloads are entered in a mixed ASCII and HEX notation: backslash escapes such as \n, \r and \t are translated to 0A, 0D and 09, and \XX is translated to the byte XX. The HEX field accepts space-delimited bytes and also tries to auto-correct other common delimiters, including commas, colons as Wireshark prints them, semicolons and a leading 0x. A single unbroken hex stream is accepted too; if the byte count is odd, the tool assumes the leading byte needs a zero and corrects it.

The audience is narrow and specific. Test engineers bringing up embedded devices, industrial and lighting control work (one sponsor listed in the README installs lighting and audiovisual systems for museums and showrooms), protocol implementers checking a spec against a real stack, and support engineers who need to prove which side of a connection is misbehaving. It is not a load tester, and it is not a packet capture tool: it sends and receives application payloads, it does not decode frames.

## How Packet Sender works: saved packets, protocol servers and the traffic log

The architecture is a Qt desktop application with an in-process server layer. In the bottom right of the GUI there are UDP, TCP and SSL server status indicators and port fields. Clicking one activates or deactivates that protocol, and the README states that Packet Sender supports binding to any number of ports. That is the part people underestimate: you can leave a UDP listener on one port and a TCP listener on another at the same time, send from the same window, and watch both in the traffic log.

An IP toggle button switches between IPv4 (the default), IPv6 and a custom IP. For IPv6 sending the README notes you also need the scope ID, which is the detail that trips people up when they try to reach a link-local address and get silence.

Each packet row carries a resend delay. A resend value of 0 means a single-shot packet; any other value makes it repeat, and while resending there is a button to cancel all resends. That is the whole traffic generator at the GUI level. The README also documents a separate Intense Traffic Generator section for both GUI and CLI, so the repeat mechanism and the intense generator are distinct features rather than the same control at two verbosity levels.

Responses are handled by a single optional response payload that the README says is shared across TCP, UDP and SSL. If you need protocol-specific replies you will be switching that field by hand. There is also a Macros and Smart Responses section, which is where conditional or pattern-based replies live; the README lists it as a top-level feature but does not spell out the matching rules in the available documentation.

Finally, the traffic log is not read-only. You can save a packet directly from the log, at which point you are prompted for a name and the source address and port are swapped for you, which is exactly the convenience you want when you have just received an interesting packet from a device and need to reply to it.

## Installing Packet Sender and sending your first UDP packet

The README points to packetsender.com/download for official desktop releases and notes that other places redistribute the binary. The mainline branch officially supports Windows, Mac and desktop Linux with Qt. On Linux, the repository carries a snapcraft.yaml at the top level, so a snap build path exists in-tree, and the README's own instructions for Ubuntu are what the search traffic is looking for. If you prefer to build from source, the README has a Building Packet Sender section and the source lives under src/.

Once installed, the first useful exercise is a loopback test: send a UDP packet to yourself and confirm the listener sees it. In the GUI, enable the UDP server and note the port it binds, then create a packet whose address is 127.0.0.1 and whose port is that same port.

Type the ASCII payload hello world\r. The README gives exactly this as the ASCII example, and the corresponding HEX is 68 65 6c 6c 6f 20 77 6f 72 6c 64 0d. Double-clicking either field opens a multi-line editor if you need to paste a larger body.

For scripted use, the README documents a Command Line Interface section. The CLI is the right entry point when you want the same send from a shell, and the README documents an Intense Traffic Generator for the CLI as well. The README states the theoretical limit for sending via the command line is 200 MB, while the HEX field in the GUI supports up to 10,922 bytes. That gap is worth remembering: if you are pushing a large payload, the GUI field will refuse it long before the CLI does.

One practical note from the README that is easy to skip: a resend value of 0 means single-shot. If you set a delay expecting one packet and get a stream, that is why.

## Portable mode, HTTP requests and the panel generator

Three features sit outside the core send-and-receive loop and change who can use the tool.

Portable mode is documented as a top-level section. That matters in environments where you cannot install software: a lab machine, a locked-down build server, a customer site. It also means the tool can live on a USB stick alongside a config, which is a genuinely different deployment story from a snap or an MSI. The search data shows people looking for packetsender portable and packetsender exe, which lines up with that use case rather than with a package manager install.

HTTP/HTTPS support arrived as first-class verbs. The v8.11.1 release is titled New HTTP Verbs!, and the README lists GET, POST, PUT, PATCH and DELETE. This is a real shift in scope. Once Packet Sender speaks HTTP, it overlaps with curl and with Postman-style clients, and the trade-off is that it gives you raw socket control and HTTP in one window rather than being best-in-class at either. For someone debugging a device that speaks HTTP on port 80 but also emits a proprietary UDP heartbeat, that combination is the reason to pick it.

The panel generator is the least conventional feature. The README describes it as panel generation and lists it as a top-level section. In practice this is aimed at building a control surface of buttons for predefined packets, which is how you hand a test rig to someone who should not be editing hex by hand. It is also the feature most likely to be misunderstood by a new user expecting a general-purpose dashboard.

There is also a Packet Sender Cloud section and a Wake-On-LAN / Magic Packet section, plus an IPv4 subnet calculator. Those are conveniences bundled into the same binary rather than separate tools, and they are the kind of thing that either saves you a browser tab or adds menu clutter, depending on how often you touch them.

## Where Packet Sender is the wrong tool

The firewall caveat is not a footnote. The README says plainly that Windows aggressively blocks TCP-based servers and that Packet Sender will still work if the firewall blocks it, but it cannot receive unsolicited TCP-based packets. That is a silent failure mode: sending succeeds, nothing arrives, and the tool looks broken. The README's own suggested remedy is to temporarily disable the firewall. If your test depends on inbound TCP from a device that initiates the connection, budget time for this before you conclude the device is at fault.

The second limitation is scale and automation. There is a CLI, and there is an intense traffic generator in both GUI and CLI form, but the README does not document a scripting API, an assertion mechanism, or a way to fail a build based on a response. If your requirement is a repeatable regression suite with pass/fail output, Packet Sender is a manual instrument that happens to have a command line, not a test framework. You will end up parsing its output or wrapping it, and the wrapping is where the value would have to come from.

The third is payload handling. The GUI HEX field tops out at 10,922 bytes per the README. Large binary payloads, file transfer testing, or anything approaching the CLI's 200 MB theoretical ceiling is not a GUI workflow.

Finally, the response model is one shared response for TCP, UDP and SSL. If you are simulating a device that answers differently per transport, or that needs stateful multi-step replies, the single response field will not carry you. That is what the Macros and Smart Responses feature is presumably for, and the README lists it without the rules in the available documentation, so treat it as something to verify against the running application rather than something you can plan around from the documentation alone.

## Packet Sender compared with nc and socat

The obvious alternative for anyone comfortable in a terminal is netcat, or socat where you need more control. The difference in approach is structural rather than a matter of feature lists.

nc and socat are stream plumbing. You pipe bytes in, they go out; bytes come back, they go to stdout. They compose with the rest of the shell, which is why they are the default answer for scripted work. What they do not give you is a persistent list of named packets you can click, a traffic log that records both directions with timestamps, a panel of buttons for a non-engineer, or a single window where a UDP listener and a TCP listener are both running while you send. Packet Sender is stateful and visual; nc is stateless and textual.

For SSL specifically, socat can wrap a connection in TLS, but you are assembling certificate arguments yourself. Packet Sender treats SSL as a first-class protocol alongside TCP and UDP, with its own server toggle. If you spend your day explaining to colleagues what you sent, the GUI is the difference.

For HTTP, curl is the comparison that matters. curl is scriptable, has an enormous option surface, and is present on nearly every machine. Packet Sender's HTTP verbs are a convenience inside a packet tool, not a replacement. If HTTP is all you do, use curl.

The honest summary is that the two approaches are complementary. Use nc or socat when the output needs to feed another program. Use Packet Sender when a human needs to see the exchange, repeat it on demand, and hand it to someone else.

## Licence, maintenance and what upgrading costs you

Packet Sender is licensed GPL v2 or later, and the README states it can be used for both commercial and personal use. GPL-2.0-or-later is a copyleft licence, so if you redistribute the application or a modified version, the licence terms attach to that distribution. Using it internally as a debugging tool is a different question from shipping it inside a product, and the README does not attempt to resolve that distinction. If your intended use involves redistribution or bundling, that is a question for your own legal review, not something this article can settle.

The repository is not archived, and the last push was on 2026-09-13. Recent releases are close together: v8.10.4 on 2026-03-01, v8.10.5 on 2026-03-23, and v8.11.1 on 2026-08-16. The release titles are informative about the project's rhythm: a bug fix and Chinese translation release, then a Mac build fix, then a feature release adding HTTP verbs. That pattern suggests a single-maintainer cadence where platform build breakage is handled promptly and features arrive when they arrive.

The upgrade cost is low in the ordinary case, because the GUI is described as identical across desktop versions with only the OS theme differing. The risk sits in the command line interface: if you script against CLI flags, a release that changes them breaks your automation silently. Pin a version for anything scripted, and read the release notes for the version you are moving to before you move. For interactive use, upgrading is close to free.

## Conclusion

Adopt Packet Sender when you need to hand-craft a packet, stand up a throwaway UDP or TCP server on an arbitrary port, or show a colleague the exact bytes on the wire. Do not adopt it as an automated regression suite: there is no documented scripting API beyond the CLI, no assertion model, and no CI integration in the repository beyond its own build pipeline. Before committing to it, verify two things on your own machine: that your firewall permits the listening side, since the README notes Windows aggressively blocks TCP-based servers, and that the CLI flags you intend to use exist in the build you downloaded, because the README's command line section is the part most likely to drift from the binary.

## FAQ

### What does Packet Sender do?

It is an open source utility for sending and receiving TCP, UDP and SSL packets, plus HTTP/HTTPS requests using GET, POST, PUT, PATCH and DELETE. It runs as a Qt desktop application on Windows, Mac and desktop Linux, and also ships a command line interface.

### How do I send a packet to an IP with Packet Sender?

Create a packet row with a name, the destination address, a port and a payload, then send it. Domain names are resolved just before sending, and the IP toggle button switches between IPv4 (the default), IPv6 and a custom IP; for IPv6 you also need the scope ID.

### Should I use UDP or TCP in Packet Sender?

The README does not prescribe one over the other; both are first-class protocols with their own server toggles, and the same optional response payload is used for TCP, UDP and SSL. The practical difference is that the README warns Windows aggressively blocks TCP-based servers, so inbound TCP may be silently dropped until the firewall is adjusted.

### How do I install Packet Sender on Ubuntu?

Official desktop releases are at packetsender.com/download, and the mainline branch officially supports desktop Linux with Qt. The repository includes a snapcraft.yaml at the top level, and the README has a Building Packet Sender section if you prefer to compile from the src/ directory.

### What is a good Packet Sender alternative?

For scripted work, nc or socat cover the same ground as stream plumbing that composes with the shell, and curl covers HTTP. Packet Sender's difference is a stateful GUI with saved named packets, a two-way traffic log, simultaneous UDP and TCP listeners, and a panel generator for handing a test rig to someone else.

## Sources

- [dannagle/PacketSender on GitHub](https://github.com/dannagle/PacketSender)
- [License: GPL-2.0](https://github.com/dannagle/PacketSender/blob/master/LICENSE)
- [Project website](https://packetsender.com)
- [README](https://github.com/dannagle/PacketSender/blob/master/README.md)
- [Releases](https://github.com/dannagle/PacketSender/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dannagle-packetsender