Same with ./libfreerdp-core/license.c:void 
license_send_new_license_request_packet(rdpLicense* license)

For:

        license->client_user_name->data = 
(uint8*)license->rdp->settings->username;
        license->client_user_name->length = 
strlen((char*)license->rdp->settings->username) + 1;


If the user doesn't do a -u to set the user name at the command line.


Which gets me to the point where I can attempt to log in (assuming I do 
--no-nla with a :  else if (nego->cookie != NULL) {  hack below to skip the 
strlen(nego->cookie) issue.  And promptly dumps me to a useless keymapping.

- Ben

On Sep 7, 2011, at 12:25 PM, Ben Lindstrom wrote:

> 
> 
> Running any of the following:
> 
> xfreerdp --no-nla ..
> xfreerdp --no-nla --no-tls ..
> 
> All result in a segv crash in the current GIT tree on SLES11 SP1.  The 
> backtrace in gdb shows it happening in a strlen() in 
> nego_send_negotiation_request().
> 
> The issue seems to be that in libfreerdp-core/nego.c:void 
> nego_send_negotiation_request(rdpNego* nego)
> 
> There is:
> 
>       if (nego->routing_token != NULL)
>       {
>               stream_write(s, nego->routing_token->data, 
> nego->routing_token->length);
>               length += nego->routing_token->length;
>       }
>       else
>       {
>               int cookie_length =  strlen(nego->cookie);
> 
> 
> And nego->cookie is NULL or not set correctly causing strlen() to die a 
> horrible death.
> 
> I'm sure of this because if I do something stupid like:
> 
>       int cookie_length = 0;
> 
> it does the wrong thing, but no longer crashes.  So something isn't setting 
> it right.
> 
> Any ideas / comments?
> 
> - Ben
> 


------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Reply via email to