Re: TCP connection problem.
I have a tcp connection problem. I connect to the Internet using a Debian 2.2r2. Some web servers refuse to respond to my requests. No matter witch browser I use (Lynx, Netscape Opera), they access the web servers but no data is transferred from them. The servers seems to run on Windoze NT 4.0. One example of this is www.conexant.com I try telnet webserver.com 80 and after connection I send a request like a browser do, but the response does not come. I suspect somme tcp connection problems. If I use a proxy from the net all works fine. Those servers seem to check if your IP can be reverse-resolved to an internet domain name. If you do have external IP (e.g. not masqueraded by your ISP) then you should have your IP to be written in DNS reverse-lookup tables, ask your ISP to do so or do it yourself if DNS in on your machine. This could help. Could be my kernel (custom 2.2.19) the source of this problem ? Please help ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
TCP connection problem.
I have a tcp connection problem. I connect to the Internet using a Debian 2.2r2. Some web servers refuse to respond to my requests. No matter witch browser I use (Lynx, Netscape Opera), they access the web servers but no data is transferred from them. The servers seems to run on Windoze NT 4.0. One example of this is www.conexant.com I try telnet webserver.com 80 and after connection I send a request like a browser do, but the response does not come. I suspect somme tcp connection problems. If I use a proxy from the net all works fine. Could be my kernel (custom 2.2.19) the source of this problem ? Please help ! -- Best regards, Minta Adrian - YO3GIH phone: +401.683.66.52 mailto:[EMAIL PROTECTED]http://www.geocities.com/adrianminta
Re: tcp connection
- Original Message - From: Russell Coker [EMAIL PROTECTED] To: Chris Wagner [EMAIL PROTECTED]; Debian ISP List [EMAIL PROTECTED] Sent: Friday, June 23, 2000 5:18 AM Subject: Re: tcp connection On Wed, 21 Jun 2000, Chris Wagner wrote: At 02:25 PM 6/20/00 +0200, Russell Coker wrote: They don't use NVT. The TELNET protocol is not running on (for example) a web server. Yeah but the NVT settings have to be negotiated for each side to talk to each other. If I telnet to an Apache webserver on port 80, my telnet is No they don't. If the server doesn't start NVT negotiation then nothing happens. going to negotiate NVT with whatever's on the other end. Both sides have to agree to establish the connection. Therefore, either Apache or something below Apache in the stack has to know about NVT. Otherwise Apache would tell me to go take a flying leap if I tried to telnet to it. What is my telnet client negotiating with in this case??? Telnet client negotiates nothing. Text you type is sent, but "\n" is replaced by "\r\n". Text that is received is just displayed as-is. As an experiment to find out how hard it would be for you to determine this without asking the list I timed myself. I determined that in 121 seconds by running strace(1) on telnet. I tried using ltrace(1) to determine the same information, but after 149 seconds I realised that it was not the right tool and would not be able to provide me with the information. Ltrace displays the values of pointers instead of the data it referrs to. I could have used "-S" which might have been more useful, but there's no point when strace(1) is available. Then I decided to solve it properly. Firstly I read rfc854 and rfc855 (the base RFCs on TELNET) which didn't clarify this issue. Then I put a telnet daemon on port 23 and straced a telnet connection to it. The telnet client started with sending a sequence of NVT protocol commands to it which were responded to. Then I put the telnet daemon on port 1000 and repeated the test, this time the telnet client didn't start sending any NVT commands until after it had received some (the server had shown itself to be a NVT protocol server not a web server or whatever else I may have chosen to run on that port). NVT is totally bi-directional so it could run either way. This took me 821 seconds. Chris, most people here would not be able to do what I just did. However I believe that you are able to do everything I did (although it may have taken you a bit longer). I think that you should be answering questions of that nature not asking them. I often see questions that I don't know the answer to, and research them for the benefit of the person who asked and everyone else on the list. It is a great way to learn about things if you've got some spare time. This is why I think that you should have researched and answered if someone else had asked the question. Russell Coker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tcp connection
- Original Message - From: Russell Coker [EMAIL PROTECTED] To: Chris Wagner [EMAIL PROTECTED]; Debian ISP List debian-isp@lists.debian.org Sent: Friday, June 23, 2000 5:18 AM Subject: Re: tcp connection On Wed, 21 Jun 2000, Chris Wagner wrote: At 02:25 PM 6/20/00 +0200, Russell Coker wrote: They don't use NVT. The TELNET protocol is not running on (for example) a web server. Yeah but the NVT settings have to be negotiated for each side to talk to each other. If I telnet to an Apache webserver on port 80, my telnet is No they don't. If the server doesn't start NVT negotiation then nothing happens. going to negotiate NVT with whatever's on the other end. Both sides have to agree to establish the connection. Therefore, either Apache or something below Apache in the stack has to know about NVT. Otherwise Apache would tell me to go take a flying leap if I tried to telnet to it. What is my telnet client negotiating with in this case??? Telnet client negotiates nothing. Text you type is sent, but \n is replaced by \r\n. Text that is received is just displayed as-is. As an experiment to find out how hard it would be for you to determine this without asking the list I timed myself. I determined that in 121 seconds by running strace(1) on telnet. I tried using ltrace(1) to determine the same information, but after 149 seconds I realised that it was not the right tool and would not be able to provide me with the information. Ltrace displays the values of pointers instead of the data it referrs to. I could have used -S which might have been more useful, but there's no point when strace(1) is available. Then I decided to solve it properly. Firstly I read rfc854 and rfc855 (the base RFCs on TELNET) which didn't clarify this issue. Then I put a telnet daemon on port 23 and straced a telnet connection to it. The telnet client started with sending a sequence of NVT protocol commands to it which were responded to. Then I put the telnet daemon on port 1000 and repeated the test, this time the telnet client didn't start sending any NVT commands until after it had received some (the server had shown itself to be a NVT protocol server not a web server or whatever else I may have chosen to run on that port). NVT is totally bi-directional so it could run either way. This took me 821 seconds. Chris, most people here would not be able to do what I just did. However I believe that you are able to do everything I did (although it may have taken you a bit longer). I think that you should be answering questions of that nature not asking them. I often see questions that I don't know the answer to, and research them for the benefit of the person who asked and everyone else on the list. It is a great way to learn about things if you've got some spare time. This is why I think that you should have researched and answered if someone else had asked the question. Russell Coker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tcp connection
On Wed, 21 Jun 2000, Chris Wagner wrote: At 02:25 PM 6/20/00 +0200, Russell Coker wrote: They don't use NVT. The TELNET protocol is not running on (for example) a web server. Yeah but the NVT settings have to be negotiated for each side to talk to each other. If I telnet to an Apache webserver on port 80, my telnet is No they don't. If the server doesn't start NVT negotiation then nothing happens. going to negotiate NVT with whatever's on the other end. Both sides have to agree to establish the connection. Therefore, either Apache or something below Apache in the stack has to know about NVT. Otherwise Apache would tell me to go take a flying leap if I tried to telnet to it. What is my telnet client negotiating with in this case??? Telnet client negotiates nothing. Text you type is sent, but \n is replaced by \r\n. Text that is received is just displayed as-is. As an experiment to find out how hard it would be for you to determine this without asking the list I timed myself. I determined that in 121 seconds by running strace(1) on telnet. I tried using ltrace(1) to determine the same information, but after 149 seconds I realised that it was not the right tool and would not be able to provide me with the information. Ltrace displays the values of pointers instead of the data it referrs to. I could have used -S which might have been more useful, but there's no point when strace(1) is available. Then I decided to solve it properly. Firstly I read rfc854 and rfc855 (the base RFCs on TELNET) which didn't clarify this issue. Then I put a telnet daemon on port 23 and straced a telnet connection to it. The telnet client started with sending a sequence of NVT protocol commands to it which were responded to. Then I put the telnet daemon on port 1000 and repeated the test, this time the telnet client didn't start sending any NVT commands until after it had received some (the server had shown itself to be a NVT protocol server not a web server or whatever else I may have chosen to run on that port). NVT is totally bi-directional so it could run either way. This took me 821 seconds. Chris, most people here would not be able to do what I just did. However I believe that you are able to do everything I did (although it may have taken you a bit longer). I think that you should be answering questions of that nature not asking them. I often see questions that I don't know the answer to, and research them for the benefit of the person who asked and everyone else on the list. It is a great way to learn about things if you've got some spare time. This is why I think that you should have researched and answered if someone else had asked the question. Russell Coker
Re: tcp connection
Are we talking about the 'TCP 3-way handshake'? -- Kevin Blackham 801-539-0852 [EMAIL PROTECTED]877-964-7746 XMission Internet, Salt Lake City, Utah On Tue, Jun 20, 2000 at 09:47:25PM -0400, Chris Wagner wrote: At 02:25 PM 6/20/00 +0200, Russell Coker wrote: They don't use NVT. The TELNET protocol is not running on (for example) a web server. Yeah but the NVT settings have to be negotiated for each side to talk to each other. If I telnet to an Apache webserver on port 80, my telnet is going to negotiate NVT with whatever's on the other end. Both sides have to agree to establish the connection. Therefore, either Apache or something below Apache in the stack has to know about NVT. Otherwise Apache would tell me to go take a flying leap if I tried to telnet to it. What is my telnet client negotiating with in this case??? +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++ 0100 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tcp connection
On Mon, 19 Jun 2000, Chris Wagner wrote: At 12:50 AM 6/19/00 +0200, Russell Coker wrote: It is called TCP - Transmission Control Protocol. RFC793. I'm starting to conclude that it's just called a tcp connection. But I'm still reading through the RFC... It was written in 1983 and for whatever reason it seems to use the term socket and port interchangeably. Seems like they had different meanings than they do now. The older RFCs were written in very poor English. I guess it's just coincidence that the common high level protocols all use the same NVT settings. Otherwise, telneting to a web server would fail. Maybe its the NVT settings that are the highest common thread here, does that standard have a name I wonder. They don't use NVT. The TELNET protocol is not running on (for example) a web server. If you have doc-rfc package installed: file:/usr/doc/doc-rfc/rfc793.txt.gz Don't got that, but I found faqs.org. Get it. doc-rfc is an essential package to have on your laptop if you are seriously into these things. Anyone who calls the protocol Transport Control Protocol is stupid and should be ignored. Instruct such people to read the documents and learn. I've never heard anybody call it that. MS do in all their documentation. MS weenies say that everyone else should change what they call the protocol to match what MS calls it. -- My current location - X marks the spot. X X X
Re: tcp connection
At 02:25 PM 6/20/00 +0200, Russell Coker wrote: They don't use NVT. The TELNET protocol is not running on (for example) a web server. Yeah but the NVT settings have to be negotiated for each side to talk to each other. If I telnet to an Apache webserver on port 80, my telnet is going to negotiate NVT with whatever's on the other end. Both sides have to agree to establish the connection. Therefore, either Apache or something below Apache in the stack has to know about NVT. Otherwise Apache would tell me to go take a flying leap if I tried to telnet to it. What is my telnet client negotiating with in this case??? +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++ 0100
Re: tcp connection
At 12:50 AM 6/19/00 +0200, Russell Coker wrote: It is called TCP - Transmission Control Protocol. RFC793. I'm starting to conclude that it's just called a tcp connection. But I'm still reading through the RFC... It was written in 1983 and for whatever reason it seems to use the term socket and port interchangeably. Seems like they had different meanings than they do now. I guess it's just coincidence that the common high level protocols all use the same NVT settings. Otherwise, telneting to a web server would fail. Maybe its the NVT settings that are the highest common thread here, does that standard have a name I wonder. If you have doc-rfc package installed: file:/usr/doc/doc-rfc/rfc793.txt.gz Don't got that, but I found faqs.org. Anyone who calls the protocol Transport Control Protocol is stupid and should be ignored. Instruct such people to read the documents and learn. I've never heard anybody call it that. PS There's no need to read 2500 RFC. A zgrep of the indexes will usually allow you to find what you want rapidly. I was being facetious. :) +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++
Re: tcp connection
On Sun, 18 Jun 2000, Chris Wagner wrote: What I meant by that was what "octets mean and do" in terms of establishing and maintaining the connection. Like, what octets are exchanged that tell each machine, "yes the connection is established". That protocol has a name. It is called TCP - Transmission Control Protocol. RFC793. If you have doc-rfc package installed: file:/usr/doc/doc-rfc/rfc793.txt.gz Anyone who calls the protocol "Transport Control Protocol" is stupid and should be ignored. Instruct such people to read the documents and learn. Russell Coker PS There's no need to read 2500 RFC. A zgrep of the indexes will usually allow you to find what you want rapidly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tcp connection
At 12:50 AM 6/19/00 +0200, Russell Coker wrote: It is called TCP - Transmission Control Protocol. RFC793. I'm starting to conclude that it's just called a "tcp connection". But I'm still reading through the RFC... It was written in 1983 and for whatever reason it seems to use the term socket and port interchangeably. Seems like they had different meanings than they do now. I guess it's just coincidence that the common high level protocols all use the same NVT settings. Otherwise, telneting to a web server would fail. Maybe its the NVT settings that are the highest common thread here, does that standard have a name I wonder. If you have doc-rfc package installed: file:/usr/doc/doc-rfc/rfc793.txt.gz Don't got that, but I found faqs.org. Anyone who calls the protocol "Transport Control Protocol" is stupid and should be ignored. Instruct such people to read the documents and learn. I've never heard anybody call it that. PS There's no need to read 2500 RFC. A zgrep of the indexes will usually allow you to find what you want rapidly. I was being facetious. :) +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tcp connection
On Sun, 18 Jun 2000, Chris Wagner wrote: What I meant by that was what octets mean and do in terms of establishing and maintaining the connection. Like, what octets are exchanged that tell each machine, yes the connection is established. That protocol has a name. It is called TCP - Transmission Control Protocol. RFC793. If you have doc-rfc package installed: file:/usr/doc/doc-rfc/rfc793.txt.gz Anyone who calls the protocol Transport Control Protocol is stupid and should be ignored. Instruct such people to read the documents and learn. Russell Coker PS There's no need to read 2500 RFC. A zgrep of the indexes will usually allow you to find what you want rapidly.
Re: tcp connection
At 10:48 PM 6/16/00 -0500, Sanjeev Gupta wrote: Sockets? Butyou would definitely have seen this more than a couple of times. No, not sockets, sockets are way down on the stack. This is the protocol that says what the octets mean and do. It's the common thread among all the high level protocols and is directly below them in the stack. But I can't think of the darn name. +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++
Re: tcp connection
On Sat, Jun 17, 2000 at 12:43:45AM -0400, Chris Wagner wrote: At 10:48 PM 6/16/00 -0500, Sanjeev Gupta wrote: Sockets? Butyou would definitely have seen this more than a couple of times. No, not sockets, sockets are way down on the stack. This is the protocol that says what the octets mean and do. It's the common thread among all the high level protocols and is directly below them in the stack. But I can't think of the darn name. What I think you're thinking of is just IP. You probably haven't been seeing it, because there is no concept of connection in TCP/IP stacks until you hit TCP, but here's how your connection kinda works (at least on 2 *nix boxen): peer--socket filehandle--transport--socket filehandle--peer transport here can be one of many things, such as: socket fd--unix domain socket--socket fd or socket fd--TCP--IP--ip transport(LAN/PPP/X.25/SmokeSignals)- -IP--TCP--socket fd Now, if you actually mean what octets mean and do, those are actually defined higher than TCP, and are laid out in the specs for those respective protocols. i.e.: Telnet Protocol: RFC 854/855 FTP:RFC 959 TFTP: RFC 1350 POP3: RFC 1939 HTTP/1.1: RFC 2068 Hope that helps. -- Love is like a friendship caught on fire. In the beginning a flame, very pretty, often hot and fierce, but still only light and flickering. As love grows older, our hearts mature and our love becomes as coals, deep-burning and unquenchable. -- Bruce Lee ** Penguin Sympathizer Bryon Roche, Kain [EMAIL PROTECTED] pgpGsUHT5B6qS.pgp Description: PGP signature
Re: tcp connection
On Sat, 17 Jun 2000, Chris Wagner wrote: At 10:48 PM 6/16/00 -0500, Sanjeev Gupta wrote: Sockets? Butyou would definitely have seen this more than a couple of times. No, not sockets, sockets are way down on the stack. This is the protocol that says what the octets mean and do. It's the common thread among all the high level protocols and is directly below them in the stack. But I can't think of the darn name. XDR? I think that is the Sun (or Xerox) standard for endian-ness in network octet encoding. This thread should make interesting reading in the archives. Regards
Re: tcp connection
At 12:24 AM 6/17/00 -0500, Kain wrote: What I think you're thinking of is just IP. You probably haven't been seeing Definately not IP, IP just gets your packets there and back. Now, if you actually mean what octets mean and do, those are actually defined higher than TCP, and are laid out in the specs for those respective protocols. What I meant by that was what octets mean and do in terms of establishing and maintaining the connection. Like, what octets are exchanged that tell each machine, yes the connection is established. That protocol has a name. Telnet Protocol: RFC 854/855 FTP: RFC 959 TFTP: RFC 1350 POP3: RFC 1939 HTTP/1.1: RFC 2068 Right, those are the high level protocols. But they all establish the same type of connection. Maybe if I explained how this came about. I was explaining to a friend how you can telnet to any network service and use that service. Like, you can telnet to a web server on port 80, manually type the get commands and get the document. I said that this was because they all use the same connection type. But I don't know what the name of that connection type is. Maybe it's just a TCP connection, does what I'm talking about have an RFC? There's no way I'm reading through all 2500 RFC's. :) At 11:14 AM 6/18/00 +1200, [EMAIL PROTECTED] wrote: LCP? Link control protocol I think that has to do with PPP. +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++
tcp connection
Hola. What is the official name of the type of connection that the common network protocols use? It lives somewhere above the tcp layer and below the app layer but is so obscure that I can't find it. e.g. Telnet, ftp, http, etc. all establish an x type connection and then transmit their data. It has to do with what means what to each side of the connection... I've only seen this I think one time ever. Know what I'm talking about? +---+ |-=I T ' S P R I N C I P L E T H A T C O U N T S=- | |=- -=ALAN KEYES FOR PRESIDENT=- -=| | Balanced Budgets Personal Freedoms Morality Lower Tax | |=-- http://www.Keyes2000.com. --=| ++
Re: tcp connection
On Fri, 16 Jun 2000, Chris Wagner wrote: Hola. What is the official name of the type of connection that the common network protocols use? It lives somewhere above the tcp layer and below the app layer but is so obscure that I can't find it. e.g. Telnet, ftp, http, etc. all establish an x type connection and then transmit their data. It has to do with what means what to each side of the connection... I've only seen this I think one time ever. Know what I'm talking about? Sockets? Butyou would definitely have seen this more than a couple of times. HTH
