gor version: 1.3.0

Environment:

• Operating System: Ubuntu (running 6.8 kernel)
• Kernel Version: 6.8.0-52-generic #53-Ubuntu SMP PREEMPT_DYNAMIC Sat Jan 11 00:06:25 UTC 2025 x86_64
• Architecture: x86_64
• Environment Type: Cloud VM (e.g., DigitalOcean, based on earlier context)

Description of the Issue:

We are attempting to use gor --input-raw to capture unencrypted HTTP traffic flowing over the loopback interface (lo/127.0.0.1) on our server. Specifically, traffic from Caddy proxying to PHP-FPM (configured to listen on TCP 127.0.0.1:9000).

Despite confirming that traffic is flowing correctly on the target loopback port and interface and that the underlying libpcap library is functional for loopback capture using other tools, gor fails to capture any packets and does not create the specified output file or print anything to stdout when configured to do so.

Steps to Reproduce (on the affected server environment):

1. Ensure PHP-FPM is configured to listen on 127.0.0.1:9000 (TCP) on the loopback interface.
   (Confirmed this setup is active and listening via lsof -i :9000 | grep LISTEN)

2. Configure a web server (like Caddy) on the same machine to proxy requests to this PHP-FPM instance at 127.0.0.1:9000.

3. Ensure traffic is hitting the web server externally, resulting in requests being successfully proxied to 127.0.0.1:9000 internally.
   (Confirmed by Caddy access logs showing HTTP 200 status responses from PHP-FPM for PHP requests, and telnet 127.0.0.1 9000 working).

4. Run gor with --input-raw targeting the loopback address and port, and outputting to a file (or stdout):

   # Example using file output, run as root or with sudo
   sudo gor --input-raw 127.0.0.1:9000 --output-file /tmp/capture.gor -verbose 9

   (Also tried --input-raw localhost:9000, --output-stdout, removing -append, and targeting different directories like user's home and /var/log).

5. Send requests to the web server while gor is running.

6. Observe the output file location or stdout.

Observed Behavior:

• gor starts and prints initialization info (Interface: lo, BPF Filter: ((tcp dst port 9000) and (dst host 127.0.0.1 or dst host ::1)), Version 1.3.0).
• The gor process successfully starts and stays running (Sl+ state confirmed by ps aux).
• The specified output file (/tmp/capture.gor in this example, or files in other attempted directories) is never created.
• No captured data is printed to stdout when --output-stdout is used.
• No error messages are printed by gor to its own output during execution or upon Ctrl+C.

Expected Behavior:

gor should capture the TCP traffic flowing to 127.0.0.1:9000 on the loopback interface and write the captured requests (extracted HTTP from the FastCGI stream) to the specified output.

Diagnostic Findings (Crucial Information):

1. PHP-FPM is listening on 127.0.0.1:9000: Confirmed by lsof -i :9000.
2. Caddy is successfully connecting and communicating with PHP-FPM on 127.0.0.1:9000: Confirmed by Caddy access logs showing HTTP 200 statuses for requests proxied to PHP-FPM, and telnet 127.0.0.1 9000 successfully connects.
3. Traffic is visible and capturable on the loopback interface targeting port 9000 at the libpcap level by other tools: Confirmed by sudo tcpdump -i lo 'tcp port 9000' -nn -vvvv successfully showing the TCP handshake and data packets flowing between Caddy's ephemeral port and 127.0.0.1:9000 when requests are sent. This proves libpcap works on lo on this system.
4. Manual file creation works with the user running sudo in /tmp and other directories where gor was unable to create the output file.
5. A simpler loopback capture test with nc also failed with gor:
   • Running nc -l 8080 and sending traffic with echo ... | nc 127.0.0.1 8080 confirmed traffic arrived at 8080.
   • Running sudo gor --input-raw :8080 --output-stdout -v 9 simultaneously with the nc test showed no output from gor, confirming a failure to capture/output any loopback traffic, not just FastCGI, on this system using gor.
6. System logs show no errors related to gor or pcap: sudo journalctl -f (watched during gor run and request sending) shows no relevant denial or error messages from gor's PID, pcap, AppArmor, SELinux (checked status, seem inactive or not logging denials here), or kernel.

Conclusion from Diagnostics:

The issue is not with traffic flow, basic libpcap functionality on lo, or simple file permissions. Given that tcpdump -i lo works while gor --input-raw lo fails even for simple nc traffic and fails to create any output file despite the process running, it strongly suggests a specific incompatibility, bug, or environment interaction within the gor 1.3.0 binary on this Ubuntu kernel version (6.8.0-52-generic) that prevents it from capturing or processing loopback traffic correctly and/or writing any output.

Any insights or suggestions for further debugging steps would be greatly appreciated.