Set mark during address selection

[flu0r1ne]

This PR addresses and resolves issue #485 concerning address selection when using a packet mark. While I believe there's a more "correct" way to fix this issue, the solution would require extensive changes that I currently do not have the time to implement.

This PR tackles the most prevalent variant of the issue. I plan to create a new issue outlining my ideal approach for resolving this problem. This will serve as a guide for anyone who might revisit the issue in the future, offering one potential solution and outlining the limitations of the current patch.

Changes

• The patch makes minimal alterations, fixing the issue by setting the mark during the address selection process.
• This fix only addresses the problem in mtr and not in mtr-packet.
• The patch also adds support for parsing packet marks as hex values, which is a common way to refer to packet marks.

Testing

I tested these patches on Linux 6.1 and FreeBSD 13.2. As the changes only involve packet marking, they do not affect non-Linux operating systems. Therefore, FreeBSD can be used as a stand-in for NetBSD or Solaris.

Testing Steps:

Linux

I have a routing table with a unique default gateway corresponding to mark 2088138254. I tested the application both with and without the mark to ensure that it traced the correct path. mtr performed as expected in both scenarios.

make clean
make
MTR_PACKET="./mtr-packet" sudo -E ./mtr -t 1.1.1.1 # traces the expected route
MTR_PACKET="./mtr-packet" sudo -E ./mtr -t -M 2088138254 1.1.1.1 # traces the expected route
MTR_PACKET="./mtr-packet" sudo -E ./mtr -t -M 0x7c76760e 1.1.1.1 # traces the expected route

BSD

As FreeBSD does not support routing marks, my test on this OS involved merely compiling mtr and confirming that it could trace a route, thereby triggering the address selection logic.

make clean
make
MTR_PACKET="./mtr-packet" sudo -E ./mtr 1.1.1.1 # traces the expected route
MTR_PACKET="./mtr-packet" sudo -E ./mtr -I vtnet0 1.1.1.1 # traces the expected route

[flu0r1ne]

See #491 for the limitations of this fix.

[yvs2014]

Therefore, FreeBSD can be used as a stand-in for NetBSD or Solaris.

Mmm... nope. NetBSD is a bit more friendly to port on, Solaris is a tottally different beast.

[rewolff]

Right. SunOS was based on BSD. But Solaris is sysV based.

[flu0r1ne]

Mmm... nope. NetBSD is a bit more friendly to port on, Solaris is a tottally different beast.

Thank you, I will keep that in mind. In this case, the code I added only affects address selection when SO_MARK is defined. This is Linux-specific so in this regard all non-Linux operating systems should function the same way. Effectively, I was testing that none of the SO_MARK code bled into the regular control flow.

[flu0r1ne]

I recognize that this does not validate that the other socket operations work. My assumption is that these worked on HEAD prior to this commit.