Re: Unlang, regex problem

Am Dienstag, den 31.07.2007, 10:48 -0400 schrieb Alan DeKok:

> >>> if ("%{User-Name}" !~ /foobar/) {
> >> ...
> >>> Mon Jul 30 14:15:07 2007 : Error: Unexpected trailing text at: !
> >>   Try doing a "cvs update".  It should be fixed now.
> > 
> > Hmm, that does not seem to work, i get the same error as before.
> 
>   I cut & paste that exact line, and it works for me.

Yes, it does. Sorry my fault.

Stephan Jaeger
--

-- 
Stephan Jaeger <stephan.jaeger <at> ewetel.de>
EWE TEL GmbH

Am Dienstag, den 31.07.2007, 10:48 -0400 schrieb Alan DeKok:

> >>> if ("%{User-Name}" !~ /foobar/) {
> >> ...
> >>> Mon Jul 30 14:15:07 2007 : Error: Unexpected trailing text at: !
> >>   Try doing a "cvs update".  It should be fixed now.
> > 
> > Hmm, that does not seem to work, i get the same error as before.
> 
>   I cut & paste that exact line, and it works for me.

Automatic report from sources (radiusd) between 31.07.2007 - 01.08.2007 GMT

CVS log entries from 31.07.2007 (Tue) 08:00:01 - 01.08.2007 (Wed) 08:00:00 GMT
=====================================================
Summary by authors
=====================================================
Author: aland
	File: radiusd/src/main/evaluate.c; Revisions: 1.23

=====================================================
Log entries
=====================================================
Description:
	Allow !~ to work, too
Modified files:
	File: radiusd/src/main/evaluate.c; Revision: 1.23;
	Date: 2007/07/31 13:30:10; Author: aland; Lines:  (+6 -6)
=====================================================
Summary of modified files
=====================================================
File: radiusd/src/main/evaluate.c
Revisions: 1.23
Authors: aland (+6 -6)
--

-- 
Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

freeradius and snmp on 64 bit architectures

Hello,

we have problems here with freeradius and snmp on 64 bit architectures. 
I have analyzed the code for snmp interaction and found some type problems.

I made a patch, which corrects the type problems and the snmp handshake 
is now working without any problem, but trying to get information from 
freeradius over snmp is not working, yet. But I do not find the problem. 
Maybe someone of you can help me with this.

I have attached the patch.

Thanks,
Thomas

--

-- 
Thomas Woerner
Software Engineer            Phone: +49-711-96437-310
Red Hat GmbH                 Fax  : +49-711-96437-111
Hauptstaetterstr. 58         Email: Thomas Woerner <twoerner <at> redhat.com>
D-70178 Stuttgart            Web  : http://www.redhat.de/

Hello,

we have problems here with freeradius and snmp on 64 bit architectures. 
I have analyzed the code for snmp interaction and found some type problems.

I made a patch, which corrects the type problems and the snmp handshake 

EAP-SIM Failed in Authentication

<div>

<div class="Section1">

<p class="MsoNormal"><span>Hi,<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>I have installed Free Radius Client/Server. I just would
like to use SIM Authentication. I have Modified the Conf file accordingly. Brought
up the Radius server successfully and when I try to bring the client with
command line arguments radeapclient &ndash;x localhost auth testing123
&lt;eapsim-in.txt where the eapsim-in.txt there under tests/eapsim03 directory.
Client sending the Message, but it is failed in the Server saying that no RAND attributes and cannot initiate sim
authentication. Where client is &nbsp;receiving the Access Reject Message.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Please guide me what format I have to use to initiate SIM
Authentication.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Here is the eapsim-in.txt file looks like:<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoPlainText"><span>User-Name = "eapsim"<p></p></span></p>

<p class="MsoPlainText"><span>NAS-IP-Address = marajade.sandelman.ottawa.on.ca<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Code = Response<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Type-Identity = "eapsim"<p></p></span></p>

<p class="MsoPlainText"><span>Message-Authenticator = 0<p></p></span></p>

<p class="MsoPlainText"><span>NAS-Port = 0<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Rand1 = 0xabcd1234abcd1234abcd1234abcd1234<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Rand2 = 0xbcd1234abcd1234abcd1234abcd1234a<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Rand3 = 0xcd1234abcd1234abcd1234abcd1234ab<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Sres1 = 0x1234abcd<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Sres2 = 0x234abcd1<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-Sres3 = 0x34abcd12<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-KC1 = 0x0011223344556677<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-KC2 = 0x1021324354657687<p></p></span></p>

<p class="MsoPlainText"><span>EAP-Sim-KC3 = 0x30415263748596a7<p></p></span></p>

<p class="MsoPlainText"><span><p>&nbsp;</p></span></p>

<p class="MsoPlainText"><span>Thanks &amp; Regards<p></p></span></p>

<p class="MsoPlainText"><span>Pramila<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

</div>

<table><tr><td bgcolor="#ffffff">============================================================================================================================<br><br>
Disclaimer:<br><br>
This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra.<br><br>
============================================================================================================================<br>
</td></tr></table>
</div>

updating avp lists with unlang and operators

Hi,

if i overwrite an avp in the preacct section like

update request {
	User-Name := "foobar"
}

and i have a "detail" instance in the acct section, the line that is
written to the detail log is 

"User-Name := foobar" 

instead of

"User-Name = foobar"

I guess the problem lies in my_pairmove() in evaluate.c (line 774). The
avp is copied from the src avp list to the dst avp list and the operator
is not touched. Maybe the operator in the dst list should default to "="
if the list is "reply" or "request"?

Another solution might be to alter rlm_detail to always use the "="
operator when printing out avp's.

What do you think?

Stephan Jaeger
--

-- 
Stephan Jaeger <stephan.jaeger <at> ewetel.de>
EWE TEL GmbH

Re: updating avp lists with unlang and operators

Stephan Jaeger wrote:
> and i have a "detail" instance in the acct section, the line that is
> written to the detail log is 
> 
> "User-Name := foobar" 

  Yeah, the operators aren't changed when the attributes are added to
the list.  This is in 1.1.x, too.

> I guess the problem lies in my_pairmove() in evaluate.c (line 774). The
> avp is copied from the src avp list to the dst avp list and the operator
> is not touched. Maybe the operator in the dst list should default to "="
> if the list is "reply" or "request"?

  Once the attribute has been moved to the destination list, the
operator should be updated to '='.

  Alan DeKok.

Re: updating avp lists with unlang and operators

Am Mittwoch, den 01.08.2007, 10:36 -0400 schrieb Alan DeKok:
> Stephan Jaeger wrote:
> > and i have a "detail" instance in the acct section, the line that is
> > written to the detail log is 
> > 
> > "User-Name := foobar" 
> 
>   Yeah, the operators aren't changed when the attributes are added to
> the list.  This is in 1.1.x, too.
> 
> > I guess the problem lies in my_pairmove() in evaluate.c (line 774). The
> > avp is copied from the src avp list to the dst avp list and the operator
> > is not touched. Maybe the operator in the dst list should default to "="
> > if the list is "reply" or "request"?
> 
>   Once the attribute has been moved to the destination list, the
> operator should be updated to '='.

It does work with the simple patch below, but what about control and
config lists? Shouldn't the old operator better be saved and re-set
afterwards?

--- evaluate.c.orig     2007-08-01 16:57:14.000000000 +0200
+++ evaluate.c  2007-08-01 16:58:09.000000000 +0200
 <at>  <at>  -776,6 +776,7  <at>  <at> 
                                       to_list[j]->name, i, j);
                                pairfree(&to_list[j]);
                                to_list[j] = from_list[i];
+                               to_list[j]->operator = T_OP_EQ;
                                from_list[i] = NULL;
                                edited[j] = TRUE;
                                break;

Stephan Jaeger
--

-- 
Stephan Jaeger <stephan.jaeger <at> ewetel.de>
EWE TEL GmbH

Re: updating avp lists with unlang and operators

Stephan Jaeger wrote:
> It does work with the simple patch below, but what about control and
> config lists? Shouldn't the old operator better be saved and re-set
> afterwards?

  Nope.  The operators exist *only* for putting attributes into the
list.  Once they're in a list, they have no effect on anything.

  Alan DeKok.

Automatic report from sources (radiusd) between 01.08.2007 - 02.08.2007 GMT

CVS log entries from 01.08.2007 (Wed) 08:00:00 - 02.08.2007 (Thu) 08:00:00 GMT
=====================================================
Summary by authors
=====================================================
Author: aland
	File: radiusd/src/main/evaluate.c; Revisions: 1.24

=====================================================
Log entries
=====================================================
Description:
	Mash operators so that the "detail" module (among others)
	gets '=' rather than ':=', etc.
Modified files:
	File: radiusd/src/main/evaluate.c; Revision: 1.24;
	Date: 2007/08/01 15:45:34; Author: aland; Lines:  (+11 -2)
=====================================================
Summary of modified files
=====================================================
File: radiusd/src/main/evaluate.c
Revisions: 1.24
Authors: aland (+11 -2)
--

-- 
Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

Error: FATAL Failed to initialize semaphore: Function not implemented

Hi,

Haven't built a new copy of the server for a while, as I was mostly 
debugging config stuff.
When I have built a new copy of the server from CVS i've always ran it 
in full foreground debugging mode which disables threads...
Which is why I don't know exactly when the commit that causes this was 
done ...

In Full debugging mode radiusd -X is fine

However running in daemon mode with debugging on I get:

Thu Aug  2 12:15:22 2007 : Debug: }
Thu Aug  2 12:15:22 2007 : Debug: Initializing the thread pool...
Thu Aug  2 12:15:22 2007 : Debug:  thread pool {
Thu Aug  2 12:15:22 2007 : Debug:       start_servers = 5
Thu Aug  2 12:15:22 2007 : Debug:       max_servers = 32
Thu Aug  2 12:15:22 2007 : Debug:       min_spare_servers = 3
Thu Aug  2 12:15:22 2007 : Debug:       max_spare_servers = 10
Thu Aug  2 12:15:22 2007 : Debug:       max_requests_per_server = 20
Thu Aug  2 12:15:22 2007 : Debug:       cleanup_delay = 5
Thu Aug  2 12:15:22 2007 : Debug:       max_queue_size = 65536
Thu Aug  2 12:15:22 2007 : Debug:  }
Thu Aug  2 12:15:22 2007 : Error: FATAL: Failed to initialize semaphore: 
Function not implemented

At which point GDB reports that the program exited normally, and so 
won't give me the backtrace of the stack.

*sigh*

According to my colleague (who has now gone off on holiday) :

"there's an issue to do with the way semaphores are implemented on OS X 
(basically, you can't use "unnamed" ones -- there's a very old thread 
about this in the freeradius-users list from 2004, with workarounds).  
I'm guessing that there's something wrong in the "configure" for OS X, 
meaning that it isn't using the right flavour of semaphore 
initialisation, OR that 2.0 has a regression to the previous problem 
that was fixed in 1.x"

Any chance someone could take a look at this ?

Be happy to provide any extra information required.

Thanks,
Arran