You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(26) |
Jun
(28) |
Jul
(27) |
Aug
(18) |
Sep
(25) |
Oct
(33) |
Nov
(64) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(48) |
Feb
(57) |
Mar
(44) |
Apr
(48) |
May
(59) |
Jun
(91) |
Jul
(35) |
Aug
(44) |
Sep
(43) |
Oct
(122) |
Nov
(13) |
Dec
(30) |
2004 |
Jan
(37) |
Feb
(32) |
Mar
(35) |
Apr
(49) |
May
(39) |
Jun
(72) |
Jul
(20) |
Aug
(25) |
Sep
(33) |
Oct
(13) |
Nov
(18) |
Dec
(4) |
2005 |
Jan
(4) |
Feb
(14) |
Mar
(26) |
Apr
(40) |
May
(31) |
Jun
(24) |
Jul
(20) |
Aug
(36) |
Sep
(50) |
Oct
(104) |
Nov
(126) |
Dec
(65) |
2006 |
Jan
(71) |
Feb
(42) |
Mar
(43) |
Apr
(93) |
May
(76) |
Jun
(48) |
Jul
(68) |
Aug
(58) |
Sep
(59) |
Oct
(108) |
Nov
(23) |
Dec
(36) |
2007 |
Jan
(41) |
Feb
(11) |
Mar
(40) |
Apr
(48) |
May
(61) |
Jun
(33) |
Jul
(19) |
Aug
(16) |
Sep
(34) |
Oct
(25) |
Nov
(38) |
Dec
(12) |
2008 |
Jan
(11) |
Feb
(29) |
Mar
(19) |
Apr
(18) |
May
(20) |
Jun
(22) |
Jul
(25) |
Aug
(24) |
Sep
(17) |
Oct
(33) |
Nov
(29) |
Dec
(38) |
2009 |
Jan
(26) |
Feb
(30) |
Mar
(44) |
Apr
(31) |
May
(60) |
Jun
(36) |
Jul
(22) |
Aug
(23) |
Sep
(24) |
Oct
(33) |
Nov
(34) |
Dec
(19) |
2010 |
Jan
(25) |
Feb
(21) |
Mar
(27) |
Apr
(6) |
May
(17) |
Jun
(23) |
Jul
(14) |
Aug
(33) |
Sep
(17) |
Oct
(10) |
Nov
(5) |
Dec
(19) |
2011 |
Jan
(9) |
Feb
(5) |
Mar
(51) |
Apr
(23) |
May
(16) |
Jun
(18) |
Jul
(82) |
Aug
(36) |
Sep
(19) |
Oct
(24) |
Nov
(22) |
Dec
(5) |
2012 |
Jan
(12) |
Feb
(3) |
Mar
(17) |
Apr
(5) |
May
|
Jun
(5) |
Jul
(7) |
Aug
(4) |
Sep
(7) |
Oct
(8) |
Nov
(20) |
Dec
(2) |
2013 |
Jan
(3) |
Feb
|
Mar
|
Apr
(11) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2014 |
Jan
(3) |
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Henrik A. <hen...@ce...> - 2015-08-20 08:07:40
|
Greetings rdesktop community. The rdesktop project is now moved to GitHub. This means that the hosted project services on SourceForge; www.rdesktop.org, svn repositories, issue trackers and mailing lists has found a new home and will be locked down. - A new static project page with updated information has been created. It is hosted by github.io, you find it here [1]. - The subversion repository has been migrated and is available at rdesktop organization page at GitHub [2]. - A BountySource rdesktop team [3] is created for donations and the ability to create bounties for issues. - New mailing lists are created and hosted by Google groups, read how to subscribe and use the new lists at the Community section on the new homepage [1]. [1] http://www.rdesktop.org [2] http://github.com/rdesktop Best Regards, rdesktop team |
From: Rostislav K. <r.k...@ww...> - 2015-07-27 13:00:03
|
Hello, When using rdesktop with smartcard logon there are two issues. 1. When connecting to existing session server does not end the transaction taken for smartcard logon, sending Server Announce instead. Protocol specification directs client to drop all existing device references, witch should include releasing all smartcard contexts, effectively releasing all current transactions. Current version however does not release these contexts, blocking smartcard from any use for the rest of the session. 2. When calling SCardGetStatus change caller may ask for special reader "\\\\?PnP?\\Notification" that will effectively signal when new smartcard reader will appear. Support for this feature appeared in pcsc-lite v1.6.0 quite a while ago. Current version of rdesktop filters out this special reader name for compatibility with older versions of pcsc-lite and Apple fork of it. As a result if a reader was not plugged in at application startup, windows logon screen will not detect insertion of a new reader during logon screen and options for smartcard logon won't appear. I have prepared a patch addressing these two issues. See attachment. Rostislav Kondratenko. |
From: Mican J. <Jin...@lg...> - 2015-04-09 14:13:37
|
Hello, I have problem regarding smartcard redirection REINER SCT cyberJack ecom plus. I tried connecting with older and latest version of rdesktop from Ubuntu 14.04 64bit and Debian Wheezy 32bit and from both applications recognized the card reader but were unable to correctly read the card. Host server I connect to is Windows 2008 R2 with cyberjack drivers installed and PCSC service shut down (even trying with on, but that is not even recommended). On Linux side, drivers working but on host side, it does seem that redirection is making something wrong, for some applications card is just not visible. Mainly for: Cyberjack function test application and for A-Trust applications. I have to mention that it works okay with Windows 8.1 connecting through Windows RDP to this server. Means there is either something wrong with rdesktop or with pcsc-lite (even that I have been told that it is not) or connection of these two applications struggle with this reader. For me, it is big problem, through web there are many similar questions and none of them has been solved. I would like to know where is this problem? What is the difference between how Windows RDP works and how rdesktop works... Why isn't it just USB redirection with smartcard that would be resolved at host or RDP connection? Thank you a lot. Henry |
From: Henrik A. <hen...@ce...> - 2014-06-23 06:41:19
|
On Wed, 18 Jun 2014 17:36:54 +0200 Lars Wenderoth <fr...@lw...> wrote: > > To fix this I created a patch, that counts 3 timeouts (All good things > come in threes. :-) ) and after this sets g_network_error to true. > This starts the reconnect loop where rdesktop tries to reestablish the > connection to the server. > Nice work, the send/recv implementation within rdesktop is just poorly designed and these issues should not exists at all. I will definitly take a look at your patch to improve in this area of rdesktop. Kind Regards Henrik Andersson (Cendio AB) |
From: Lars W. <fr...@lw...> - 2014-06-18 15:37:03
|
Hi, I observed the following: - rdesktop intentionally retries reading all the time - if trying to read times out (after 60 seconds) it just tries again. - if the network link went away long enough, it will try forever or at least very long without getting data - while retrying on a dead connection, the window doesn't react to any input from either side, but it keeps focus and grabs the keyboard, which is especially annoying in fullscreen.. This is what I want to change. - data is always considered sent, even if the connection is broken? I didn't have a closer look into this. To fix this I created a patch, that counts 3 timeouts (All good things come in threes. :-) ) and after this sets g_network_error to true. This starts the reconnect loop where rdesktop tries to reestablish the connection to the server. WARNING: This will also trigger, if there simply is no data to be received for 3 minutes, for example on an idle remote desktop without a clock or anything moving! It only triggers if we do NOT send any data. Moving the mouse is enough to make rdesktop think it did send data! To trigger we need at least 3 minutes of absolutely nothing happening, no received data and no data sent. So this patch is by no means perfect. But it seems to help in my case. Some bugs I found describing the symptoms: #347 and #345 I attached the patch to xwin.c. Hopefully this helps anyone out there.. Do you have any ideas for enhancements? Kind regards, Lars W. |
From: Igor G. <i.g...@gm...> - 2014-03-04 05:49:06
|
Hi, rdesktop is one project which correctly works with printer redirection, but I can't use it in production, because we don't have options for automatic redirection for printers. I know that Remmina can do this. Can we have chance for supporting this functional (for example we can have option '-r printers' for this functional)? -- -Igor Gnatenko |
From: Florent P. <fl...@pe...> - 2014-02-17 13:05:19
|
Hi Henrik, I have a workaround for the license problem. I printed sucesssively g_hostname, hi, ho and hash variables, in load_licence and save_licence, and saw that ho has never the same value and strangely, hi no more. From that results an incorrect hash between load and save calls. I don't know how this is possible, but to make it work, I made a memset on hi and ho before any use of these variables. I'm not sure it is a correct way to do, but for the moment, it works well. See the attached patch. On 07/02/2014 08:29, Henrik Andersson wrote: > On Tue, 04 Feb 2014 22:27:26 +0100 > Florent Peterschmitt <fl...@pe...> wrote: > >> Le 07/01/2014 09:03, Henrik Andersson a écrit : >>> On Mon, 06 Jan 2014 17:04:45 +0100 >>> Florent Peterschmitt <fl...@pe...> wrote: >>> Hi Florent, >>> >>>> What we see here is: >>>> >>>> 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file >>>> 2. fail to open it (it doesn't exists) >>>> 3. write to another file something (a new TSE license?) >>>> 4. close this new file >>>> >>>> If I re-launch rdesktop, then the same file (09...) is asked, not >>>> found and another _new_ CAL file is created. At this point, I have >>>> 2 CAL files. >>>> >>>> If I mv the latest CAL to the wanted CAL (09...), here is what I >>>> have: >>>> >>>> [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ >>>> [admin@S777TXDTTEST licenses]$ ls >>>> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >>>> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal >>>> [admin@S777TXDTTEST licenses]$ mv >>>> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >>>> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal >>>> [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace >>>> /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' >>>> Failed to negotiate protocol, retrying with plain RDP. >>>> * is this behaviour the expected one? >>> >>> No, this is not an expected behavior. >>> >>>> * does this behaviour can be responsible about an over consumption >>>> of TSE licenses? >>>> >>> >>> I'm unsure, i need to investigate the issue first before having a >>> straight up answer, I will take a look at this issue this week and >>> get back to you. >>> >>> >>> Kind Regards, >>> >>> Henrik Andersson (Cendio AB) >> >> Hello, >> >> Did you have the time for any investigation? Also, do you think >> xfreerdp can "solve" this problem? >> > > The license filename hash is generated from local hostname if not > specified by the -n <hostnam> argument to rdesktop. > > I can't reproduce your problem and I have not found any oddities in the > code regarding the license filename generation. Could you add a debug > print in load_license() and save_license() of g_hostname to verify that > its same while loading/storing ? > > > Kind Regards, > > Henrik Andersson > |
From: Florent P. <fl...@pe...> - 2014-02-13 21:03:40
|
On 07/02/2014 08:29, Henrik Andersson wrote: > The license filename hash is generated from local hostname if not > specified by the -n <hostnam> argument to rdesktop. > > I can't reproduce your problem and I have not found any oddities in the > code regarding the license filename generation. Could you add a debug > print in load_license() and save_license() of g_hostname to verify that > its same while loading/storing ? Thanks for the precisions. Next week I will be able to test what you asked. -- Florent Peterschmitt | Please: fl...@pe... | * Avoid HTML/RTF in E-mail. http://florent.peterschmitt.fr | * Send PDF for documents. Proudly powered by FLOSS | * Trim your quotations. Really. | Thank you :) |
From: Henrik A. <hen...@ce...> - 2014-02-07 07:29:20
|
On Tue, 04 Feb 2014 22:27:26 +0100 Florent Peterschmitt <fl...@pe...> wrote: > Le 07/01/2014 09:03, Henrik Andersson a écrit : > > On Mon, 06 Jan 2014 17:04:45 +0100 > > Florent Peterschmitt <fl...@pe...> wrote: > > Hi Florent, > > > >> What we see here is: > >> > >> 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file > >> 2. fail to open it (it doesn't exists) > >> 3. write to another file something (a new TSE license?) > >> 4. close this new file > >> > >> If I re-launch rdesktop, then the same file (09...) is asked, not > >> found and another _new_ CAL file is created. At this point, I have > >> 2 CAL files. > >> > >> If I mv the latest CAL to the wanted CAL (09...), here is what I > >> have: > >> > >> [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ > >> [admin@S777TXDTTEST licenses]$ ls > >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal > >> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal > >> [admin@S777TXDTTEST licenses]$ mv > >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal > >> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal > >> [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace > >> /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' > >> Failed to negotiate protocol, retrying with plain RDP. > >> * is this behaviour the expected one? > > > > No, this is not an expected behavior. > > > >> * does this behaviour can be responsible about an over consumption > >> of TSE licenses? > >> > > > > I'm unsure, i need to investigate the issue first before having a > > straight up answer, I will take a look at this issue this week and > > get back to you. > > > > > > Kind Regards, > > > > Henrik Andersson (Cendio AB) > > Hello, > > Did you have the time for any investigation? Also, do you think > xfreerdp can "solve" this problem? > The license filename hash is generated from local hostname if not specified by the -n <hostnam> argument to rdesktop. I can't reproduce your problem and I have not found any oddities in the code regarding the license filename generation. Could you add a debug print in load_license() and save_license() of g_hostname to verify that its same while loading/storing ? Kind Regards, Henrik Andersson |
From: Florent P. <fl...@pe...> - 2014-02-04 21:27:20
|
Le 07/01/2014 09:03, Henrik Andersson a écrit : > On Mon, 06 Jan 2014 17:04:45 +0100 > Florent Peterschmitt <fl...@pe...> wrote: > Hi Florent, > >> What we see here is: >> >> 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file >> 2. fail to open it (it doesn't exists) >> 3. write to another file something (a new TSE license?) >> 4. close this new file >> >> If I re-launch rdesktop, then the same file (09...) is asked, not >> found and another _new_ CAL file is created. At this point, I have 2 >> CAL files. >> >> If I mv the latest CAL to the wanted CAL (09...), here is what I have: >> >> [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ >> [admin@S777TXDTTEST licenses]$ ls >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal >> [admin@S777TXDTTEST licenses]$ mv >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal >> [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace >> /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' >> Failed to negotiate protocol, retrying with plain RDP. >> [admin@S777TXDTTEST licenses]$ cat rdesktop.trace |grep lice >> open("/home/admin/.local/share/rdesktop/licenses/09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal", >> O_RDONLY|O_LARGEFILE) = 5 >> [admin@S777TXDTTEST licenses]$ ls >> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal >> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal rdesktop.trace >> >> Then it's ok, the 09... CAL is reused (we see a read() and close() of >> this file) and no extra CAL created. >> >> >> >> Then, two questions : >> >> * is this behaviour the expected one? > > No, this is not an expected behavior. > >> * does this behaviour can be responsible about an over consumption of >> TSE licenses? >> > > I'm unsure, i need to investigate the issue first before having a > straight up answer, I will take a look at this issue this week and get > back to you. > > > Kind Regards, > > Henrik Andersson (Cendio AB) Hello, Did you have the time for any investigation? Also, do you think xfreerdp can "solve" this problem? Thanks -- Florent Peterschmitt | Please: fl...@pe... | * Avoid HTML/RTF in E-mail. http://florent.peterschmitt.fr | * Send PDF for documents. Proudly powered by Open Source | * Trim your quotations. Really. | Thank you :) |
From: Florent P. <fl...@pe...> - 2014-01-07 08:33:14
|
Le 07/01/2014 09:03, Henrik Andersson a écrit : > On Mon, 06 Jan 2014 17:04:45 +0100 > Florent Peterschmitt <fl...@pe...> wrote: > Hi Florent, > >> What we see here is: >> >> 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file >> 2. fail to open it (it doesn't exists) >> 3. write to another file something (a new TSE license?) >> 4. close this new file >> >> If I re-launch rdesktop, then the same file (09...) is asked, not >> found and another _new_ CAL file is created. At this point, I have 2 >> CAL files. >> >> If I mv the latest CAL to the wanted CAL (09...), here is what I have: >> >> [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ >> [admin@S777TXDTTEST licenses]$ ls >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal >> [admin@S777TXDTTEST licenses]$ mv >> 0f6f3932c9ecff5b253edabc71d017de013a1778.cal >> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal >> [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace >> /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' >> Failed to negotiate protocol, retrying with plain RDP. >> [admin@S777TXDTTEST licenses]$ cat rdesktop.trace |grep lice >> open("/home/admin/.local/share/rdesktop/licenses/09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal", >> O_RDONLY|O_LARGEFILE) = 5 >> [admin@S777TXDTTEST licenses]$ ls >> 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal >> ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal rdesktop.trace >> >> Then it's ok, the 09... CAL is reused (we see a read() and close() of >> this file) and no extra CAL created. >> >> >> >> Then, two questions : >> >> * is this behaviour the expected one? > > No, this is not an expected behavior. > >> * does this behaviour can be responsible about an over consumption of >> TSE licenses? >> > > I'm unsure, i need to investigate the issue first before having a > straight up answer, I will take a look at this issue this week and get > back to you. Thank you very much. Also, is the following problem[0] relevant with the latest version? I see the code hasn't changed. [0] https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/303082 > Kind Regards, > > Henrik Andersson (Cendio AB) -- Florent Peterschmitt | Please: fl...@pe... | * Avoid HTML/RTF in E-mail. http://florent.peterschmitt.fr | * Send PDF for documents. | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) |
From: Henrik A. <hen...@ce...> - 2014-01-07 08:03:12
|
On Mon, 06 Jan 2014 17:04:45 +0100 Florent Peterschmitt <fl...@pe...> wrote: Hi Florent, > What we see here is: > > 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file > 2. fail to open it (it doesn't exists) > 3. write to another file something (a new TSE license?) > 4. close this new file > > If I re-launch rdesktop, then the same file (09...) is asked, not > found and another _new_ CAL file is created. At this point, I have 2 > CAL files. > > If I mv the latest CAL to the wanted CAL (09...), here is what I have: > > [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ > [admin@S777TXDTTEST licenses]$ ls > 0f6f3932c9ecff5b253edabc71d017de013a1778.cal > ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal > [admin@S777TXDTTEST licenses]$ mv > 0f6f3932c9ecff5b253edabc71d017de013a1778.cal > 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal > [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace > /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' > Failed to negotiate protocol, retrying with plain RDP. > [admin@S777TXDTTEST licenses]$ cat rdesktop.trace |grep lice > open("/home/admin/.local/share/rdesktop/licenses/09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal", > O_RDONLY|O_LARGEFILE) = 5 > [admin@S777TXDTTEST licenses]$ ls > 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal > ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal rdesktop.trace > > Then it's ok, the 09... CAL is reused (we see a read() and close() of > this file) and no extra CAL created. > > > > Then, two questions : > > * is this behaviour the expected one? No, this is not an expected behavior. > * does this behaviour can be responsible about an over consumption of > TSE licenses? > I'm unsure, i need to investigate the issue first before having a straight up answer, I will take a look at this issue this week and get back to you. Kind Regards, Henrik Andersson (Cendio AB) |
From: Florent P. <fl...@pe...> - 2014-01-06 16:23:41
|
Hi, I'm currently using rdesktop 1.8.1 built from sources and I saw something strange: rdesktop is continuously asking for the same license file. Here is a strace output of a fresh start (no .cal in ~/.local/share/rdesktop/licenses/): [admin@S777TXDTTEST ~]$ strace -o rdesktop.trace /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' Failed to negotiate protocol, retrying with plain RDP. [admin@S777TXDTTEST ~]$ ls .^C [admin@S777TXDTTEST ~]$ cat rdesktop.trace |grep lice open("/home/admin/.local/share/rdesktop/licenses/09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/home/admin/.local/share/rdesktop/licenses", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/home/admin/.local/share/rdesktop/licenses/ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal.new", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 5 rename("/home/admin/.local/share/rdesktop/licenses/ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal.new", "/home/admin/.local/share/rdesktop/licenses/ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal") = 0 What we see here is: 1. search for 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal file 2. fail to open it (it doesn't exists) 3. write to another file something (a new TSE license?) 4. close this new file If I re-launch rdesktop, then the same file (09...) is asked, not found and another _new_ CAL file is created. At this point, I have 2 CAL files. If I mv the latest CAL to the wanted CAL (09...), here is what I have: [admin@S777TXDTTEST ~]$ cd .local/share/rdesktop/licenses/ [admin@S777TXDTTEST licenses]$ ls 0f6f3932c9ecff5b253edabc71d017de013a1778.cal ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal [admin@S777TXDTTEST licenses]$ mv 0f6f3932c9ecff5b253edabc71d017de013a1778.cal 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal [admin@S777TXDTTEST licenses]$ strace -o rdesktop.trace /usr/bin/rdesktop -x 0x86 -N -a 16 -P -z -k en-us S777SQ01 -u '' Failed to negotiate protocol, retrying with plain RDP. [admin@S777TXDTTEST licenses]$ cat rdesktop.trace |grep lice open("/home/admin/.local/share/rdesktop/licenses/09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal", O_RDONLY|O_LARGEFILE) = 5 [admin@S777TXDTTEST licenses]$ ls 09dcea473ad6f1ca5c33bc89df88aa42560b82b4.cal ebbcc14692930d5d3f71925f6cc657ec02fa02cf.cal rdesktop.trace Then it's ok, the 09... CAL is reused (we see a read() and close() of this file) and no extra CAL created. Then, two questions : * is this behaviour the expected one? * does this behaviour can be responsible about an over consumption of TSE licenses? Thanks. -- Florent Peterschmitt | Please: fl...@pe... | * Avoid HTML/RTF in E-mail. http://florent.peterschmitt.fr | * Send PDF for documents. | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) |
From: Henrik A. <hen...@ce...> - 2013-12-10 11:33:18
|
With commit r1777 i have now also successfully verified that the server redirection using 2012r2 is working correctly. Regards, Henrik Andersson > Hi rdesktop users, > > We have rewritten the server redirection code of rdesktop and testing > of the functionality has been performed aginst 2003 and 2008r2 > terminal server farms. It would be awesome if we could get some more > testings of this functionality from you to make it as stable as > possible for the next release. > > If you stumble upon a bug, report it on > https://sourceforge.net/p/rdesktop/feature-requests/146/ > |
From: 李毅为 <le...@gm...> - 2013-12-06 03:55:33
|
found a bug when redirect packet doesn't contian a LB_TARGET_NET_ADDRESS(PDU_REDIRECT_HAS_IP in rdp.c) flag and TargetNetAddress field. bug has been report to https://sourceforge.net/p/rdesktop/feature-requests/146/ 2013/12/5 Henrik Andersson <hen...@ce...> > Hi rdesktop users, > > We have rewritten the server redirection code of rdesktop and testing of > the functionality has been performed aginst 2003 and 2008r2 terminal > server farms. It would be awesome if we could get some more testings of > this functionality from you to make it as stable as possible for the next > release. > > If you stumble upon a bug, report it on > https://sourceforge.net/p/rdesktop/feature-requests/146/ > > > Kind Regards, > > Henrik Andersson > > > --- > Henrik Andersson > Cendio AB http://cendio.com > Teknikringen 8 http://twitter.com/ThinLinc > 583 30 Linköping http://facebook.com/ThinLinc > Phone: +46-13-214600 http://plus.google.com/112509906846170010689 > > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > rdesktop-devel mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel > |
From: Henrik A. <hen...@ce...> - 2013-12-04 20:40:44
|
Hi rdesktop users, We have rewritten the server redirection code of rdesktop and testing of the functionality has been performed aginst 2003 and 2008r2 terminal server farms. It would be awesome if we could get some more testings of this functionality from you to make it as stable as possible for the next release. If you stumble upon a bug, report it on https://sourceforge.net/p/rdesktop/feature-requests/146/ Kind Regards, Henrik Andersson --- Henrik Andersson Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköping http://facebook.com/ThinLinc Phone: +46-13-214600 http://plus.google.com/112509906846170010689 |
From: Henrik A. <hen...@ce...> - 2013-08-29 14:33:10
|
On 08/28/2013 09:13 PM, Xiaoqiang Chen wrote: > The change http://sourceforge.net/p/rdesktop/code/1724/ in v1.8.0 breaks > compilation on OSX 10.8 > > src here: > http://smartcardservices.macosforge.org/trac/browser/releases/Apple/OSX-10.8.0/SmartCardServices-55105/src/PCSC/reader.h > but reader.h is not distributed. > > Would you just please use 1<<16 | 0x100 or #ifndef #define it? > We can't just do that, its undefined and would break usage of other pcsc implementations, my suggestion is to push a bug upstream to fix the main issue with undefined macros. After some investigation that block of codes existence is not motivated, so I just removed it. -- --- Henrik Andersson Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköping http://facebook.com/ThinLinc Phone: +46-13-214600 http://plus.google.com/112509906846170010689 |
From: Xiaoqiang C. <fe...@gm...> - 2013-08-28 19:14:38
|
The change http://sourceforge.net/p/rdesktop/code/1724/ in v1.8.0 breaks compilation on OSX 10.8 src here: http://smartcardservices.macosforge.org/trac/browser/releases/Apple/OSX-10.8.0/SmartCardServices-55105/src/PCSC/reader.h but reader.h is not distributed. Would you just please use 1<<16 | 0x100 or #ifndef #define it? |
From: Xiaoqiang C. <fe...@gm...> - 2013-08-28 16:09:31
|
1. On network error, return NULL rather than an empty return statement to conform with function signature. 2. SSL_OP_NO_COMPRESSION is only available for openssl ver >=0.9.8 so check it before adding the flag. ref: https://github.com/mxcl/homebrew/pull/22116 diff --git a/tcp.c b/tcp.c index a541e45..943a655 100644 --- a/tcp.c +++ b/tcp.c @@ -193,7 +193,7 @@ tcp_recv(STREAM s, uint32 length) int rcvd = 0, ssl_err; if (g_network_error == True) - return; + return NULL; if (s == NULL) { @@ -318,7 +318,9 @@ tcp_tls_connect(void) } options = 0; +#ifdef SSL_OP_NO_COMPRESSION options |= SSL_OP_NO_COMPRESSION; +#endif options |= SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS; SSL_CTX_set_options(g_ssl_ctx, options); } |
From: Douglas E. E. <dee...@an...> - 2013-08-20 14:52:55
|
On 8/20/2013 3:55 AM, Henrik Andersson wrote: > Hi, Anand > > If your pinpad device is pcsc compat and supported by opensc this should not be a problem. It also depends on the smart card driver used on the server. For example the Microsoft PIV minidriver does not understand that the Omnikey 3821 has a pinpad. (Either when used directly on W7 or via rdesktop.) OpenSC PKCS11 when used from FireFox on Windows does use the pin pad reader. But when trying the 3821 via rdesktop-1.8.0 from Ubuntu to Windows 7, things may partially work, with or without the pin pad feature, with the either the Microsoft PIV mini driver or OpenSC. So try and configure rdesktop with the debugging options, and run pcscd -f -d -a to see what commands are being sent to the reader. On Windows the certutil -scinfo -v command is helpful, as are the OpenSC opensc-tool and pkcs11-tool > > Regards, > > Henrik Andersson > > On 06/21/2013 07:31 PM, Anand Renju wrote: >> Hi, >> >> Does the latest rdesktop support the redirection of PinPad smart card >> readers? >> >> Thanks, >> -Anand >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> >> >> _______________________________________________ >> rdesktop-devel mailing list >> rde...@li... >> https://lists.sourceforge.net/lists/listinfo/rdesktop-devel > > > -- > --- > Henrik Andersson > Cendio ABhttp://cendio.com > Teknikringen 8http://twitter.com/ThinLinc > 583 30 Linköpinghttp://facebook.com/ThinLinc > Phone: +46-13-214600http://plus.google.com/112509906846170010689 > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > > > _______________________________________________ > rdesktop-devel mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
From: Henrik A. <hen...@ce...> - 2013-08-20 08:55:41
|
Hi, Anand If your pinpad device is pcsc compat and supported by opensc this should not be a problem. Regards, Henrik Andersson On 06/21/2013 07:31 PM, Anand Renju wrote: > Hi, > > Does the latest rdesktop support the redirection of PinPad smart card > readers? > > Thanks, > -Anand > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > > _______________________________________________ > rdesktop-devel mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel -- --- Henrik Andersson Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköping http://facebook.com/ThinLinc Phone: +46-13-214600 http://plus.google.com/112509906846170010689 |
From: Anand R. <ana...@gm...> - 2013-07-16 17:22:15
|
Hi, smart card redirection is not working with Windows 8 and Windows 2012 TS. Not getting any debug messages even scard debug enabled. What change happened at server side? Does anyone have faced the issue? Any resolution? Thanks, -Renju |
From: Pierre O. <os...@ce...> - 2013-07-08 07:10:20
|
On Fri, 5 Jul 2013 15:43:15 +0530 Anand Renju <ana...@gm...> wrote: > Application i'm trying to test is rdesktop. I meant the application that you are running on the Windows server. > If i want to learn smart card > redirection code, what should be best way. How can i see at the server side > what PDU response has sent from client after processing each PCSC call? You'll have to add some more code to rdesktop to print the PDU in that case. Fair warning though; the rdesktop smart card code is horrible. It is in desperate need of a complete rewrite. It is very messy and is not properly written according to the protocol specification. Rgds -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköping http://facebook.com/ThinLinc Phone: +46-13-214600 http://plus.google.com/112509906846170010689 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? |
From: Anand R. <ana...@gm...> - 2013-07-05 10:13:23
|
Application i'm trying to test is rdesktop. If i want to learn smart card redirection code, what should be best way. How can i see at the server side what PDU response has sent from client after processing each PCSC call? Thanks, -Renju On Fri, Jul 5, 2013 at 1:37 PM, Pierre Ossman <os...@ce...> wrote: > On Fri, 5 Jul 2013 11:18:46 +0530 > Anand Renju <ana...@gm...> wrote: > > > Hi, > > > > Is there any way to see what data rdesktop sends to to server for smart > > card login. We have debugging option at the rdesktop side to see what all > > pscs calls are made, same way how we can see this on Terminal server. > > > > I'm afraid I'm not aware of any such debugging facilities. Perhaps in > the application you are trying to test? > > The debug output you get from rdesktop should basically be what gets > sent over the wire though. Is there something specific that doesn't > seem to add up? > > Rgds > -- > Pierre Ossman Software Development > Cendio AB http://cendio.com > Teknikringen 8 http://twitter.com/ThinLinc > 583 30 Linköping http://facebook.com/ThinLinc > Phone: +46-13-214600 http://plus.google.com/112509906846170010689 > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > |
From: Pierre O. <os...@ce...> - 2013-07-05 08:08:00
|
On Fri, 21 Jun 2013 23:01:55 +0530 Anand Renju <ana...@gm...> wrote: > Hi, > > Does the latest rdesktop support the redirection of PinPad smart card > readers? > I think it should, yes. There was some magic that we had to add to get the capability handshake working between Windows and pcsc-lite, but I think everything should be in place for this to work. Rgds -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköping http://facebook.com/ThinLinc Phone: +46-13-214600 http://plus.google.com/112509906846170010689 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? |