Re: Re: Data convertion and pre-defined variables for Dhcp site.
Because DHCP-SIP-Servers-DHCP-Option is an "octets" data type, so you have to feed it octets. e.g. &DHCP-SIP-Servers-DHCP-Option = 0x01c0a800fe That will work.
* Dhcpdump shows: *> >* OPTION: 120 ( 12) SIP Servers DHCP Option *3131302e31302e302e323534* *> Because you gave the attribute a text string. Which isn't hex, and it isn't an IP address.
But option 43 - DHCP-Vendor is octet also. However &DHCP-Vendor = "http://user:pass@%{listen:src_ipaddr}/pbx" works fine.
You just typed it there. You can add that as hex to the "update" statement. * I specified this option at isc-dhcp-server simply *>* *option sip-pbx-servers 1 192.168.0.254;* *> That's nice for them.
I added it &DHCP-SIP-Servers-DHCP-Option = "0x01c0a800fe" to update section. If you talked about it. But it would be easy that it is in human readable/clear format.
That's unfortunately more difficult to do in FreeRADIUS. Your best bet is to just use hex.
Is there string to hex convertion ? Look like %{hex:%{listen:str_ipaddr}} ? But what about your previous words:
I looked into a lot of docs but didn' t find any success resolution. So, how is the best way at unlang to: - convert ipaddr type to octet; - convert string to octet; - convert string to ipaddr ? You don't. The server should automatically do this.
As I understood, in case of 120 option conversion in particular is made automatically, is it ?
On Jun 9, 2019, at 1:48 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
But option 43 - DHCP-Vendor is octet also. However
&DHCP-Vendor = "http://user:pass@%{listen:src_ipaddr}/pbx"
works fine.
Define "works". Hint: it does the same thing as any other "octets" attribute. It takes the data you give, and dumps it into the attribute.
I added it &DHCP-SIP-Servers-DHCP-Option = "0x01c0a800fe" to update section. If you talked about it. But it would be easy that it is in human readable/clear format.
That's nice. Send a patch to fix it.
Is there string to hex convertion ? Look like
%{hex:%{listen:str_ipaddr}} ?
You don't want string to hex conversion. Think about it. You want to covert "192.168.0.254" into a 32-bit IP address, and then convert *that* to hex.
As I understood, in case of 120 option conversion in particular is made automatically, is it ?
I just said it wasn't made automatically. What part of that was unclear? Alan DeKok.
I just said it wasn't made automatically. What part of that was unclear?
At your first answer at the thread you wrote as answer to mine question: My Q:
* I looked into a lot of docs but didn' t find any success resolution. *>*> So, how is the best way at unlang to: *>*> - convert ipaddr type to octet; *>*? - convert string to octet; *>*> - convert string to ipaddr ? *Your A: You don't. The server should automatically do this.
And then I additionally asked you, if I understood you correctly or not:
* As I understood, in case of 120 option conversion in particular is **made automatically, is it *
And it is unclear for me - "...server should automatically yes ... " , "... wasn't made automatically ..." .
* But option 43 - DHCP-Vendor is octet also. However *>>* &DHCP-Vendor = "http://user:pass@%{listen:src_ipaddr}/pbx" *>>* works fine. *> Define "works". Hint: it does the same thing as any other "octets" attribute. It takes the data you give, and dumps it into the attribute.
But why is not such situation observed with DHCP-SIP-Servers-DHCP-Option ? It is octet as well. is it because of *DHCP-Vendor* is converted by Freeradius from string to octets as well as for DHCP-SIP-Servers-DHCP-Option ? Instead it is necessary to convert it from ipaddr type to octet for right handling of DHCP-SIP-Servers-DHCP-Option ?
On Jun 10, 2019, at 8:58 AM, CpServiceSPb <cpservicespb@gmail.com> wrote: ... So you're interested in arguing. But not so interested in learning.
But why is not such situation observed with DHCP-SIP-Servers-DHCP-Option ? It is octet as well. is it because of *DHCP-Vendor* is converted by Freeradius from string to octets as well as for DHCP-SIP-Servers-DHCP-Option ?
I already answered this question. If you pay attention to what happens, you'll see that "octets" attributes are all handled the same way.
Instead it is necessary to convert it from ipaddr type to octet for right handling of DHCP-SIP-Servers-DHCP-Option ?
Because my explanations are being ignored. Alan DeKok.
participants (2)
-
Alan DeKok -
CpServiceSPb