On Sat, Mar 01, 2014 at 12:56:16PM +0900, YASUOKA Masahiko wrote:
> Currently the parser needs to surrounding the address-mask with double
> quote like below:
>
> pool-address "10.128.120.0/24"
Ah, yes; that's much better:
2014-03-01 15:59:13:INFO: ipcp=IPCP pool dyn_pool=[10.128.120.0/24]
pool=[10.128.120.0/24]
> And also we can use
>
> pool-address 10.128.120.0:255.255.255.0
Yes, that also results in a nice clean pool:
2014-03-01 16:00:43:INFO: ipcp=IPCP pool dyn_pool=[10.128.120.0/24]
pool=[10.128.120.0/24]
I think I'll stick with the quotes for now, I like CIDR notation :).
I had actually looked a bit at the parser before I posted, nothing
initially jumped out, but now that you point it out as the culprit I see
that the pool address is defined as a STRING, and based on:
#define allowed_in_string(x) \
(isalnum(x) || (ispunct(x) && x != '(' && x != ')' && \
x != '{' && x != '}' && x != '<' && x != '>' && \
x != '!' && x != '=' && x != '/' && x != '#' && \
x != ','))
The literal / is not allowed in a string, whereas the literal : is.
>From a quick look, I don't really see anything that would be broken by
allowing a / in a non-quoted string? Would just removing the explicit
restriction on the / in the above define fix it, or I am missing
something more subtle?
> As the default, npppd doesn't use the local tunnel endpoint address
> and broadcast addresses in class network (10.0.0.0 and 10.255.255.255)
> for the clients. Do you worry about 10.128.120.0 or 10.128.120.255 in
> this case?
Technically, given they are all /32 point to point links, you could actually
make the local side .0 and use everything up to .255 (I think), but
I'm ok with losing two addresses to conform to usual /24 semantics and
less risk of confusion at some point. Setting the pppx IP to 10.128.120.1
and the ipcp pool to 10.128.120.0/24 will work perfectly for me, thanks
much for the help.
