pfSense

I'm unable to reproduce this.

There was an issue with pppcfg where '-pppoesvc' (i.e. to remove a service name) didn't work, but that has different symptoms and the PHP code never used that feature either.

I've gone through the ioctl code and don't see any obvious way we can end up inserting garbage for the service name.

Steve ran this dtrace probe:

dtrace -n 'fbt::pppoe_ioctl:entry { printf("%s", curpsinfo->pr_psargs); }'

/sbin/pppcfg pppoe0 pppoedev lagg1 pppoesvc 0x31|1 authname Test authkey 12345

That points in the direction of the PHP code, rather than pppcfg or if_pppoe.ko

He also thinks it only happens when MIM is enabled.

I've also added changes in https://gitlab.netgate.com/pfSense/factory/-/commit/ff0af2d353b8db1eba524371556d51d028f03dae to handle this on the PHP side. This issue stems from some goofy handling of boolean values in the XML parsing, and some really dodgy mixing of string and bool values in the service and hostuniq attributes in the PHP form handling code.

When either of these attributes is empty on the PHP form submission, rather than just ignoring them the form submission code instead sets these properties to 'true' in the PPP configuration array. This forces empty tags for these attributes to be written to the XML. HOWEVER - when the config.cache is subsequently generated from that XML, these empty tags are interpreted as empty strings rather than boolean values.

When the configuration provider is Nexus, the process is different - on form submission the array representing the configured PPP is serialized directly and sent to Nexus, and those properties retain their boolean values. In this situation, the PHP code still expects them to be strings when the mpd config is generated and we get unexpected values because of the binhexed and stringified boolean values.

It's a subtle bug and only presents itself when the PPP configuration is changed while Nexus is running.