Bug #16167
closed
if_pppoe sends invalid service name
0%
Description
In some circumstances the if_pppoe module sends an unexpected and seemingly random service name:
00:14:46.435384 PPPoE PADI [Service-Name "0x31|1"] [Host-Uniq ".NYU"]
[25.03-BETA][root@m470-3.stevew.lan]/root: pppcfg pppoe0
dev: lagg1 svc: 0x31|1 state: PADI sent
sid: 0x0 PADI retries: 7 PADR retries: 0
sppp: phase establish authproto auto authname "Test" peerproto auto
That value is not in the pfSense config, it's empty.
That happens after resaving an existing PPPoE interface with no service name set.
Updated by Kristof Provost about 2 months ago
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.
Updated by Kristof Provost about 2 months ago
Steve ran this dtrace probe:
dtrace -n 'fbt::pppoe_ioctl:entry { printf("%s", curpsinfo->pr_psargs); }'and found (among other output)
/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.
Updated by Steve Wheeler about 2 months ago
- Status changed from New to Feedback
This should be fixed in the next pfnet-conbtroller build.
Updated by Steve Wheeler about 2 months ago
- Status changed from Feedback to Resolved
Looks fixed as of controller build 678d0c35afc910be4f6ce7420259a8321a7f1ec3
Updated by Reid Linnemann about 2 months ago
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.
Updated by Jim Pingle about 1 month ago
- Release Notes changed from Default to Force Exclusion