I thought it prudent to ensure that
IPv6 addresses are stored in the SQL database according to
RFC 5952 rather than a variable format 'text' string.
i.e. According to
https://datatracker.ietf.org/doc/html/rfc5952#section-1 (Hmmm????) a single IPv6 address can be 'text' string represented in many ways;
All of the following represent the same
IPv6 address:
- 2001:db8:0:0:1:0:0:1
- 2001:0db8:0:0:1:0:0:1
- 2001:db8::1:0:0:1
- 2001:db8::0:1:0:0:1
- 2001:0db8::1:0:0:1
- 2001:db8:0:0:1::1
- 2001:db8:0000:0:1::1
- 2001:0DB8:0:0:1::1
which makes checking if the
IP address was already assigned to a Road-Warrior 'device' difficult - hence despite your dismissive
'cosmetic' statement I perform the useful compression transformation if possible.
To determine which address should be assigned to the new Road-Warrior peer, by default
wireguard_manager
assumes that the 'server' Peer is assigned '.1', so assigns '.2' to the first 'device' Peer, then '.3' for the next and so on etc.
Originally,
wireguard_manager
simply issued a single
SQL Count(*)
request to return the number of 'device' Peers currently defined then simply added '1' to the count and used this for the new IP assignment.
However if 'device' Peers are deleted,
wireguard_manager
would potentially find the
IP already assigned or leave gaps, so I changed to always try and maintain a contiguous range starting @
'.2' with no gaps.
Clearly, providing custom 'server' Peer base addresses
> '.1' isn't currently catered for as shown in your 'bug' report.
Perhaps it is indeed prudent to start the search from the base address - in your case
'.101' for
IPv6, yet
'.1' for
IPv4 rather than
'.101'?
...but being lazy, suppose the
IPv6 base was '
FFFF', then it's tedious rolling over the correct subnet, but for
IPv6 '
.101' it may make sense to start from
'.102'
Possibly a candidate for
wireguard_manager
Beta
v4.16b2 ?