You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've looked a bit into how to best handle IPv6 requests here.
KEA (ISC replacement) DHCPv6 server is perfectly capable of issuing prefix delegations, and maintaining persistence and all of than, but it really, really sucks at dynamic interfaces. It's probably OK if you only have a handful of connections, but we had extreme problems just to get it configured in this way.
I then started on a DHCPv6 proxy (yes, there were existing ones, none of which has active maintenance), but then realised that getting PD delegations and all that into radius, whilst it can be done externally, it would overall be simpler if we can build the DHCPv6 proxy (which also knows how to handle radius IPv6 static assignments and delegations) straight into pppd.
I've started playing in https://github.com/jkroonza/dhcpv6-relay towards a standalone relay, but the complexities involved with not being part of the pppd daemon is tremendous once radius interactions becomes involved.
Using strace the pppd daemon sits mainly in this system call.
In this case fd 8 is a pipe whilst 10 and 12 are /dev/ppp. The write-end of the pipe is at fd=9 and I suspect this is to enable signals to interrupt the select.
This will likely result in work on top of #544 where the function to add/remove the default route will start accepting a specific prefix. This can happen before #544 but has the obvious rebasing caveats.
It looks like it's fairly trivial to add a file descriptor using add_fd to this set of descriptors, but I see no obvious way to associate an event handler with this file descriptor.
Would the following set of PRs (or commits in a single PR) be acceptable?
Adjust add_fd to take two additional arguments: a function pointer "void (callback)(int fd, void pvt)", and a "void* pvt"? Alterantively a new function in pppd/main.c add_fd_event_handler that has these semantics, and builds on top of add_fd but instead in handle_events calls the callback functions if these file descriptors has input available? (the latter is probably a cleaner approach, and won't break backwards compatibility with external modules)
Adjust the route add/remove code with support for a prefix.
In radius module add support Framed-Route (when it's encountered add a route to the interface, should remove too when link goes down).
In radius module add support for Framed-IPv6-Route (similar).
Make note of any of the following for DHCPv6 proxy module:
Delegated-IPv6-Prefix
DNS-Server-IPv6-Address
tag for IPv6 local assignment that will result in RAs being transmitted.
DHCPv6 module (if above tags are present use to serve request, else, proxy to upstream DHCPv6 server which may well be on the same host - there are some interesting caveats with that as I've found out during dhcpv6-proxy work).
The text was updated successfully, but these errors were encountered:
Hi,
I've looked a bit into how to best handle IPv6 requests here.
KEA (ISC replacement) DHCPv6 server is perfectly capable of issuing prefix delegations, and maintaining persistence and all of than, but it really, really sucks at dynamic interfaces. It's probably OK if you only have a handful of connections, but we had extreme problems just to get it configured in this way.
I then started on a DHCPv6 proxy (yes, there were existing ones, none of which has active maintenance), but then realised that getting PD delegations and all that into radius, whilst it can be done externally, it would overall be simpler if we can build the DHCPv6 proxy (which also knows how to handle radius IPv6 static assignments and delegations) straight into pppd.
I've started playing in https://github.com/jkroonza/dhcpv6-relay towards a standalone relay, but the complexities involved with not being part of the pppd daemon is tremendous once radius interactions becomes involved.
Using strace the pppd daemon sits mainly in this system call.
In this case fd 8 is a pipe whilst 10 and 12 are /dev/ppp. The write-end of the pipe is at fd=9 and I suspect this is to enable signals to interrupt the select.
This will likely result in work on top of #544 where the function to add/remove the default route will start accepting a specific prefix. This can happen before #544 but has the obvious rebasing caveats.
It looks like it's fairly trivial to add a file descriptor using add_fd to this set of descriptors, but I see no obvious way to associate an event handler with this file descriptor.
Would the following set of PRs (or commits in a single PR) be acceptable?
The text was updated successfully, but these errors were encountered: