Don't dismiss warnings without understanding them - investigate to determine if they indicate bugs, misconfigurations, or are cosmetic, then document findings either way
Warnings in output (compiler, runtime, CLI tools) shouldn't be automatically dismissed or ignored. Each warning deserves investigation to understand:
All three require documentation explaining the finding.
Core Principle: Every warning has a reason. Understand it, then decide.
Use this skill when:
$ ping6 -I demop ff02::1
ping6: Warning: source address might be selected on device other than: demop
# "Probably fine, ignore it"
Problems:
Session example:
$ ping6 -I test_mainp ff02::1
ping6: Warning: source address might be selected on device other than: test_mainp
User: "Should we be concerned about the warning?"
Investigation process:
ip addr show test_mainpfe80::... (from MAC)fe80::... (random IID)Conclusion:
% notation rather than -I: ping6 ff02::1%test_mainpResult: User has confidence warning is harmless, future users won't be concerned.
Example:
// Warning: variable 'err' is never checked
result, err := doSomething()
return result
Investigation:
Fix:
result, err := doSomething()
if err != nil {
return nil, fmt.Errorf("doing something: %w", err)
}
return result
Example:
WARNING: Running tests without -v flag may hide failure details
Investigation:
Fix:
# Add -v flag to test commands
go test -v ./...
Example:
ping6: Warning: source address might be selected on device other than: demop
Investigation:
Documentation:
## Troubleshooting
**Warning: "source address might be selected on device other than"**
- Cosmetic warning from ping6
- Occurs when multiple link-local addresses exist on interface
- Packets flow correctly; eBPF programs capture traffic as expected
- No action needed
Capture exact warning:
# Save full output
command 2>&1 | tee output.log
Note context:
For network warnings:
ip addr show <interface>
ip link show <interface>
ip route show
For eBPF warnings:
sudo bpftool prog list
sudo bpftool map list
dmesg | tail
For build warnings:
# Check actual definitions
go doc <package>.<Type>
# Verify imports
go list -m all
Check documentation:
man ping6go docSearch issues:
gh issue list --repo <org>/<repo> --search "warning text"
Web search:
Does it affect functionality?
Session example:
# Warning appeared but eBPF still captured packets
[peer] IPv6: fe80::... -> ff02::1 | next=58 len=64 ttl=255
# ✓ Functionality works despite warning
In code (for build/lint warnings):
// Suppress "unused" warning: keepalive ticker prevents connection timeout
_ = keepaliveTicker
In README (for runtime warnings):
### Known Warnings
**ping6 source address warning**
- Expected when interface has multiple link-local addresses
- Does not affect packet delivery
- See: https://man7.org/linux/man-pages/man8/ping.8.html
In commit message:
Add IPv6 link-local configuration
Note: ping6 may warn about source address selection when interface
has both kernel-generated and manually assigned link-local addresses.
This is cosmetic and doesn't affect functionality.
Warning:
ping6: Warning: source address might be selected on device other than: test_mainp
Investigation:
$ ip addr show test_mainp
12: test_mainp@test_main: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
link/ether 96:8b:bf:87:91:04
inet6 fe80::a4b3:12ff:fe34:5678/64 scope link # Our assigned
inet6 fe80::948b:bfff:fe87:9104/64 scope link # Kernel generated
Conclusion: Two link-local addresses → ping6 unsure which to use → warning
Documentation added to README:
Warning: "source address might be selected on device other than"
- Cosmetic warning from ping6
- Occurs when multiple link-local addresses exist
- Packets still flow correctly through the interface
When encountering a warning:
Dismissing warnings without investigation:
For you:
For others:
For debugging:
When you see a warning:
Every warning deserves understanding. Ignoring warnings = accepting unknown unknowns.