possible ascend data filter problems
i have been working with our upstream dialup provider for a week now and he has come to the conclusion that freeradius is passing the data as ascii rather than abinary. his tests used flat files while we use mysql. the filters we define are listed below from our support tech's email: -- That too did not change anything. In my testing If I just plug the ascend attributes in my users file as follows Ascend-data-filter += "ip in forward tcp est", Ascend-data-filter += "ip in forward dstip 64.113.34.0/24", Ascend-data-filter += "ip in drop tcp srcport = 80", Ascend-data-filter += "ip in drop tcp dstport = 25", Ascend-data-filter += "ip in forward", And they translate to Abinary fine. This leads me to believe it has to do with the way sql is passing it to you radius server. --- any idea why /how this is happening? it is affecting our entire structure since we are also a proxy for approx 25 realms and it affects many of their setups too. these need to be passed to our upstream as abinary. -- Chuck - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: possible ascend data filter problems
Chuck <[EMAIL PROTECTED]> wrote: > i have been working with our upstream dialup provider for a week now and he > has come to the conclusion that freeradius is passing the data as ascii > rather than abinary. Hmm... that shouldn't happen. Which version are you running? > That too did not change anything. In my testing If I just plug the ascend > attributes in my users file as follows >Ascend-data-filter += "ip in forward tcp est", >Ascend-data-filter += "ip in forward dstip 64.113.34.0/24", >Ascend-data-filter += "ip in drop tcp srcport = 80", >Ascend-data-filter += "ip in drop tcp dstport = 25", >Ascend-data-filter += "ip in forward", > And they translate to Abinary fine. This leads me to believe it has to > do with the way sql is passing it to you radius server. I don't see why. The "users" file reads ascii strings, and they get packed as abinary stuff. The SQL module should be doing exactly the same thing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: possible ascend data filter problems
On Tuesday 10 January 2006 06:41 pm, Alan DeKok wrote: version 1.0.5 i may have messed up with the configuration or dictionaries i don't know. the ascend dictionary is in the directory and is included in the main dictionary. this is a gentoo installation made by simply doing "emerge freeradius" so i don't know what the compile options were. i suppose i can find out if that is necessary. > Chuck <[EMAIL PROTECTED]> wrote: > > i have been working with our upstream dialup provider for a week now and he > > has come to the conclusion that freeradius is passing the data as ascii > > rather than abinary. > > Hmm... that shouldn't happen. Which version are you running? > > > That too did not change anything. In my testing If I just plug the ascend > > attributes in my users file as follows > >Ascend-data-filter += "ip in forward tcp est", > >Ascend-data-filter += "ip in forward dstip 64.113.34.0/24", > >Ascend-data-filter += "ip in drop tcp srcport = 80", > >Ascend-data-filter += "ip in drop tcp dstport = 25", > >Ascend-data-filter += "ip in forward", > > And they translate to Abinary fine. This leads me to believe it has to > > do with the way sql is passing it to you radius server. > > I don't see why. The "users" file reads ascii strings, and they get > packed as abinary stuff. The SQL module should be doing exactly the > same thing. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Chuck "Windows?? You mean the thirty-two bit extension and graphical shell to a sixteen-bit patch to an eight-bit operating system originally coded for a four-bit microprocessor which was written by a two-bit company that can't stand one bit of competition? Oh, that..." -- Lee Clarke - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: possible ascend data filter problems
On Tuesday 10 January 2006 06:41 pm, Alan DeKok wrote:
> Chuck <[EMAIL PROTECTED]> wrote:
> > i have been working with our upstream dialup provider for a week now and
he
> > has come to the conclusion that freeradius is passing the data as ascii
> > rather than abinary.
>
> Hmm... that shouldn't happen. Which version are you running?
>
below is the entire ebuild configuration/compile section in case there is
something there that may cause this... it is freeradius 1.0.5.. also below
this is the output from radtest if that might help too. the more i look into
this the more i am confused as to why it isn't working properly.
-
src_compile() {
# export WANT_AUTOCONF=2.1
autoconf
local myconf=" \
`use_with snmp` \
`use_with frascend ascend-binary` \
`use_with frxp experimental-modules` \
`use_with udpfromto` \
`use_with edirectory edir` "
if useq frnothreads; then
myconf="${myconf} --without-threads"
fi
#fix bug #77613
if has_version app-crypt/heimdal; then
myconf="${myconf} --enable-heimdal-krb5"
fi
# kill modules we don't use
if ! use ssl; then
einfo "removing rlm_eap_tls and rlm_x99_token (no use ssl)"
rm -rf src/modules/rlm_eap/types/rlm_eap_tls
src/modules/rlm_x99_token
fi
if ! use ldap; then
einfo "removing rlm_ldap (no use ldap)"
rm -rf src/modules/rlm_ldap
fi
if ! use kerberos; then
einfo "removing rlm_krb5 (no use kerberos)"
rm -rf src/modules/rlm_krb5
fi
if ! use pam; then
einfo "removing rlm_pam (no use pam)"
rm -rf src/modules/rlm_pam
fi
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--mandir=/usr/share/man \
--with-large-files --disable-ltdl-install --disable-static \
${myconf} || die
make || die
}
---
plus, when i use radtest i get this result which seems to me to be either
hex-text or the proper 'binary' they are looking for? i am not familiar with
this...
rad_recv: Access-Accept packet from host 64.113.39.5:1645, id=88, length=291
Service-Type = Framed-User
Framed-Protocol = PPP
Port-Limit = 1
Ascend-Data-Filter = 0x697020696e20666f72776172642074637020657374
Ascend-Data-Filter =
0x697020696e20666f72776172642064737469702036342e3131332e33342e302f32342030
Ascend-Data-Filter =
0x697020696e20666f72776172642064737469702036342e3131332e33362e34362f32382030
Ascend-Data-Filter =
0x697020696e2064726f702074637020647374706f7274203d203235
Ascend-Data-Filter = 0x697020696e20666f72776172642030
Ascend-Data-Filter =
0x697020696e2064726f702074637020737263706f7374203d203830
Ascend-Client-Assign-DNS = DNS-Assign-Yes
Ascend-Client-Primary-DNS = 64.113.32.54
Ascend-Client-Secondary-DNS = 64.113.39.4
Session-Timeout = 14400
> > That too did not change anything. In my testing If I just plug the ascend
> > attributes in my users file as follows
> >Ascend-data-filter += "ip in forward tcp est",
> >Ascend-data-filter += "ip in forward dstip 64.113.34.0/24",
> >Ascend-data-filter += "ip in drop tcp srcport = 80",
> >Ascend-data-filter += "ip in drop tcp dstport = 25",
> >Ascend-data-filter += "ip in forward",
> > And they translate to Abinary fine. This leads me to believe it has to
> > do with the way sql is passing it to you radius server.
>
> I don't see why. The "users" file reads ascii strings, and they get
> packed as abinary stuff. The SQL module should be doing exactly the
> same thing.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
>
--
Chuck
"Windows?? You mean the thirty-two bit extension and graphical shell to a
sixteen-bit patch to an eight-bit operating system originally coded for a
four-bit microprocessor which was written by a two-bit company that can't
stand one bit of competition? Oh, that..." -- Lee Clarke
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: possible ascend data filter problems
Chuck <[EMAIL PROTECTED]> wrote: > plus, when i use radtest i get this result which seems to me to be either > hex-text or the proper 'binary' they are looking for? i am not familiar with > this... > > rad_recv: Access-Accept packet from host 64.113.39.5:1645, id=88, length=291 > Service-Type = Framed-User > Framed-Protocol = PPP > Port-Limit = 1 > Ascend-Data-Filter = 0x697020696e20666f72776172642074637020657374 The "hex" is just the ASCII string value you entered on the server. Since it's not the proper abinary format, radclient can't decode it, and instead prints it as hex. The reason for this is that the server isn't encoding the attribute as abinary before sending it. That has to be fixed. This is almost always a dictionary problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: possible ascend data filter problems
On Wednesday 11 January 2006 11:31 am, Alan DeKok wrote: > Chuck <[EMAIL PROTECTED]> wrote: > > plus, when i use radtest i get this result which seems to me to be either > > hex-text or the proper 'binary' they are looking for? i am not familiar with > > this... > > > > rad_recv: Access-Accept packet from host 64.113.39.5:1645, id=88, length=291 > > Service-Type = Framed-User > > Framed-Protocol = PPP > > Port-Limit = 1 > > Ascend-Data-Filter = 0x697020696e20666f72776172642074637020657374 > > The "hex" is just the ASCII string value you entered on the server. > Since it's not the proper abinary format, radclient can't decode it, > and instead prints it as hex. > > The reason for this is that the server isn't encoding the attribute > as abinary before sending it. That has to be fixed. > > This is almost always a dictionary problem. > hmm ok wish i was more an expert at this... will have a closer look at the dictionary sections and try to figure it out. thanks > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Chuck "Windows?? You mean the thirty-two bit extension and graphical shell to a sixteen-bit patch to an eight-bit operating system originally coded for a four-bit microprocessor which was written by a two-bit company that can't stand one bit of competition? Oh, that..." -- Lee Clarke - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
