I have 2 pcs, A and B and a router R. raffic is routed from A to the internet via B acting as a router to R and R routing to an ISDN line. Router R has some capability of operating as a name server on behalf of the internat. If I telnet R from A or B, it immediately opens the ISDN connection, which I don't want, because it costs. Why is this and how can I stop it? More info. B has eth0 and eth1 interfaces, and runs SuSE 8.0. It also does OS/2, in which case everything works perfectly. I think ping causes the same problem on Linux, but again not on OS/2. I am wondering whether Linux sees the connection out and goes sniffing for routing info or Name Server info or some such. If this is the case, I would appreciate knowing what, and how to turn it off. Any help on this appreciated, so I can complete the migration of B to Linux TIA Vince Littler
On Thursday 19 September 2002 10:24 pm, Vince Littler wrote:
I have 2 pcs, A and B and a router R. traffic is routed from A to the internet via B acting as a router to R and R routing to an ISDN line. Router R has some capability of operating as a name server on behalf of the internet.
If I telnet R from A or B, it immediately opens the ISDN connection, which I don't want, because it costs. Why is this and how can I stop it?
More info. B has eth0 and eth1 interfaces, and runs SuSE 8.0. It also does OS/2, in which case everything works perfectly. I think ping causes the same problem on Linux, but again not on OS/2.
I am wondering whether Linux sees the connection out and goes sniffing for routing info or Name Server info or some such. If this is the case, I would appreciate knowing what, and how to turn it off.
Any help on this appreciated, so I can complete the migration of B to Linux
TIA
Finally I have solved this one and maybe found a small bug in the host name resolution at the same time. If I do telnet 192.168.1.1 or whatever [by IP address] to my router, it opens an ISDN connection, and takes a number of seconds before opening the telnet session. However, after putting an entry for the router in the hosts table, the telnet session opens immediately whether I use the IP address or the host name, and the router does not connect to outside. So the bug seems to be that if one is invoking telnet with an IP address, it is not recognised as an IP address initially, rather it is treated as a name. First the hosts table is searched and then the DNS on the router, which then presumbly goes to my ISP's DNS which then says rather cleverly 'the IP address for hostname 192.168.1.1 is 192.168.1.1'. So, 1] is this a bug or is it expected behaviour? 2] If it is a bug, what is the correct place to take it? Regards Vince Littler
On Mon, 2003-04-07 at 10:11, Vince Littler wrote:
On Thursday 19 September 2002 10:24 pm, Vince Littler wrote:
I have 2 pcs, A and B and a router R. traffic is routed from A to the internet via B acting as a router to R and R routing to an ISDN line. Router R has some capability of operating as a name server on behalf of the internet.
If I telnet R from A or B, it immediately opens the ISDN connection, which I don't want, because it costs. Why is this and how can I stop it?
More info. B has eth0 and eth1 interfaces, and runs SuSE 8.0. It also does OS/2, in which case everything works perfectly. I think ping causes the same problem on Linux, but again not on OS/2.
I am wondering whether Linux sees the connection out and goes sniffing for routing info or Name Server info or some such. If this is the case, I would appreciate knowing what, and how to turn it off.
Any help on this appreciated, so I can complete the migration of B to Linux
TIA
Finally I have solved this one and maybe found a small bug in the host name resolution at the same time.
If I do telnet 192.168.1.1 or whatever [by IP address] to my router, it opens an ISDN connection, and takes a number of seconds before opening the telnet session. However, after putting an entry for the router in the hosts table, the telnet session opens immediately whether I use the IP address or the host name, and the router does not connect to outside.
So the bug seems to be that if one is invoking telnet with an IP address, it is not recognised as an IP address initially, rather it is treated as a name. First the hosts table is searched and then the DNS on the router, which then presumbly goes to my ISP's DNS which then says rather cleverly 'the IP address for hostname 192.168.1.1 is 192.168.1.1'.
So, 1] is this a bug or is it expected behaviour? 2] If it is a bug, what is the correct place to take it?
Regards
Vince Littler
This is not a bug. You added an entry for 192.168.1.1 in your hosts file therefore there is NO need to go to the internet to resolve the address as it is being resolved by your hosts file. Ken
Ken, Thanks for the reply. I fully agree that as I added an entry for 192.168.1.1 in my hosts file, there is NO need to go to the internet to resolve the address. That was my solution. My suspected bug is that [with no hosts file entry], the IP address I give the telnet command seems not to be taken as an IP address, but seems to be taken as a host name and go through the name resolution process, presumably until my ISP's DNS says 'hostname 192.168.1.1 is IP address 192.168.1.1' Do you not agree that if I call telnet with an IP address, there is no need to look in the hosts file to resolve anything? regards Vince On Monday 07 April 2003 3:31 pm, Ken Schneider wrote:
On Mon, 2003-04-07 at 10:11, Vince Littler wrote:
On Thursday 19 September 2002 10:24 pm, Vince Littler wrote:
I have 2 pcs, A and B and a router R. traffic is routed from A to the internet via B acting as a router to R and R routing to an ISDN line. Router R has some capability of operating as a name server on behalf of the internet.
If I telnet R from A or B, it immediately opens the ISDN connection, which I don't want, because it costs. Why is this and how can I stop it?
More info. B has eth0 and eth1 interfaces, and runs SuSE 8.0. It also does OS/2, in which case everything works perfectly. I think ping causes the same problem on Linux, but again not on OS/2.
I am wondering whether Linux sees the connection out and goes sniffing for routing info or Name Server info or some such. If this is the case, I would appreciate knowing what, and how to turn it off.
Any help on this appreciated, so I can complete the migration of B to Linux
TIA
Finally I have solved this one and maybe found a small bug in the host name resolution at the same time.
If I do telnet 192.168.1.1 or whatever [by IP address] to my router, it opens an ISDN connection, and takes a number of seconds before opening the telnet session. However, after putting an entry for the router in the hosts table, the telnet session opens immediately whether I use the IP address or the host name, and the router does not connect to outside.
So the bug seems to be that if one is invoking telnet with an IP address, it is not recognised as an IP address initially, rather it is treated as a name. First the hosts table is searched and then the DNS on the router, which then presumbly goes to my ISP's DNS which then says rather cleverly 'the IP address for hostname 192.168.1.1 is 192.168.1.1'.
So, 1] is this a bug or is it expected behaviour? 2] If it is a bug, what is the correct place to take it?
Regards
Vince Littler
This is not a bug. You added an entry for 192.168.1.1 in your hosts file therefore there is NO need to go to the internet to resolve the address as it is being resolved by your hosts file.
Ken
That is not correct. Since your computer nor your router know anything about the address it will search the internet to try and resolve the "hardware" address to the given "ip" address. Ken On Mon, 2003-04-07 at 10:54, Vince Littler wrote:
Ken,
Thanks for the reply. I fully agree that as I added an entry for 192.168.1.1 in my hosts file, there is NO need to go to the internet to resolve the address. That was my solution.
My suspected bug is that [with no hosts file entry], the IP address I give the telnet command seems not to be taken as an IP address, but seems to be taken as a host name and go through the name resolution process, presumably until my ISP's DNS says 'hostname 192.168.1.1 is IP address 192.168.1.1'
Do you not agree that if I call telnet with an IP address, there is no need to look in the hosts file to resolve anything?
regards
Vince
On Monday 07 April 2003 3:31 pm, Ken Schneider wrote:
On Mon, 2003-04-07 at 10:11, Vince Littler wrote:
On Thursday 19 September 2002 10:24 pm, Vince Littler wrote:
I have 2 pcs, A and B and a router R. traffic is routed from A to the internet via B acting as a router to R and R routing to an ISDN line. Router R has some capability of operating as a name server on behalf of the internet.
If I telnet R from A or B, it immediately opens the ISDN connection, which I don't want, because it costs. Why is this and how can I stop it?
More info. B has eth0 and eth1 interfaces, and runs SuSE 8.0. It also does OS/2, in which case everything works perfectly. I think ping causes the same problem on Linux, but again not on OS/2.
I am wondering whether Linux sees the connection out and goes sniffing for routing info or Name Server info or some such. If this is the case, I would appreciate knowing what, and how to turn it off.
Any help on this appreciated, so I can complete the migration of B to Linux
TIA
Finally I have solved this one and maybe found a small bug in the host name resolution at the same time.
If I do telnet 192.168.1.1 or whatever [by IP address] to my router, it opens an ISDN connection, and takes a number of seconds before opening the telnet session. However, after putting an entry for the router in the hosts table, the telnet session opens immediately whether I use the IP address or the host name, and the router does not connect to outside.
So the bug seems to be that if one is invoking telnet with an IP address, it is not recognised as an IP address initially, rather it is treated as a name. First the hosts table is searched and then the DNS on the router, which then presumbly goes to my ISP's DNS which then says rather cleverly 'the IP address for hostname 192.168.1.1 is 192.168.1.1'.
So, 1] is this a bug or is it expected behaviour? 2] If it is a bug, what is the correct place to take it?
Regards
Vince Littler
This is not a bug. You added an entry for 192.168.1.1 in your hosts file therefore there is NO need to go to the internet to resolve the address as it is being resolved by your hosts file.
Ken
On Monday 07 April 2003 17:00, Ken Schneider wrote:
That is not correct. Since your computer nor your router know anything about the address it will search the internet to try and resolve the "hardware" address to the given "ip" address.
resolve hardware address? You mean arp? It won't. It knows enough about the ip address from looking at the routing table, which should tell it all it needs to know about how to handle it. I think the problem in this case is that those numbers after telnet aren't numbers, they're characters. It looks like telnet first tries to resolve those characters as though it were a text url. Only after that fails will it try to convert it into a quad IP address. An strace shows ftp does the same thing. ssh doesn't, for some reason. If you want it to happen faster you could set up a local forwarding dns, which should be able to answer quicker than the remote dns that it's a malformed url.
Thanks for this Anders On Monday 07 April 2003 4:21 pm, Anders Johansson wrote:
On Monday 07 April 2003 17:00, Ken Schneider wrote:
That is not correct. Since your computer nor your router know anything about the address it will search the internet to try and resolve the "hardware" address to the given "ip" address.
resolve hardware address? You mean arp? It won't.
It knows enough about the ip address from looking at the routing table, which should tell it all it needs to know about how to handle it.
I think the problem in this case is that those numbers after telnet aren't numbers, they're characters. It looks like telnet first tries to resolve those characters as though it were a text url. Only after that fails will it try to convert it into a quad IP address.
YES, this is exactly what happens and I think you have put your finger on it in saying that the numbers are just a string as far as telnet understands them.
An strace shows ftp does the same thing. ssh doesn't, for some reason.
Yes, I knew some other service had displayed the behaviour, but it has been a while since I saw it, that I was reluctant t report it.
If you want it to happen faster you could set up a local forwarding dns, which should be able to answer quicker than the remote dns that it's a malformed url.
No, the hosts file is an acceptable work around. But the question remains, is there not a small bug inherent in this in that the destination address should be checked for being an IP address or a URL, and DNS only invoked for a URL? Or is it historic that DNS itself does the IP or URL check? [which was reasonable in the days before dialup and is reasonable again with broadband, but is bad behaviour in a dialup context] regards Vince Littler
On Mon, 2003-04-07 at 12:23, Vince Littler wrote:
Thanks for this Anders
On Monday 07 April 2003 4:21 pm, Anders Johansson wrote:
On Monday 07 April 2003 17:00, Ken Schneider wrote:
That is not correct. Since your computer nor your router know anything about the address it will search the internet to try and resolve the "hardware" address to the given "ip" address.
resolve hardware address? You mean arp? It won't.
It knows enough about the ip address from looking at the routing table, which should tell it all it needs to know about how to handle it.
I think the problem in this case is that those numbers after telnet aren't numbers, they're characters. It looks like telnet first tries to resolve those characters as though it were a text url. Only after that fails will it try to convert it into a quad IP address.
YES, this is exactly what happens and I think you have put your finger on it in saying that the numbers are just a string as far as telnet understands them.
An strace shows ftp does the same thing. ssh doesn't, for some reason.
Yes, I knew some other service had displayed the behaviour, but it has been a while since I saw it, that I was reluctant t report it.
If you want it to happen faster you could set up a local forwarding dns, which should be able to answer quicker than the remote dns that it's a malformed url.
No, the hosts file is an acceptable work around.
But the question remains, is there not a small bug inherent in this in that the destination address should be checked for being an IP address or a URL, and DNS only invoked for a URL?
Or is it historic that DNS itself does the IP or URL check? [which was reasonable in the days before dialup and is reasonable again with broadband, but is bad behaviour in a dialup context]
regards
Vince Littler
Maybe some simple networking lessons are in order. A "dotted quad address" is always treated as an "IP address" NOT some random text string URL. When you type the "IP address" as the destination, (whether telnet, ftp, http) it eliminates having to go through DNS to resolve a "name" to an "IP address". Once the "IP address" has been determined another query is sent on its way to the routers looking for the "MAC address" that belongs to the "IP address". EVERY request will resolve to a "MAC address" or fail. Try using ethereal to grab the packets as you make the request via an "IP address". Ken Schneider Network Administrator
On Monday 07 April 2003 18:36, Ken Schneider wrote:
Maybe some simple networking lessons are in order.
A "dotted quad address" is always treated as an "IP address" NOT some random text string URL.
argv is a pointer to an array of zero terminated character strings. How they are treated is not written in stone.
When you type the "IP address" as the destination, (whether telnet, ftp, http) it eliminates having to go through DNS to resolve a "name" to an "IP address".
only if you use getaddrinfo and pass it the flag AI_NUMERICHOST read "man 3 getaddrinfo" for more info.
Once the "IP address" has been determined another query is sent on its way to the routers looking for the "MAC address" that belongs to the "IP address".
arp queries are broadcast, not routed. They may be handled by a switch, rarely by a router.
EVERY request will resolve to a "MAC address" or fail.
Are you suggesting that every machine queries every other machine on the entire internet for its hardware address?
On Mon, 2003-04-07 at 13:11, Anders Johansson wrote:
On Monday 07 April 2003 18:36, Ken Schneider wrote:
Maybe some simple networking lessons are in order.
A "dotted quad address" is always treated as an "IP address" NOT some random text string URL.
argv is a pointer to an array of zero terminated character strings. How they are treated is not written in stone.
We are talking about the telnet command NOT c source.
When you type the "IP address" as the destination, (whether telnet, ftp, http) it eliminates having to go through DNS to resolve a "name" to an "IP address".
only if you use getaddrinfo and pass it the flag AI_NUMERICHOST
We are talking about the telnet command NOT c source. I don't know if I have ever typed getaddrinfo at the command line but I have used telnet.
read "man 3 getaddrinfo" for more info.
Once the "IP address" has been determined another query is sent on its way to the routers looking for the "MAC address" that belongs to the "IP address".
arp queries are broadcast, not routed. They may be handled by a switch, rarely by a router.
Yes but the query is sent as an "IP address" first which IS routed.
EVERY request will resolve to a "MAC address" or fail.
Are you suggesting that every machine queries every other machine on the entire internet for its hardware address?
The request sent is (I may not be quoting correctly) "Who has x.x.x.x" and listens for an answer. First the request is sent to your default router and so on and so on until one replies with that is has the "MAC address" for the requested "IP address". Ken
On Monday 07 April 2003 18:38, Ken Schneider wrote: <SNIP>
The request sent is (I may not be quoting correctly) "Who has x.x.x.x" and listens for an answer. First the request is sent to your default router and so on and so on until one replies with that is has the "MAC address" for the requested "IP address".
I thought the whole point of IP was to avoid the problems of MAC addresses 'in the wild' - differring formats and the like? the switch that my box is connected to is the only other piece of equipment which needs to know my MAC address. Everything else is done through IP, or am I so far off base I should start knapping flints? Dylan -- It is a dark day...
On Mon, 2003-04-07 at 13:47, Dylan wrote:
On Monday 07 April 2003 18:38, Ken Schneider wrote: <SNIP>
The request sent is (I may not be quoting correctly) "Who has x.x.x.x" and listens for an answer. First the request is sent to your default router and so on and so on until one replies with that is has the "MAC address" for the requested "IP address".
I thought the whole point of IP was to avoid the problems of MAC addresses 'in the wild' - differring formats and the like? the switch that my box is connected to is the only other piece of equipment which needs to know my MAC address. Everything else is done through IP, or am I so far off base I should start knapping flints?
The whole point of IP is that you can type in a textual name and NOT have to remember IP addresses and MAC addresses it resolves to. As I said earlier use ethereal to capture some packets on your local lan and see what actually transpires when making requests. Ken
I thought the whole point of IP was to avoid the problems of MAC addresses 'in the wild' - differring formats and the like? the switch that my box is connected to is the only other piece of equipment which needs to know my MAC address. Everything else is done through IP, or am I so far off base I should start knapping flints?
No, you are right to a point, but the ip address must be resolved to a mac address eventually (before the connection is made) just like a hostname is resolved to an ip address. As for mac addresses "in the wild", there is only one format. Each vendor (Intel, 3Com, etc) is assigned a range of addresses they can use. If I recall correctly this is the first two values in the colon or space delimited mac address (as they are usually displayed). The remainer of the address is assigned by the vendor with no two devices ever having the same mac addressed "burned in". A quick read through of the OSI model should serve as a good refresher and helps iron out what parts are used for what functions. I know I reread it every year or two! -- John LeMay KC2KTH Senior Enterprise Consultant NJMC | http://www.njmc.com | Phone 732-557-4848 Specializing in Microsoft and Unix based solutions
On Monday 07 April 2003 18:56, John LeMay wrote:
I thought the whole point of IP was to avoid the problems of MAC addresses 'in the wild' - differring formats and the like? the switch that my box is connected to is the only other piece of equipment which needs to know my MAC address. Everything else is done through IP, or am I so far off base I should start knapping flints?
No, you are right to a point, but the ip address must be resolved to a mac address eventually (before the connection is made) just like a hostname is resolved to an ip address.
As for mac addresses "in the wild", there is only one format. Each vendor (Intel, 3Com, etc) is assigned a range of addresses they can use. If I recall correctly this is the first two values in the colon or space delimited mac address (as they are usually displayed). The remainer of the address is assigned by the vendor with no two devices ever having the same mac addressed "burned in".
Does that count for non-ethernet as well? Dylan -- It is a dark day...
Today at 1:38pm, Ken Schneider wrote:
On Mon, 2003-04-07 at 13:11, Anders Johansson wrote:
On Monday 07 April 2003 18:36, Ken Schneider wrote:
Maybe some simple networking lessons are in order.
[snip]
The request sent is (I may not be quoting correctly) "Who has x.x.x.x" and listens for an answer. First the request is sent to your default router and so on and so on until one replies with that is has the "MAC address" for the requested "IP address".
ARP requests are only sent for IP addresses known by the host sending the request to be on subnet directly connected to that host. ARP requests are not sent to the default router--they can't be, because ARPs are sent with a broadcast MAC address and thus go to "everybody on this LAN segment." If your host wants to talk to a system that is not on a directly connected subnet, it will never know the MAC address of the remote host, because there is no way for that host to convey its MAC address. Perhaps Mr. Schneider could use some of the simple networking lessons he recommends for others. Jim Cunning
On Monday 07 April 2003 19:38, Ken Schneider wrote:
On Mon, 2003-04-07 at 13:11, Anders Johansson wrote:
On Monday 07 April 2003 18:36, Ken Schneider wrote:
Maybe some simple networking lessons are in order.
A "dotted quad address" is always treated as an "IP address" NOT some random text string URL.
argv is a pointer to an array of zero terminated character strings. How they are treated is not written in stone.
We are talking about the telnet command NOT c source.
telnet is written in C.
When you type the "IP address" as the destination, (whether telnet, ftp, http) it eliminates having to go through DNS to resolve a "name" to an "IP address".
only if you use getaddrinfo and pass it the flag AI_NUMERICHOST
We are talking about the telnet command NOT c source. I don't know if I have ever typed getaddrinfo at the command line but I have used telnet.
telnet is written in C. My comment above was poorly phrased. What I meant to say was that if you use getaddrinfo you pass the AI_NUMERICHOST flag to tell it to treat it as a numerical address and avoid a name lookup. It's explained in the man page. Obviously if you don't use getaddrinfo and you know you have a numeric address, you can create the struct needed manually. telnet uses getaddrinfo. telnet does not use AI_NUMERICHOST.
Once the "IP address" has been determined another query is sent on its way to the routers looking for the "MAC address" that belongs to the "IP address".
arp queries are broadcast, not routed. They may be handled by a switch, rarely by a router.
Yes but the query is sent as an "IP address" first which IS routed.
no
EVERY request will resolve to a "MAC address" or fail.
Are you suggesting that every machine queries every other machine on the entire internet for its hardware address?
The request sent is (I may not be quoting correctly) "Who has x.x.x.x" and listens for an answer. First the request is sent to your default router and so on and so on until one replies with that is has the "MAC address" for the requested "IP address".
Yes, the request is sent on the local lan. The TCP packet is then sent to the router for routing, so there's an arp lookup for the router ip (possibly cached). The router then does an arp lookup for the next routing hop and so on. The final router on the path does a lookup for the receiving machine, so it can send it on the recipient's local lan. The sending computer does not wait for, nor receive the other side's hardware address, except possibly as part of the ACK packets in the tcp protocol. arp is a LAN protocol. It is not used on the internet, nor is there a reason to use it on the internet.
On Monday 07 April 2003 18:23, Vince Littler wrote:
But the question remains, is there not a small bug inherent in this in that the destination address should be checked for being an IP address or a URL, and DNS only invoked for a URL?
After actually looking at the source, I see the reason. telnet does a getaddrinfo with the AI_CANONNAME set, which does at least a reverse name lookup. telnet itself doesn't try to parse the address very much. It looks like that's where the call to dns comes from. Maybe you could call it a bug or a buglet or an unwanted feature. If you have more than one machine you should have either host file entries or a local dns anyway.
On Mon, Apr 07, 2003 at 07:06:18PM +0200, Anders Johansson wrote:
On Monday 07 April 2003 18:23, Vince Littler wrote:
But the question remains, is there not a small bug inherent in this in that the destination address should be checked for being an IP address or a URL, and DNS only invoked for a URL?
After actually looking at the source, I see the reason. telnet does a getaddrinfo with the AI_CANONNAME set, which does at least a reverse name lookup. telnet itself doesn't try to parse the address very much. It looks like that's where the call to dns comes from.
Thank you. I was wondering who'd come to it first. Reverse lookup. Telnet ALWAYS does it. Drives me crazy sometimes, but then again....
Maybe you could call it a bug or a buglet or an unwanted feature. If you have more than one machine you should have either host file entries or a local dns anyway.
You need valid DNS lookups available, or a properly configured hosts file to keep it from checking DNS for the IP Address -> Hostname match. -- Brad Shelton On Line Exchange http://ole.net Phone: 313-526-1111 Fax: 313-526-3333
On Monday 07 April 2003 6:51 pm, Brad Shelton wrote:
On Mon, Apr 07, 2003 at 07:06:18PM +0200, Anders Johansson wrote:
After actually looking at the source, I see the reason. telnet does a getaddrinfo with the AI_CANONNAME set, which does at least a reverse name lookup. telnet itself doesn't try to parse the address very much. It looks like that's where the call to dns comes from.
Thank you. I was wondering who'd come to it first. Reverse lookup. Telnet ALWAYS does it. Drives me crazy sometimes, but then again....
Maybe you could call it a bug or a buglet or an unwanted feature. If you have more than one machine you should have either host file entries or a local dns anyway.
You need valid DNS lookups available, or a properly configured hosts file to keep it from checking DNS for the IP Address -> Hostname match.
Thanks to all on this. I think we have pinned down what is going on. But I would say that OS/2 and M$ telnet do not exhibit the behaviour. Presumably the GNU/Linux sources for telnet are so rooted in history that no-one dare suggest a change.... regards Vince Littler
On Monday 07 April 2003 15:11, Vince Littler wrote: <SNIP>
If I do telnet 192.168.1.1 or whatever [by IP address] to my router, it opens an ISDN connection, and takes a number of seconds before opening the telnet session. However, after putting an entry for the router in the hosts table, the telnet session opens immediately whether I use the IP address or the host name, and the router does not connect to outside.
So the bug seems to be that if one is invoking telnet with an IP address, it is not recognised as an IP address initially, rather it is treated as a name. First the hosts table is searched and then the DNS on the router, which then presumbly goes to my ISP's DNS which then says rather cleverly 'the IP address for hostname 192.168.1.1 is 192.168.1.1'.
So, 1] is this a bug or is it expected behaviour? 2] If it is a bug, what is the correct place to take it?
I don't think it's classifiable as a bug, but more a sloppy approach. In an environment where the order of checking doesn't matter, it may have been easier to code a DNS lookup then if that fails assume an IP address. Parsing for an IP shouldn't be too difficult, but there may have been a time when lookup-speed<parse-speed. To be frank, I don't see why this would be an app issue, surely enough apps need to make an IP connection of some sort that connect_to(IP_address|URL) should exist to sort out the whole sorry mess. £0.02 Dylan -- It is a dark day...
participants (7)
-
Anders Johansson -
Brad Shelton -
Dylan -
Jim Cunning -
John LeMay -
Ken Schneider -
Vince Littler