Development Documentation:
- Complete development history and commit reference
- Four-phase implementation breakdown with detailed descriptions
- Key commit hashes with functional descriptions
- Project structure overview with file descriptions
- Build and test command reference
Reproducibility Guide:
- Step-by-step development phases documented
- Commit-by-commit feature implementation tracking
- Docker and testing infrastructure setup
- Usage examples for all major features
- Troubleshooting and architecture guidance
This documentation allows future developers or Claude instances to:
- Understand the complete development process
- Reproduce the implementation step-by-step
- Navigate the codebase structure effectively
- Run tests and demonstrations independently
- Extend functionality with proper context
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
README Documentation:
- Complete project overview and architecture description
- Detailed installation and setup instructions
- Comprehensive usage examples for all features
- Command-line reference with all options
- Structured logging format specifications
Key Documentation Sections:
- XDP vs other eBPF hook point comparison
- Performance considerations and tuning guide
- Security considerations and best practices
- Troubleshooting guide for common issues
- Development workflow and contribution guidelines
Usage Examples:
- Basic traffic monitoring setup
- Structured logging in multiple formats
- Log analysis and threat detection workflows
- Configuration management examples
- Docker and containerized deployments
Technical Details:
- eBPF program architecture and data flow
- Ring buffer communication mechanisms
- CIDR range configuration and validation
- Logging system design and performance
- Threat detection algorithms and thresholds
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Configuration Files:
- configs/default.json: Standard private network CIDR ranges
- configs/strict.json: Restrictive localhost-only configuration
- configs/logging-example.json: Example with logging settings
Test Suite (tests/integration_tests.rs):
- Comprehensive integration tests for all components
- CIDR parsing and IP matching validation
- Event handling and statistics verification
- Configuration loading and validation tests
- Error handling and edge case coverage
Features Tested:
- IP address parsing and CIDR range matching
- Traffic event processing and statistics
- Configuration file loading and validation
- Protocol detection and classification
- Event handler statistics and summaries
Quality Assurance:
- Edge case handling for malformed inputs
- Performance testing for high-volume scenarios
- Memory safety verification for eBPF integration
- Cross-platform compatibility testing
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Main Program (main.rs):
- Command-line interface using clap with comprehensive options
- eBPF program lifecycle management (load, configure, attach)
- Integration with structured logging system
- Graceful shutdown handling with log flushing
Command-Line Options:
- Interface selection for XDP attachment
- Configuration file path for CIDR ranges
- Packet action control (log-only vs drop)
- Logging format selection (console/json/csv/jsonl)
- Output file specification and buffer size tuning
- Verbose logging for debugging
eBPF Integration:
- Automatic eBPF program loading and BTF initialization
- CIDR range configuration via eBPF maps
- Real-time event processing from ring buffers
- XDP attachment with fallback to SKB mode
Enhanced Features:
- Structured event logging with flow correlation
- Real-time statistics and periodic summaries
- Signal handling for clean shutdown
- Error handling with context preservation
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Core eBPF Program (traffic_monitor.bpf.rs):
- XDP-based packet processing for high performance
- IP header parsing and CIDR range matching
- Configurable packet dropping or logging
- Ring buffer event logging to userspace
Supporting Modules:
- config.rs: JSON configuration management for CIDR ranges
- ip_utils.rs: CIDR parsing and IP matching utilities
- event_handler.rs: Traffic event processing and statistics
- lib.rs: Module exports and shared structures
Key Features:
- Line-rate packet filtering in kernel space
- Support for up to 256 permitted CIDR ranges
- Real-time event streaming via ring buffers
- Protocol-aware logging (TCP/UDP/ICMP/etc.)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add Cargo.toml with aya dependencies and project configuration
- Add build.rs with aya-build integration for eBPF compilation
- Configure workspace and example targets
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements TryFrom for FdLink for CgroupSkb, CgroupSock, CgroupSockAddr
and SockOps program types. This allows support for link pinning for
these program types, aligning with the documentation for FdLink.
Fixes: #739
Co-authored-by: Benjamin Barzen <bbarzen@amazon.com>
Short-circuits `CACHE` to true if the field is non-zero.
This saves from executing the probing logic since the logic essentially
checks if the field can process (or doesn't error) non-zero value.
Cached probed for ProgramInfo fields instead of exposing it through
global FEATURE. Probing occurs on cache miss, which happens when first
accessing the field, *and* if the field is 0.
We have had loaded_links in the API as `#[doc(hidden)]` for a while.
I've been using it in bpfman and it's been fine. This commit does the
minimal work required to make the API stable.
We expose a `LinkInfo` type - similar to `ProgInfo` - which wraps the
generated type. In this case, `bpf_link_info`.
A few accessor functions have been added for `id`, `link_type` and
`program_id`. There are many more fields that could be (eventually)
made public.
As a convenience, `LinkInfo` can be retrieved from an existing FdLink
by using `FdLink::info()`.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Make the xz2 dependency optional to allow building without a C cross
compiler. This allows clippy.sh to be used on e.g. macOS more easily:
```
./clippy.sh --target x86_64-unknown-linux-gnu --exclude-features xz2
```
Krish Sharma
Tamir Duberstein
dependabot[bot]
tamird
Mehnaz Yunus
Tyrone Wu
Dave Tucker
Omri Steiner