New option --oiface for outgoing interface by gsnw-sebast · Pull Request #463 · schweikert/fping

gsnw-sebast · 2026-02-22T09:31:12Z

With this new option, it should be possible to send a packet on one interface and receive any packet on another. There is no fallback to SO_BINDTODEVICE, for example. The -I option must be used for this.

Unfortunately, it is difficult for me to test this behavior. Therefore, I have only worked with the debugger.

gemini-code-assist · 2026-02-22T09:31:32Z

Summary of Changes

Hello @gsnw-sebast, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new --oiface command-line option for fping, enabling users to explicitly define the network interface through which outgoing ping packets are sent. This enhancement provides more granular control over network traffic, allowing pings to originate from a specific interface while still permitting the reception of responses from any available interface. The implementation utilizes IP_PKTINFO and IPV6_PKTINFO for robust interface binding.

Highlights

New --oiface option: Introduced a new command-line option --oiface to specify the outgoing network interface for ping packets.
Separate send/receive interfaces: This option allows sending packets via a specific interface while still being able to receive responses on any interface, differentiating it from the existing -I (SO_BINDTODEVICE) option.
IP_PKTINFO implementation: The functionality is implemented using IP_PKTINFO for IPv4 and IPV6_PKTINFO for IPv6, leveraging sendmsg to attach control messages with interface information.
Test case and documentation: A new test case was added for the --oiface option, and the fping man page was updated to include its description.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

CHANGELOG.md
- Added an entry for the new --oiface feature.
ci/test-07-options-i-m.pl
- Increased the test count and added a new test case for the --oiface option, specifically for Linux.
doc/fping.pod
- Documented the newly introduced --oiface command-line option, explaining its purpose.
src/fping.c
- Registered the --oiface option in the command-line parser and added logic to handle its argument, calling interface-setting functions.
- Added a check for IP_PKTINFO availability when --oiface is used.
src/fping.h
- Declared new functions socket_set_outgoing_iface_ipv4 and socket_set_outgoing_iface_ipv6.
src/socket4.c
- Included net/if.h for interface functions.
- Added a static variable outgoing_iface_idx_ipv4 to store the outgoing interface index.
- Implemented socket_set_outgoing_iface_ipv4 to resolve the interface name to an index and set the IP_PKTINFO socket option.
- Modified socket_sendto_ping_ipv4 to use sendmsg with IP_PKTINFO control messages if an outgoing interface is specified.
src/socket6.c
- Included net/if.h for interface functions.
- Added a static variable outgoing_iface_idx_ipv6 to store the outgoing interface index.
- Implemented socket_set_outgoing_iface_ipv6 to resolve the interface name to an index and set the IPV6_RECVPKTINFO socket option.
- Modified socket_sendto_ping_ipv6 to use sendmsg with IPV6_PKTINFO control messages if an outgoing interface is specified.

Activity

The author, @gsnw-sebast, implemented the --oiface option to allow sending packets on one interface and receiving on another, noting it's distinct from SO_BINDTODEVICE.
The author mentioned that testing this specific behavior was challenging and primarily relied on debugger analysis.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request introduces a new --oiface option to specify the outgoing network interface for ping packets. The implementation correctly uses sendmsg with ancillary data (IP_PKTINFO for IPv4 and IPV6_PKTINFO for IPv6) to achieve this. The changes are well-structured and include documentation and a basic test case. My review includes a couple of suggestions for improvement: one to clarify a comment in the new test and another to make the command-line option parsing more robust to prevent potential issues with future options.

ci/test-07-options-i-m.pl

gemini-code-assist · 2026-02-22T09:33:17Z

src/fping.c

 #endif
            } else if (strstr(optparse_state.optlongname, "seqmap-timeout") != NULL) {
                opt_seqmap_timeout = strtod_strict(optparse_state.optarg) * 1000000;
+            } else if (strstr(optparse_state.optlongname, "oiface") != NULL) {


Using strstr to check for the option name is not robust. It could lead to incorrect behavior if another long option is added that contains "oiface" as a substring (e.g., --oiface-extra). A more precise check using strncmp would be safer and prevent potential future bugs. This applies to other long option checks in this block as well, but this change should at least be applied for the new option.

} else if (strncmp(optparse_state.optlongname, "oiface", 6) == 0 && (optparse_state.optlongname[6] == '\0' || optparse_state.optlongname[6] == '=')) {

coveralls · 2026-02-22T09:34:19Z

coverage: 87.947% (-0.2%) from 88.152%
when pulling ba543cb on gsnw:oiface
into fd87284 on schweikert:develop.

schweikert

The code should be tested to work before it is submitted (on a host with multiple interfaces).

schweikert · 2026-03-22T06:54:53Z

ci/test-07-options-i-m.pl

 $cmd->stderr_like(qr{binding to specific interface \(SO_BINDTODEVICE\):.*\n});
 }

+# fping --oiface=IFACE


The IPv6 code is not tested at the moment I think.

I have expanded the test to include IPv6

schweikert · 2026-03-22T06:56:31Z

src/fping.c

 #endif
            } else if (strstr(optparse_state.optlongname, "seqmap-timeout") != NULL) {
                opt_seqmap_timeout = strtod_strict(optparse_state.optarg) * 1000000;
+            } else if (strstr(optparse_state.optlongname, "oiface") != NULL) {


You said that setting -I is also required? Should you check that that option is set as well?

Sorry for the unclear description. What I meant was that if the user wants to use SO_BINDTODEVICE again, they must explicitly use -I instead of --oiface. If --oiface doesn't work, there is no fallback to SO_BINDTODEVICE.

But that reminds me. The --oiface option must not be used together with the -I option.

gsnw-sebast · 2026-03-29T12:27:57Z

I was able to successfully test the whole thing using an Azure Pipeline. This means it should also be testable automatically via a GitHub workflow.

Test case

Ping 10.0.2.2 (target on interface 2)
Force the output through veth2_tst
Set the source IP to 10.0.1.1 (interface 1)

Bash script

set -ex

NS_TESTER="tester_ns"
NS_TARGET="target_ns"
LOG_FILE="/tmp/asym_trace.log"

cleanup() {
    echo "--- FINALER TRACE-LOG ---"
    [ -f "$LOG_FILE" ] && cat $LOG_FILE
    sudo ip netns del $NS_TESTER 2>/dev/null || true
    sudo ip netns del $NS_TARGET 2>/dev/null || true
}
trap cleanup EXIT

echo "--- Network-Setup ---"
sudo ip netns add $NS_TESTER
sudo ip netns add $NS_TARGET

sudo ip link add veth1_tst type veth peer name veth1_trg
sudo ip link add veth2_tst type veth peer name veth2_trg

sudo ip link set veth1_tst netns $NS_TESTER
sudo ip link set veth2_tst netns $NS_TESTER
sudo ip link set veth1_trg netns $NS_TARGET
sudo ip link set veth2_trg netns $NS_TARGET

sudo ip netns exec $NS_TESTER ip addr add 10.0.1.1/24 dev veth1_tst
sudo ip netns exec $NS_TESTER ip addr add 10.0.2.1/24 dev veth2_tst
sudo ip netns exec $NS_TARGET ip addr add 10.0.1.2/24 dev veth1_trg
sudo ip netns exec $NS_TARGET ip addr add 10.0.2.2/24 dev veth2_trg

sudo ip netns exec $NS_TESTER ip link set veth1_tst up
sudo ip netns exec $NS_TESTER ip link set veth2_tst up
sudo ip netns exec $NS_TESTER ip link set lo up
sudo ip netns exec $NS_TARGET ip link set veth1_trg up
sudo ip netns exec $NS_TARGET ip link set veth2_trg up
sudo ip netns exec $NS_TARGET ip link set lo up

echo "--- Configuration for asymmetric routing ---"
for ns in $NS_TESTER $NS_TARGET; do
    sudo ip netns exec $ns sysctl -w net.ipv4.conf.all.rp_filter=0
    sudo ip netns exec $ns sysctl -w net.ipv4.conf.default.rp_filter=0
    sudo ip netns exec $ns sysctl -w net.ipv4.conf.all.accept_local=1
    sudo ip netns exec $ns sysctl -w net.ipv4.ip_forward=1

    for dev in $(sudo ip netns exec $ns ls /sys/class/net/); do
        sudo ip netns exec $ns sysctl -w net.ipv4.conf.$dev.rp_filter=0 2>/dev/null || true
    done
done

T_MAC2=$(sudo ip netns exec $NS_TARGET cat /sys/class/net/veth2_trg/address)
sudo ip netns exec $NS_TESTER arp -s 10.0.2.2 $T_MAC2 -i veth2_tst

echo "--- Tests ---"
sudo ip netns exec $NS_TESTER tcpdump -i any icmp -n -l > $LOG_FILE 2>&1 &
TCP_PID=$!
sleep 2

echo "Send fping (asymmetry check)..."
sudo ip netns exec $NS_TESTER ./src/fping -c 1 -t 1000 --oiface veth2_tst -S 10.0.1.1 10.0.2.2 || FPING_STATUS=$?

sleep 1
sudo kill $TCP_PID 2>/dev/null || true
sleep 1

echo "--- Analysis ---"

REQ_OK=$(grep "veth2_tst Out IP 10.0.1.1 > 10.0.2.2" $LOG_FILE | wc -l)
REP_OK=$(grep "veth1_tst In  IP 10.0.2.2 > 10.0.1.1" $LOG_FILE | wc -l)

if [ "$REQ_OK" -gt 0 ] && [ "$REP_OK" -gt 0 ]; then
    echo "RESULT: TEST SUCCESSFUL (True asymmetry detected)"
    exit 0
else
    echo "RESULT: TEST FAILED"
    [ "$REQ_OK" -eq 0 ] && echo "- The request was not sent correctly with source 10.0.1.1 via veth2_tst."
    [ "$REP_OK" -eq 0 ] && echo "- The reply was not received asymmetrically via veth1_tst."
    exit 1
fi

Result

The request is sent out via veth2_tst
The reply comes in via veth1_tst (because the destination 10.0.1.1 in the target namespace is routed via veth1_trg)

Send ping

sudo ip netns exec tester_ns ./src/fping -c 1 -t 1000 --oiface veth2_tst -S 10.0.1.1 10.0.2.2
10.0.2.2 : [0], 64 bytes, 0.046 ms (0.046 avg, 0% loss)

10.0.2.2 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.046/0.046/0.046

tcpdump

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:14:36.573032 veth2_tst Out IP 10.0.1.1 > 10.0.2.2: ICMP echo request, id 4010, seq 0, length 64
12:14:36.573063 veth1_tst In  IP 10.0.2.2 > 10.0.1.1: ICMP echo reply, id 4010, seq 0, length 64

2 packets captured
2 packets received by filter
0 packets dropped by kernel

gsnw-sebast linked an issue Feb 22, 2026 that may be closed by this pull request

New option for "outgoing interface" #62

Open

gemini-code-assist bot reviewed Feb 22, 2026

View reviewed changes

gsnw-sebast force-pushed the oiface branch from 81a6f53 to 060128c Compare February 22, 2026 09:35

gsnw-sebast requested a review from schweikert February 22, 2026 11:02

gsnw-sebast requested a review from auerswal March 8, 2026 06:25

schweikert requested changes Mar 22, 2026

View reviewed changes

gsnw-sebast added 3 commits March 27, 2026 11:30

New option --oiface for outgoing interface

c84a8ae

The --oiface option is not allowed with -I --iface

a8ee3ca

Add IPv6 test for --oiface

57545c9

gsnw-sebast force-pushed the oiface branch from 4bcab43 to 57545c9 Compare March 27, 2026 10:31

Fix: set ipi_spec_dst from -S source address in sendmsg()

10ce973

Test asymmetric routing (--oiface)

ba543cb

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New option --oiface for outgoing interface#463

New option --oiface for outgoing interface#463
gsnw-sebast wants to merge 5 commits intoschweikert:developfrom
gsnw:oiface

gsnw-sebast commented Feb 22, 2026

Uh oh!

gemini-code-assist bot commented Feb 22, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

gemini-code-assist bot Feb 22, 2026

Uh oh!

coveralls commented Feb 22, 2026 •

edited

Loading

Uh oh!

schweikert left a comment

Uh oh!

schweikert Mar 22, 2026

Uh oh!

gsnw-sebast Mar 22, 2026

Uh oh!

schweikert Mar 22, 2026

Uh oh!

gsnw-sebast Mar 22, 2026

Uh oh!

gsnw-sebast commented Mar 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

gsnw-sebast commented Feb 22, 2026

Uh oh!

gemini-code-assist bot commented Feb 22, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

gemini-code-assist bot Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

coveralls commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

schweikert left a comment

Choose a reason for hiding this comment

Uh oh!

schweikert Mar 22, 2026

Choose a reason for hiding this comment

Uh oh!

gsnw-sebast Mar 22, 2026

Choose a reason for hiding this comment

Uh oh!

schweikert Mar 22, 2026

Choose a reason for hiding this comment

Uh oh!

gsnw-sebast Mar 22, 2026

Choose a reason for hiding this comment

Uh oh!

gsnw-sebast commented Mar 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

coveralls commented Feb 22, 2026 •

edited

Loading