Add support for -k/--fwmark option

[tomangert]

No description provided.

[coveralls]

Coverage increased (+0.09%) to 81.777% when pulling f562f49 on tomangert:develop into 296de3d on schweikert:develop.

[tomangert]

Satisfies Issue #158

I am not configured to test ipv6 but it should work.

[tomangert]

For --fwmark to work either run as root or set the cap_net_raw and cap_net_admin file capabilities. setuid does not work for fwmark.

sudo chmod u-s /usr/bin/fping
sudo setcap "cap_net_admin,cap_net_raw+ep" /usr/bin/fping

README.md ci/prepare-linux.sh and contrib/fping.spec can be updated to reflect this. I will add those changes.

[hmh]

This is rather strange, setuid to unrestricted root should be very much equivalent to all capabilities.

Maybe you hit the same problem I had with SO_BINDTODEVICE ? Refer to #199 and PR #200 for a hint of the issue.

[tomangert]

Yes it looks like the same thing. At least for fwmark there is cap_net_admin as a workaround. For SO_BINDTODEVICE I don't see a capability that will work documented anywhere.

[tomangert]

Checked the kernel source. cap_net_raw should work for SO_BINDTODEVICE, but I didn't try it.

[hmh]

Yes, cap_net_raw works for SO_BINDTODEVICE.

However, without my extra changes to unbreak setuid (or some other change to the same effect), fping remains half-broken on a very large set of machines that cannot operate with capabilites. E.g. every small OpenWrt router. They simply don't use filesystems (and in some case, deployment and update methods) that can deal with extended attributes. That means effectively no capabilities support, even if it is Linux, and even if capabilities are enabled in the kernel.

I am not against merging this PR as-is. I will just adjust mine to also fix -k/--fwmark if it lands first, because I believe fping should work in setuid mode just as well as it does with capabilities.

[hmh]

So, to be very clear, I have no objections against the merge of this PR in its current state.

[tomangert]

@hmh I just looked at #200 and agree it will be trivial to merge with this one (or vice versa).

I checked a diskless embedded linux implementation and see what you mean about not having xattr support.

So either order of merge is fine by me also. I will update the request if needed.

[darless]

What's holding up this from being merged? #200 shows a status of merged. Status checks show that all checks have passed.

[deepkv]

I'd also like to see this merged, and I see it has some conflicts. If no one else has time, I'd be happy to reimplement this on top of the current HEAD.

[deepkv]

Done: #289