Alan, I will dig into both mods-available/dhcp and dictionary.dhcp. Yes I am running in debug mode. The information you gave me is very useful. Once I have access to my lab again, I'll get back into this. If I hit another road block, I'll make sure to include the data dump. Thank you for your time. -- Best regards, Mark mailto:mark@mailmt.com Myakka Communications www.Myakka.com ------ Wednesday, January 15, 2025, 1:50:20 PM, you wrote: AD> On Jan 15, 2025, at 1:04 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Current PPPoE setup is as follows. Clients connect to a Mikroik PPPoE server, Mikrotik Authenticates via a FreeRadius Server, FreeRadius Authenticates via a MS SQL Server. We also do accounting. Client uses a Username/Password we supply them.
AD> OK.
We are implementing some new hardware which would work better if we used DHCP instead of PPPoE. We have setup a Mikrotik DHCP server. Mikrotik allows us to authenticate DHCP request via Radius. We have this piece of the system setup. Currently the way mikrotik authenticates is using device MAC address as username and a blank password. This is a problem being the mac address is supplied by the clients device. We want this to be invisible to the client. If the client decides to change their equipment, we don't want it to generate a service call.
AD> That makes sense.
We decided to use DHCP Option 82 on our new equipment. Setting it up this way we can have the Option 82 data programmed into our equipment which will stay static. For example we can pass something like XX01-username-password-port-etc. We have the setup and I can confirm the freeradius server is receiving the correct data in the Agent-Circuit-Id.
AD> Hmm... there's no need to send a password. That data is sent over the network in the clear. So any password you send is publicly visible. Which means that the password isn't that useful.
What I would like to do as early as possible in the freeradius process is to extract the username and password from Agent-Circuit-Id and update both username and password with that data.
AD> Sure. If the server is receiving this in RADIUS packets, see mods-available/dhcp. It can decode Option 82 into fields. AD> Or, if this is native DHCP, just update dictionary.dhcp. Define whatever sub-options you need there, and the server will automatically decode them.
Current issues
Agent-Circuit-Id is transferred as hex. Doesn't look like uLang has a hex to string conversion routine. That causes issues with the RegEx extract. That is why I was thinking about dropping into perl
AD> Are you sure it's ASCII HEX? Or just binary data that is printed as hex? AD> The dictionary.dhcp file has DHCP-Agent-Circuit-Id defined as "octets", which is binary data. This means it's printed as hex in debug mode, but the actual data is binary. AD> You shouldn't need to use Perl. Just use the native functionality in FreeRADIUS. It will handle this. AD> And this shouldn't need to be said, but do you have debug putout as suggested in *all* of the documentation? It would help a lot to be able to see the actual contents of Agent-Circuit-Id. AD> i.e. you're asking me for help with a problem, but aren't actually saying what the problem is. AD> You don't need to convert hex to string. You don't need to use Perl. You don't need to use regexes on binary data. Those are all possible solutions, and likely the wrong solution. AD> You should explain what, exactly, is in the Agent-Circuit-ID option. The best way to do this is to post the debug output. This is describing the problem, which then allows us to suggest a good solution. AD> Alan DeKok.