Serge Caron

Hello Eugene, Thank you for your outstanding support. I am using mpd in the context of the latest release of pfsense (release 2.6.0). I was able to get a log but the key to solving my issue was your comment to "set link no protocomp" before connecting to the ISP. The latest pfSene Documentation (2022.03.31, 5 days ago!) has this on page 405: "Protocol Field Compression (ProtoComp) This option saves one byte per frame for most frames. To disable this, check Disable Protocol Compression." This is far...

Hello Eugene, I'm not sure the exact log level that was inplace on Friday. I will make sure the configuration matches your request on Tuesday. In the meantime, the actual log level shows 74 "reconnection attempt" in attachment MPD_2022.04.01.11H59.txt. Attachment MPD_2022.04.01.12H31.txt shows 8 PAP NAK over the first 18 login attempts before receiving an ACK, all of this activity using the same credentials. The only variable that I can see in the packet capture is the session identifier. Note: attachments...

Hello Eugene, I'm not sure the exact log level taht was inplace on Friday. I will make sure the configuration matches your request on Tuesday. In the meantime, the actual log level shows 74 "reconnection attempt" in attachment MPD_2022.04.01.11H59.txt. Attachment MPD_2022.04.01.12H31.txt shows 8 PAP NAK over the first 18 login attempts before receiving an ACK, all of this activity using the same credentials. The only variable that I can see in the packet capture is the session identifier. Note: attachments...

A well known North American ISP appears to send "Authenticate-NAK" to sessions using 1 as its identifier. In the following WireShark capture, the original equipment is using the value 2 as its session Identifier and receives "Authenticate-Ack" (oviously, the credentials are valid ;-). The equipment spoofing the MAC address of the original equipment uses the value 1 by default as its session Identifier and receives "Authenticate-NAK", even if every other byte of the packet is the same as in the original...

OOPS! Senior moment. When the spoofing mpd client issues the "PPP LCP Configuration Request" using session identifier 1, the server returns a "PPP LCP Configuration Reject". mpd then issues a second "PPP LCP Configuration Request" using session identifier 2 and receives a "PPP LCP Configuration Ack". This session number is not remembered when authentication is attempted. Regards,

A well known North American ISP appears to send "Authenticate-NAK" to sessions using 1 as its identifier. In the following WireShark capture, the original equipment is using the value 2 as its session Identifier and receives "Authenticate-Ack" (oviously, the credentials are valid ;-). The equipment spoofing the MAC address of the original equipment uses the value 1 by default as its session Identifier and receives "Authenticate-NAK", even if every other byte of the packet is the same as in the original...

Missing port package following update of ASSP VM