From: Mrs. B. <mrs...@ni...> - 2003-07-05 03:59:06
Attachments:
use_tcp_connect.c
|
If it really is blocking in connect() (around line 155 in tcp.c/CVS), then you can do either: 1. put an alarm(N); right above that line, where N is the number of seconds you want to wait. 2. lower the TCP connection timeout limit on your operating system However, the magic words you are using are "connect to an ip" -- I think your resolver library doesn't translate gethostbyname()'s for IP addresses, but instead actually asks the DNS cache for it, _AND_ you're not using a DNS cache that performs that translation (like djbdns does) RDESKTOP-DEVEL: Your tcp_connect routine is not friendly to systems with a broken resolver library (sadly, most aren't). I've taken the liberty of rewriting those functions. Since I am lazy, I've just coded them in a separate file. Please see attached code fragment, integrate into tcp.c (fairly easily) and apply to CVS. On Fri, 2003-07-04 at 04:50, Justin Fretwell wrote: > I need to reduce the timeout when someone tries to connect to an ip with no > terminal services running. how might i do this? |
From: Justin F. <ju...@ak...> - 2003-07-07 10:02:22
|
It works by dns name. On Monday 07 July 2003 09:51, Justin Fretwell wrote: > i amended the tcp.c file as per instructions and recompiled: > > bingo2:~/thin_client/rdesktop/rdesktop$ ./rdesktop -5 180.0.0.118 > Trying 0.0.0.0...ERROR: 0.0.0.0: Connection refused > > To make sure i got this right i basically removed the old "tcp_connect()" > and added yours and put the other function "finish_tcp_connect()" directly > after it. i also added the function prototype at the top of the file: > > static BOOL finish_tcp_connect(char *, struct sockaddr_in *, char **); > > compiled it, no errors and ran it. > > On Saturday 05 July 2003 05:13, Mrs. Brisby wrote: > > If it really is blocking in connect() (around line 155 in tcp.c/CVS), > > then you can do either: > > 1. put an alarm(N); right above that line, where N is the number of > > seconds you want to wait. > > 2. lower the TCP connection timeout limit on your operating system > > > > > > However, the magic words you are using are "connect to an ip" -- I think > > your resolver library doesn't translate gethostbyname()'s for IP > > addresses, but instead actually asks the DNS cache for it, _AND_ you're > > not using a DNS cache that performs that translation (like djbdns does) > > > > RDESKTOP-DEVEL: > > > > Your tcp_connect routine is not friendly to systems with a broken > > resolver library (sadly, most aren't). > > > > I've taken the liberty of rewriting those functions. Since I am lazy, > > I've just coded them in a separate file. Please see attached code > > fragment, integrate into tcp.c (fairly easily) and apply to CVS. > > > > On Fri, 2003-07-04 at 04:50, Justin Fretwell wrote: > > > I need to reduce the timeout when someone tries to connect to an ip > > > with no terminal services running. how might i do this? > > ************************************************************************ > DISCLAIMER: > ----------- > The information in this E-mail and in any attachments is confidential > and is intended solely for the original addressee. It should not be > used by anyone who is not an original intended recipient. Access, > copying or use of information in it by anyone else is unauthorised and > may be illegal. If you are not the intended recipient please contact > the sender by replying to them and then delete the message. > > Akhter Computers Ltd cannot accept liability for statements made which > are clearly the sender's own and are not made on behalf of Akhter > Computers Ltd. No statement shall be construed as giving > industrial/confidential advice within/outside the UK. > ************************************************************************ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > rdesktop-users mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-users |
From: Mrs. B. <mrs...@ni...> - 2003-07-08 00:58:41
Attachments:
use_tcp_connect.c
|
How about "bad dns names"? Do they block in the same way? If you truss/strace the run, can you identify which syscall generates the block? Also note, if you're passing through a NAT/firewall that blocks ICMP messages, you're probably shooting yourself in the foot. I'm also not sure I understand properly: ./rdesktop 192.168.1.5 server bpp 8 client bpp 16 depth 16 Trying 192.168.1.5...connected! -- works fine ./rdesktop 192.168.1.3 server bpp 8 client bpp 16 depth 16 Trying 192.168.1.3...ERROR: 192.168.1.3: Connection refused -- works as expected ./rdesktop 192.168.1.55 server bpp 8 client bpp 16 depth 16 Trying 192.168.1.55... -- blocks for a rather long time- as expected; 55 doesn't have any machine listening there. ./rdesktop 192.168.1.91 server bpp 8 client bpp 16 depth 16 Trying 192.168.1.55... -- blocks for a rather long time- as expected; 91 blocks ICMP traffic and tries hard to be invisible. Which one of these do you think is going on? My patch isn't designed to solve _your problem_ unless your problem is the DNS server drops questions (or worse still- tries to answer questions) like 192.168.1.91- djbdns's dnscache will response immediately with the same answer. some stub resolvers don't deal well with this and that causes problems. My patch reorders things and allows us to try multiple addresses associated with the same name (something I use here a lot) Btw, I made a mistake. Get rid of those memset(&s, 0, sizeof(s)) lines and put one above the if( inet_aton... line. Updated version attached- I had accidentally copied the wrong source file out into my home directory. On Mon, 2003-07-07 at 06:00, Justin Fretwell wrote: > It works by dns name. > > On Monday 07 July 2003 09:51, Justin Fretwell wrote: > > i amended the tcp.c file as per instructions and recompiled: > > > > bingo2:~/thin_client/rdesktop/rdesktop$ ./rdesktop -5 180.0.0.118 > > Trying 0.0.0.0...ERROR: 0.0.0.0: Connection refused > > > > To make sure i got this right i basically removed the old "tcp_connect()" > > and added yours and put the other function "finish_tcp_connect()" directly > > after it. i also added the function prototype at the top of the file: > > > > static BOOL finish_tcp_connect(char *, struct sockaddr_in *, char **); > > > > compiled it, no errors and ran it. > > > > On Saturday 05 July 2003 05:13, Mrs. Brisby wrote: > > > If it really is blocking in connect() (around line 155 in tcp.c/CVS), > > > then you can do either: > > > 1. put an alarm(N); right above that line, where N is the number of > > > seconds you want to wait. > > > 2. lower the TCP connection timeout limit on your operating system > > > > > > > > > However, the magic words you are using are "connect to an ip" -- I think > > > your resolver library doesn't translate gethostbyname()'s for IP > > > addresses, but instead actually asks the DNS cache for it, _AND_ you're > > > not using a DNS cache that performs that translation (like djbdns does) > > > > > > RDESKTOP-DEVEL: > > > > > > Your tcp_connect routine is not friendly to systems with a broken > > > resolver library (sadly, most aren't). > > > > > > I've taken the liberty of rewriting those functions. Since I am lazy, > > > I've just coded them in a separate file. Please see attached code > > > fragment, integrate into tcp.c (fairly easily) and apply to CVS. > > > > > > On Fri, 2003-07-04 at 04:50, Justin Fretwell wrote: > > > > I need to reduce the timeout when someone tries to connect to an ip > > > > with no terminal services running. how might i do this? > > > > ************************************************************************ > > DISCLAIMER: > > ----------- > > The information in this E-mail and in any attachments is confidential > > and is intended solely for the original addressee. It should not be > > used by anyone who is not an original intended recipient. Access, > > copying or use of information in it by anyone else is unauthorised and > > may be illegal. If you are not the intended recipient please contact > > the sender by replying to them and then delete the message. > > > > Akhter Computers Ltd cannot accept liability for statements made which > > are clearly the sender's own and are not made on behalf of Akhter > > Computers Ltd. No statement shall be construed as giving > > industrial/confidential advice within/outside the UK. > > ************************************************************************ > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > > _______________________________________________ > > rdesktop-users mailing list > > rde...@li... > > https://lists.sourceforge.net/lists/listinfo/rdesktop-users > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > rdesktop-users mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-users |
From: Justin F. <ju...@ak...> - 2003-07-08 10:06:55
|
On Tuesday 08 July 2003 02:13, Mrs. Brisby wrote: > How about "bad dns names"? Do they block in the same way? If you > truss/strace the run, can you identify which syscall generates the > block? they dont block in the same way they just say: could not resolve address, which is what i would expect to happen. > Also note, if you're passing through a NAT/firewall that blocks ICMP > messages, you're probably shooting yourself in the foot. I'm not. > I'm also not sure I understand properly: > > ./rdesktop 192.168.1.5 > server bpp 8 client bpp 16 depth 16 > Trying 192.168.1.5...connected! > -- works fine this is working > ./rdesktop 192.168.1.3 > server bpp 8 client bpp 16 depth 16 > Trying 192.168.1.3...ERROR: 192.168.1.3: Connection refused > -- works as expected > > ./rdesktop 192.168.1.55 > server bpp 8 client bpp 16 depth 16 > Trying 192.168.1.55... > -- blocks for a rather long time- as expected; 55 doesn't have any > machine listening there. this is the problem i am having. It times out eventually but its takes far far too long. the users that will be using my clients are not having access to command line so i need a fairly quick timeout. > ./rdesktop 192.168.1.91 > server bpp 8 client bpp 16 depth 16 > Trying 192.168.1.55... > -- blocks for a rather long time- as expected; 91 blocks ICMP traffic > and tries hard to be invisible. > eventually times out as expected. > > Which one of these do you think is going on? My patch isn't designed to > solve _your problem_ unless your problem is the DNS server drops > questions (or worse still- tries to answer questions) like 192.168.1.91- > djbdns's dnscache will response immediately with the same answer. some > stub resolvers don't deal well with this and that causes problems. My > patch reorders things and allows us to try multiple addresses associated > with the same name (something I use here a lot) all alias addresses fail if they are incorrect. but works fine with a working address. > Btw, I made a mistake. Get rid of those memset(&s, 0, sizeof(s)) lines > and put one above the if( inet_aton... line. Updated version attached- I > had accidentally copied the wrong source file out into my home > directory. that fixed it. ************************************************************************ DISCLAIMER: ----------- The information in this E-mail and in any attachments is confidential and is intended solely for the original addressee. It should not be used by anyone who is not an original intended recipient. Access, copying or use of information in it by anyone else is unauthorised and may be illegal. If you are not the intended recipient please contact the sender by replying to them and then delete the message. Akhter Computers Ltd cannot accept liability for statements made which are clearly the sender's own and are not made on behalf of Akhter Computers Ltd. No statement shall be construed as giving industrial/confidential advice within/outside the UK. ************************************************************************ |
From: Mrs. B. <mrs...@ni...> - 2003-07-10 01:40:20
|
On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > ./rdesktop 192.168.1.55 > > server bpp 8 client bpp 16 depth 16 > > Trying 192.168.1.55... > > -- blocks for a rather long time- as expected; 55 doesn't have any > > machine listening there. > > this is the problem i am having. It times out eventually but its takes far > far too long. the users that will be using my clients are not having access > to command line so i need a fairly quick timeout. This is TCP related. There really isn't a lot you can do besides: 1. lower the timeout in your operating system (dangerous!) 2. use an alarm clock. You _might_ try using a shell script to sanitize the rdesktop IP address. Something that looks like this: ---- #!/bin/sh ip=$1 args="" shift while test "X$1" != "X" do args="$args $ip" ip="$1" shift done if ping -w1 -c1 $ip >/dev/null 2>&1 then rdesktop $args $ip else echo "Ping failed" fi |
From: Justin F. <ju...@ak...> - 2003-07-10 10:30:27
|
the ping idea is a possiblity (although i dont have the -w option. what does it do?), but if i have 20 people all connecting at the same time, roughly, if i set -c10 (on my linux distribution this creates 10 pings) will that cause a denial of service attack on the server? On Thursday 10 July 2003 02:55, Mrs. Brisby wrote: > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > ./rdesktop 192.168.1.55 > > > server bpp 8 client bpp 16 depth 16 > > > Trying 192.168.1.55... > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > machine listening there. > > > > this is the problem i am having. It times out eventually but its takes > > far far too long. the users that will be using my clients are not having > > access to command line so i need a fairly quick timeout. > > This is TCP related. There really isn't a lot you can do besides: > 1. lower the timeout in your operating system (dangerous!) > 2. use an alarm clock. > > > > You _might_ try using a shell script to sanitize the rdesktop IP > address. Something that looks like this: > > ---- > #!/bin/sh > ip=$1 > args="" > shift > while test "X$1" != "X" > do > args="$args $ip" > ip="$1" > shift > done > > if ping -w1 -c1 $ip >/dev/null 2>&1 > then > rdesktop $args $ip > else > echo "Ping failed" > fi ************************************************************************ DISCLAIMER: ----------- The information in this E-mail and in any attachments is confidential and is intended solely for the original addressee. It should not be used by anyone who is not an original intended recipient. Access, copying or use of information in it by anyone else is unauthorised and may be illegal. If you are not the intended recipient please contact the sender by replying to them and then delete the message. Akhter Computers Ltd cannot accept liability for statements made which are clearly the sender's own and are not made on behalf of Akhter Computers Ltd. No statement shall be construed as giving industrial/confidential advice within/outside the UK. ************************************************************************ |
From: Bob B. <bb...@us...> - 2003-07-10 14:26:03
|
On Thu, Jul 10, 2003 at 11:29:20AM +0100, Justin Fretwell <ju...@ak...> wrote: > the ping idea is a possiblity (although i dont have the -w option. what does > it do?), but if i have 20 people all connecting at the same time, roughly, if > i set -c10 (on my linux distribution this creates 10 pings) will that cause a > denial of service attack on the server? I very much doubt that any reasonal server capable of hosting remote desktop sessions will be overwhelmed by that many pings. Yes, a DoS is possible, but you'd need a lot more traffic than that. -- Bob Bell <bb...@us...> |
From: Bob B. <bb...@us...> - 2003-07-10 14:33:13
|
On Wed, Jul 09, 2003 at 09:55:40PM -0400, Mrs. Brisby <mrs...@ni...> wrote: > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > ./rdesktop 192.168.1.55 > > > server bpp 8 client bpp 16 depth 16 > > > Trying 192.168.1.55... > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > machine listening there. > > > > this is the problem i am having. It times out eventually but its takes far > > far too long. the users that will be using my clients are not having access > > to command line so i need a fairly quick timeout. > > This is TCP related. There really isn't a lot you can do besides: > 1. lower the timeout in your operating system (dangerous!) > 2. use an alarm clock. You can also usually set a socket option. On Tru64 UNIX this is TCP_KEEPINIT. On HP-UX it's TCP_CONN_ABORT_THRESHOLD. I don't know what it is on Linux. Of course, this involves an OS-specific modification to the rdesktop source to pull this off. -- Bob Bell <bb...@us...> |
From: Justin F. <ju...@ak...> - 2003-07-10 15:35:30
|
I presume: "tcp_retries1 Defines how many times an answer to a TCP connection request is retransmitted before giving up." is the sysctrl way of doing it in linux. On Thursday 10 July 2003 15:24, Bob Bell wrote: > On Wed, Jul 09, 2003 at 09:55:40PM -0400, Mrs. Brisby <mrs...@ni...> wrote: > > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > > ./rdesktop 192.168.1.55 > > > > server bpp 8 client bpp 16 depth 16 > > > > Trying 192.168.1.55... > > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > > machine listening there. > > > > > > this is the problem i am having. It times out eventually but its takes > > > far far too long. the users that will be using my clients are not > > > having access to command line so i need a fairly quick timeout. > > > > This is TCP related. There really isn't a lot you can do besides: > > 1. lower the timeout in your operating system (dangerous!) > > 2. use an alarm clock. > > You can also usually set a socket option. On Tru64 UNIX this is > TCP_KEEPINIT. On HP-UX it's TCP_CONN_ABORT_THRESHOLD. I don't know > what it is on Linux. > > Of course, this involves an OS-specific modification to the rdesktop > source to pull this off. ************************************************************************ DISCLAIMER: ----------- The information in this E-mail and in any attachments is confidential and is intended solely for the original addressee. It should not be used by anyone who is not an original intended recipient. Access, copying or use of information in it by anyone else is unauthorised and may be illegal. If you are not the intended recipient please contact the sender by replying to them and then delete the message. Akhter Computers Ltd cannot accept liability for statements made which are clearly the sender's own and are not made on behalf of Akhter Computers Ltd. No statement shall be construed as giving industrial/confidential advice within/outside the UK. ************************************************************************ |
From: Mrs. B. <mrs...@ni...> - 2003-07-12 02:18:38
|
On Thu, 2003-07-10 at 10:24, Bob Bell wrote: > On Wed, Jul 09, 2003 at 09:55:40PM -0400, Mrs. Brisby <mrs...@ni...> wrote: > > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > > ./rdesktop 192.168.1.55 > > > > server bpp 8 client bpp 16 depth 16 > > > > Trying 192.168.1.55... > > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > > machine listening there. > > > > > > this is the problem i am having. It times out eventually but its takes far > > > far too long. the users that will be using my clients are not having access > > > to command line so i need a fairly quick timeout. > > > > This is TCP related. There really isn't a lot you can do besides: > > 1. lower the timeout in your operating system (dangerous!) > > 2. use an alarm clock. > > You can also usually set a socket option. On Tru64 UNIX this is > TCP_KEEPINIT. On HP-UX it's TCP_CONN_ABORT_THRESHOLD. I don't know > what it is on Linux. > > Of course, this involves an OS-specific modification to the rdesktop > source to pull this off. Why bother? Saving an extra FIN or accidentally canceling a half-completed connection isn't going to happen often enough to waste a significant amount of bandwidth, and there's a perfectly fine (and almost portable) way to do it (and without signals... technically): 1. create the socket 2. set the nonblock flag on the fd 3. start the connect 4. select() until connected socket is writable- set a timeout on the select operation for whatever's desired. 5. if we're connected, turn the nonblock flag back off. the "hard" part occurs with how to determine /what/ error actually occurred. If we don't care, then that's it. No weird socket options. But if we _do_ care (and we're irritatingly persistent like that), we have: 6. call getpeername(); if we don't return zero, read(fd,&ch,1), and use the errno suggested there. This topic is gone over in great detail at: http://cr.yp.to/docs/connect.html Anyway, Linux doesn't complain about alarm pulls during connect, and while it borks-out the error code, the problem we're actually trying to solve here is providing a user-defined timeout. Steps 1-5 are sufficient for that for almost any UNIXish... |
From: Justin F. <ju...@ak...> - 2003-07-10 15:09:43
|
one more thing, you wrote in your patch "no need to gethostbyname" does that mean that the line: #include <netdb.h> /* gethostbyname */ isnt needed either? On Thursday 10 July 2003 02:55, Mrs. Brisby wrote: > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > ./rdesktop 192.168.1.55 > > > server bpp 8 client bpp 16 depth 16 > > > Trying 192.168.1.55... > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > machine listening there. > > > > this is the problem i am having. It times out eventually but its takes > > far far too long. the users that will be using my clients are not having > > access to command line so i need a fairly quick timeout. > > This is TCP related. There really isn't a lot you can do besides: > 1. lower the timeout in your operating system (dangerous!) > 2. use an alarm clock. > > > > You _might_ try using a shell script to sanitize the rdesktop IP > address. Something that looks like this: > > ---- > #!/bin/sh > ip=$1 > args="" > shift > while test "X$1" != "X" > do > args="$args $ip" > ip="$1" > shift > done > > if ping -w1 -c1 $ip >/dev/null 2>&1 > then > rdesktop $args $ip > else > echo "Ping failed" > fi ************************************************************************ DISCLAIMER: ----------- The information in this E-mail and in any attachments is confidential and is intended solely for the original addressee. It should not be used by anyone who is not an original intended recipient. Access, copying or use of information in it by anyone else is unauthorised and may be illegal. If you are not the intended recipient please contact the sender by replying to them and then delete the message. Akhter Computers Ltd cannot accept liability for statements made which are clearly the sender's own and are not made on behalf of Akhter Computers Ltd. No statement shall be construed as giving industrial/confidential advice within/outside the UK. ************************************************************************ |
From: Mrs. B. <mrs...@ni...> - 2003-07-12 02:00:56
|
No. gethostbyname is still used- but only for hostnames. On Thu, 2003-07-10 at 11:04, Justin Fretwell wrote: > one more thing, you wrote in your patch "no need to gethostbyname" does that > mean that the line: > > #include <netdb.h> /* gethostbyname */ > > isnt needed either? > > On Thursday 10 July 2003 02:55, Mrs. Brisby wrote: > > On Tue, 2003-07-08 at 05:35, Justin Fretwell wrote: > > > > ./rdesktop 192.168.1.55 > > > > server bpp 8 client bpp 16 depth 16 > > > > Trying 192.168.1.55... > > > > -- blocks for a rather long time- as expected; 55 doesn't have any > > > > machine listening there. > > > > > > this is the problem i am having. It times out eventually but its takes > > > far far too long. the users that will be using my clients are not having > > > access to command line so i need a fairly quick timeout. > > > > This is TCP related. There really isn't a lot you can do besides: > > 1. lower the timeout in your operating system (dangerous!) > > 2. use an alarm clock. > > > > > > > > You _might_ try using a shell script to sanitize the rdesktop IP > > address. Something that looks like this: > > > > ---- > > #!/bin/sh > > ip=$1 > > args="" > > shift > > while test "X$1" != "X" > > do > > args="$args $ip" > > ip="$1" > > shift > > done > > > > if ping -w1 -c1 $ip >/dev/null 2>&1 > > then > > rdesktop $args $ip > > else > > echo "Ping failed" > > fi > > > > ************************************************************************ > DISCLAIMER: > ----------- > The information in this E-mail and in any attachments is confidential > and is intended solely for the original addressee. It should not be > used by anyone who is not an original intended recipient. Access, > copying or use of information in it by anyone else is unauthorised and > may be illegal. If you are not the intended recipient please contact > the sender by replying to them and then delete the message. > > Akhter Computers Ltd cannot accept liability for statements made which > are clearly the sender's own and are not made on behalf of Akhter > Computers Ltd. No statement shall be construed as giving > industrial/confidential advice within/outside the UK. > ************************************************************************ |
From: Justin F. <ju...@ak...> - 2003-07-07 08:52:19
|
i amended the tcp.c file as per instructions and recompiled: bingo2:~/thin_client/rdesktop/rdesktop$ ./rdesktop -5 180.0.0.118 Trying 0.0.0.0...ERROR: 0.0.0.0: Connection refused To make sure i got this right i basically removed the old "tcp_connect()" and added yours and put the other function "finish_tcp_connect()" directly after it. i also added the function prototype at the top of the file: static BOOL finish_tcp_connect(char *, struct sockaddr_in *, char **); compiled it, no errors and ran it. On Saturday 05 July 2003 05:13, Mrs. Brisby wrote: > If it really is blocking in connect() (around line 155 in tcp.c/CVS), > then you can do either: > 1. put an alarm(N); right above that line, where N is the number of > seconds you want to wait. > 2. lower the TCP connection timeout limit on your operating system > > > However, the magic words you are using are "connect to an ip" -- I think > your resolver library doesn't translate gethostbyname()'s for IP > addresses, but instead actually asks the DNS cache for it, _AND_ you're > not using a DNS cache that performs that translation (like djbdns does) > > RDESKTOP-DEVEL: > > Your tcp_connect routine is not friendly to systems with a broken > resolver library (sadly, most aren't). > > I've taken the liberty of rewriting those functions. Since I am lazy, > I've just coded them in a separate file. Please see attached code > fragment, integrate into tcp.c (fairly easily) and apply to CVS. > > On Fri, 2003-07-04 at 04:50, Justin Fretwell wrote: > > I need to reduce the timeout when someone tries to connect to an ip with > > no terminal services running. how might i do this? ************************************************************************ DISCLAIMER: ----------- The information in this E-mail and in any attachments is confidential and is intended solely for the original addressee. It should not be used by anyone who is not an original intended recipient. Access, copying or use of information in it by anyone else is unauthorised and may be illegal. If you are not the intended recipient please contact the sender by replying to them and then delete the message. Akhter Computers Ltd cannot accept liability for statements made which are clearly the sender's own and are not made on behalf of Akhter Computers Ltd. No statement shall be construed as giving industrial/confidential advice within/outside the UK. ************************************************************************ |