Repository navigation
eep: add TCP support for HEP3 listen - #583
Merged
Merged
Conversation
Kaian
requested changes
Oct 14, 2026
Kaian
left a comment
Kaian
left a comment
Member
There was a problem hiding this comment.
Awesome! 💯
I was not able to test TCP receiver (UDP still works as expected). It would be nice to include TCP also in the HEP sender logic!! :)
Thanks!
Kaian
approved these changes
Oct 16, 2026
The listen socket was always created as an IPv4 UDP socket, so binding an IPv6 eep.listen.address failed. Use the family and protocol returned by getaddrinfo, check the created server socket instead of the client one, and free the resolved address list. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add eep.listen.proto setting (udp or tcp, default udp) to select the protocol of the HEP listen socket. The -L url protocol prefix now sets it, so -L tcp:X.X.X.X:XXXX listens for HEP3 over TCP while existing udp: urls and settings keep working as before. TCP clients are handled from the existing EEP capture thread using poll(), up to 64 simultaneous connections. Each connection has its own buffer where received data is stored until a full HEP3 packet is available, using the HEP3 total length field, so packets split in several reads or several packets in a single read are parsed properly. Connections sending data that is not HEP3 or packets that do not fit in the buffer are closed. HEPv2 has no total length field, so TCP listen requires HEP version 3. Closes irontec#501 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HEP3 packets are received from the network, but the parser trusted the total length and chunk lengths found in them: chunks could be read past the received data or the packet total length, chunks shorter than their header produced negative payload sizes, and received authentication keys were compared without a string terminator. Drop HEP3 packets that are shorter than the HEP3 header, longer than the received data, or contain chunks that do not fit in the packet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Homer can receive HEP over TCP, but -H only accepted udp: urls. Add an eep.send.proto setting, filled from the -H url scheme, so captured packets can also be sent through a TCP connection. HEPv2 has no length field to frame packets on a stream, so TCP send requires HEP version 3. Full frames are written under a lock, so packets sent from different capture threads never interleave on the connection, and HEP3 packets longer than the 16-bit length fields allow are not sent. While here, release the resolved address and the socket when the connection fails, and return the send result from the v2 sender. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kaian
force-pushed
the
feat/hep3-tcp-listener-501
branch
from
October 16, 2026 08:02
56a18d9 to
fe3a8ec
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add TCP support for the HEP listen socket, as requested in #501.
A new
eep.listen.protosetting (udportcp, defaultudp) selects the listen socket protocol, and it is also available in the EEP/HEP settings dialog. The-Lurl protocol prefix now sets it:Existing
udp:urls andeep.listen.*settings keep working as before.TCP clients are handled from the existing EEP capture thread with
poll()(up to 64 simultaneous connections), so no new threads are added. Each connection keeps its own buffer until a full HEP3 packet is received, using the HEP3 total length field, so packets split across several reads or several packets in a single read are parsed properly. Connections sending data that is not HEP3, or packets that do not fit in the capture buffer, are closed without affecting other clients. HEPv2 has no total length field, so TCP listen requireseep.listen.version 3.Other fixes in the HEP listen path, as separate commits:
-O). Now only parsed packets are dumped.eep.listen.addressfailed to bind. It now uses the address family returned bygetaddrinfo.Closes #501
Validation
./configure --enable-eep --enable-ipv6 --with-pcre2make -j$(nproc): no new warnings. CMake build with-DUSE_EEP=ONalso builds.make check: 14/14 passedsngrep -N -F -L tcp:127.0.0.1:19061 -O tcp.pcapand a Python HEP3 sender.tsharkfound every expected Call-ID in the output pcap:send(), and the rest later-L udp:127.0.0.1:19062still receives HEP3 over UDP. IPv6 (::1) was tested over TCP and UDP witheep.listen.*settings in an rc file.-L tcp:witheep.listen.version 2printsEEP server: TCP listen requires HEP version 3.🤖 Generated with Claude Code