pfSense

May be the same as #4378

Note: both Local IP, subnet and Gateway fields are lost for all but the first of multiple interfaces selected for MLPPP.
That data is stored in comma-separated lists 'localip' 'subnet' and 'gateway'. interfaces_ppps_edit.php correctly handles unpacking and packing the lists to/from the fields in the UI.
interfaces.php is too stupid. It only displays the first in the list, even having code that explicitly picks out the first (0) element of the arrays:
htmlspecialchars($pconfig['pptp_local'][0])
$pconfig['pptp_subnet'][0]
htmlspecialchars($pconfig['pptp_remote'][0])

And then that is saved back without putting back any of the other entries that might have been there.

The Local IP, Subnet and Gateway details already managed by interfaces_ppps_edit.

What to do in interfaces.php?
a) Remove the fields from interfaces.php and just make sure to preserve the existing data without ever showing it to the user, or;
b) Display all the data from the 3 fields as text information to the user and point them to where it can be edited in interfaces_ppps_edit.php. Make sure to preserve it correctly on save, or;
c) Enhance interfaces.php to display multiple sets of the fields, accept and validate any changes and correctly build the comma-separated lists again, or;
d) Just display the first set of fields as they are now, allowing the user to edit that as they wish. If there are multiple MLPPP defined underneath then indicate that somewhere (so the user can realise that), point them to where the proper editing of that is done, and underneath in the code make sure to preserve that data on save, or;
e) Something else.

What is the preferred option?

Actually I looked at the code more and option (d) was easy to do and seemed reasonable. Pull request https://github.com/pfsense/pfsense/pull/1780 should fix this bug.

Yes, you are right. There is a bit of duck-and-weave in the changes there to save the previous strings, get the $POST values and merge them back in at the start of the previous data... And it really needs testing that there are no unforeseen side-effects when other PP* variants are selected for an interface. Not good to just dump in as the last commit for a formal release.

I see you have admitted to the idea that 2.2.5 might happen - good. We can keep fixing the steady flow of things that seem to pop up. I keep thinking I have got near the end of things I care about, then I press a button somewhere and think "Oh, that should validate better or..."
For things that change/fix/enhance the GUI modules (/usr/local/www) it will be a challenge to make sure that everything that is done is also migrated into effectively the same change/fix/enhancement in the bootstrap code.

Is there a workaround for this? I just upgraded from 2.1.3 > 2.2.4 and now have use of only one of my MLPPP members.

Apply the patch to usr/local/www/interfaces.php from https://github.com/pfsense/pfsense/pull/1780
My commit https://github.com/phil-davis/pfsense/commit/da71a2c06e9b955cf482ebfa8081616dc94a7efe
Note: After the pull request is merged, that temporary branch and patch will be deleted. But at that time you will be able to get the change from the pfSense RELENG_2_2 branch anyway.

I have never been able to edit my posts in Redmine. Sorry - that post above has the pull request and commit for master.
The ones for RELENG_2_2 to go on top of 2.2.4 are:
https://github.com/pfsense/pfsense/pull/1781
https://github.com/phil-davis/pfsense/commit/6db49ea6cb14ac80adb9f1b800780117fa3dd78a

New pull request for RELENG_2_2 that should be bug free :) https://github.com/pfsense/pfsense/pull/1928

The master version was committed as https://github.com/pfsense/pfsense/commit/66fd7b47679187ddcfaf5852a55b2af15394f341
and there is a followup dumb bug fix for that https://github.com/pfsense/pfsense/pull/1929

Sorry for all the noise. My brain is going to mush with recent merging and manual integration.