Phil Mayers wrote:
The source code, and my testing, suggests this just triggers a lookup of the IP against the home servers, so you still need to define one home server per NAS. If you don't you get:
WARNING: Unknown destination <nas>:3799 for CoA request. Do CoA Fail handler here
That's been fixed in git, at least.
Also this entails using an access-request to trigger a CoA, rather than sending a CoA and proxying it onwards to a NAS. Not terrible but not ideal either.
The server *can* receive coa packets and proxy them. See sites-available/coa.
It's possible I'm doing something wrong, as I found the examples for this seriously hard to follow - the use of a home server/pool as an indirection mechanism really confused me, and it was not obvious what 127.0.0.1 was being used for. Dummy value/placeholder? Magic value?
Place-holder. When the server is sending a CoA packet to a NAS, it's just proxying the packet. That's the same whether it's receiving a CoA and proxying it, to receiving an Access-Request and originating a CoA packet. The reason for the home server/pool is because the CoA packets aren't magic. They're just proxied, like any other packets. So... they use the same proxy mechanism. Which includes pools and home servers. I supposed we *could* add a "coa" sub-section to the "client" section. It would contain CoA port, secret, and anything else required for CoA. The server could then just send a CoA packet to a particular client, instead of using the home server mechanism. The only downside to doing that is that CoA proxying now becomes magic. And the generic proxy code becomes polluted with CoA magic. Alan DeKok.