I noticed this when experimenting with VPN settings, is this a bug ?
If I add my L2TP interface both inside “Interfaces > interface lists” (e.g under LAN) and I also specify “LAN” under interface list of “PPP > profiles”, then it disconnects me when I try to connect.
I under if this is a bug. Basically it refuses the connection when PPP profile tries to add the L2TP interface to a list that already has the interface.
Otherwise it works OK if I only specify interface list in one of the above locations.
// v6.45.9
As these two mechanisms (creating a static name for the virtual interface created for a particular L2TP user vs. adding the dynamically created interface name to a pre-defined interface list) basically substitute each other, I can imagine that the system designers haven’t anticipated that a user might want to deploy both of them simultaneously, so they haven’t implemented an exceptional mechanism allowing the ppp stack to ignore the error in which creation of an interface list member row which already exists normally results. So I definitely don’t see this behaviour as a bug, it’s a misconfiguration to me.
Can you elaborate on the application scenario which requires to use both those mechanisms at the same time?
Hi Sindy
I would not say that my scenario required using both mechanisms, but rather not being fully familiar with it, you might assume you need to specify the interface list in both locations.
Under PPP profiles I understand that it means “the interface list to add this interface to (once connected)”, but for a beginner, it might look like “interface list to use to establish the connection”.
In my opinion I still think it would be a good practice to check for duplicates instead of silently fail to accept connections.
It would be nice to have tips, maybe from community or from the official wiki when rolling over the options in winbox, or an “?” next to options with available tips.
But then that’s the case I had in mind - no developer has enough imagination to anticipate all the creative misunderstandings users can come up with. And even if they had, it would require much more code to resolve these cases than the code doing the actual useful job.
Yes, one can assume that since in few cases, interface lists are used to control local outgoing traffic (ip neighbor discovery), they could be used also to control long-distance traffic. It’s only if you have more experience with other setups of Mikrotik that you realize that source interface for outgoing packets is always chosen depending on the result of routing, not vice versa. And you are right that googling for mikrotik ppp profile “interface-list” doesn’t take you to the right wiki page, simply because the interface-list property of the /ppp profile has not been added to the respective page. More than that, I could not find in the changelog since when the interface-list is available as a property of a /ppp profile.
I’d be less demanding, and it would be enough for me if the official wiki was updated every time when a new feature makes it to the stable version. A link from Winbox/WebGUI to the right point in the manual from each item could be nice, but bear in mind that the smaller devices already bump into flash memory limits, so for WebGUI this would likely be complicated.
Thank you for posting something like this