Project

General

Profile

Actions

Bug #12436

open

Pppoe server config gui does not allow setting of chap authentication, and sets the network start address for allocation to 0

Added by And Ritchie over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
PPPoE Server
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.2
Affected Architecture:

Description

It is not possible to enable chap authentication via the gui. The service config file is generated with pap authentication only.
Also the client address allocation keeps being defaulted to 0 I.e if I want the address allocated to the first client to be 192.168.1.1 the gui will reset it to 192.168.1.0 upon save.

Actions #1

Updated by Viktor Gurov over 2 years ago

  • Affected Version set to 2.5.2

And Ritchie wrote:

It is not possible to enable chap authentication via the gui. The service config file is generated with pap authentication only.

Feature request #12438 created.

Also the client address allocation keeps being defaulted to 0 I.e if I want the address allocated to the first client to be 192.168.1.1 the gui will reset it to 192.168.1.0 upon save.

Changing this behavior can confuse users with existing installations.

Actions #2

Updated by And Ritchie over 2 years ago

Hi Victor,
This behaviour causes assigned client ip address to be 0 thus invalid.
E.g. 192.168.1.0 is not a valid client address. Which is what gets allocated to the connected client when it connects.

Actions #3

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Not a Bug

An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.

It's better for various automated parts of the configuration to have the client address range expressed as a subnet (e.g. for firewall rules/etc) but the clients are not actually all in the same "subnet" from a network interface perspective, they are each on their own interface using a single isolated address.

Since the other feature request was moved to its own separate issue I don't see anything actionable here.

Actions #4

Updated by Viktor Gurov over 2 years ago

  • Status changed from Not a Bug to New

Jim Pingle wrote in #note-3:

An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.

This is valid, but this is still incorrect behavior
fix: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/435
it doesn't break the existing installations as it doesn't modify remoteip which is stored in config.xml

Actions #5

Updated by Jim Pingle over 2 years ago

Viktor Gurov wrote in #note-4:

Jim Pingle wrote in #note-3:

An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.

This is valid, but this is still incorrect behavior

Why would it be incorrect? It is not technically a subnet. It is a range/pool of addresses. If you skip the first and last IP address in the configured range by treating in incorrectly as a subnet, it will have less available addresses to use for clients. For example if you set the mask to /30 right now you could fit four clients in that range, not two (or three if you only skip the first one).

If anything, language referring to it as a subnet should be corrected. It uses subnet-style configuration for historical reasons (mostly because it's easier to deal with in automatic firewall and NAT rules) but could just as easily use a hand-entered starting and ending address if the backend code was changed appropriately.

Actions

Also available in: Atom PDF