On another note, given this request has come up previously. I assume RMerlin said it's not possible to better integrate such a feature? (I.E. easily utilised via the user interface) I know sometimes there are restrictions not that I understand them. Do you know if anyone asked?
Merlin does NOT use the marking of packets, but instead, adds/removes ip rules. These rules do NOT include the ability to specify ports, but are limited to a few items, such as source and/or destination IP (there are others like TOS, but those are not relevant at the moment).
If he decided to switch to marking packets instead of ip rules, he would then face the problem of making sure other parts of the system don't interfere w/ his marks, and vice versa. And that's because there's only *one* location for marking packets that's shared by all processes. All participants in marking are expected to *cooperate* and NOT mess up the marks of others. And you do that by a) reserving certain bits within the marked field for yourself that are known NOT to be used by others, and b) masking your marks so you don't mess up the marks of others.
Problem is, trying to enforce those two things is next to impossible when you have a mix of OEM and third-party developers who are all working independently. Even those offering their own scripts, or suggestions for how YOU can implement policy based routing based on marking, are taking a risk that some unknown process doesn't mess w/ your marks, or vice versa. That's why this is a bit trickier to implement than some would have you believe. To the extent you can guarantee that only YOU are marking packets, you can do so w/ 100% confidence. But that almost never happens. I've seen everything from unexpected usage of certain bits in the marked field, to processes that clobber anything they find, as if they expect exclusive use.
This is one of the reasons I've been reluctant to mark packets over the years w/ third-party firmware. Sometimes you can get away with it if you know the firmware quite well, or else notify users that certain other features that also depend on marking can not be used at the same time. But if you just assume otherwise, you can quickly make a mess of things. And even when you do know the firmware quite well, things can suddenly change w/o your knowledge.
Now granted, someone like Merlin is far better positioned to avoid such issues than you or I. But even so. It's far easier for him to simply add/remove IP rules at will, since rarely is anything else in the system doing the same. Conflicts are very rare.
FWIW, FreshTomato implements policy based routing using marked packets. But they do NOT offer anything more than source/destination IP (well, they do offer domain name support, but that's implemented w/ a combination of ipset and marking, and that's another story). So in that case, it would presumably be easier to add support for ports by just changing the GUI. But in all the years they've supported policy based routing, they've never indicated any such desire or intent. But at least the firmware developers are in FULL control of what is using marks. OTOH, Merlin has to integrate his changes w/ both open and closed sources from ASUS, giving him significantly less control.
All that said, I'm sure another big part of the decision is just the desire to keep things simple. Every developer, esp. any dealing w/ a GUI, has to draw a fine line between functionality and ease of use, and avoid the problem of making the GUI so complex, it becomes intimidating to end-users, and difficult to support. The number of users that need port support is probably just not at a threshold to overcome those concerns (which probably explains why FreshTomato still doesn't support it either).
JMTC
