• Newbie learning about Ports

    From adnanchowdhury88@gmail.com@1:0/0 to All on Fri Jun 14 14:56:40 2013

    Hello all,=20

    I am trying to grok network ports and how they work ... Mainly because I wa=
    s trying to see if a machine at work could see my local DNS and I looked up=
    the port binding used by DNS servers and read this:

    "In general, all DNS queries are sent from a high-numbered source port (491=
    52 or above) to destination port 53, and responses are sent from source por=
    t 53 to a high-numbered destination port. The following table lists the UDP=
    and TCP ports used for different DNS message types."

    When I access a website, I am assuming that my outbound traffic is going ou=
    t port 80 and reaching the server's port 80, and when the server responds i=
    t sends through its port 80 to my port 80. Is there anything wrong with thi=
    s assumption? (I think there might be)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Rick Jones@110:110/2002 to All on Fri Jun 14 17:54:46 2013

    adnanchowdhury88@gmail.com wrote:

    I am trying to grok network ports and how they work ... Mainly
    because I was trying to see if a machine at work could see my local
    DNS and I looked up the port binding used by DNS servers and read
    this:

    "In general, all DNS queries are sent from a high-numbered source
    port (49152 or above) to destination port 53, and responses are sent
    from source port 53 to a high-numbered destination port. The
    following table lists the UDP and TCP ports used for different DNS
    message types."

    When I access a website, I am assuming that my outbound traffic is
    going out port 80 and reaching the server's port 80, and when the
    server responds it sends through its port 80 to my port 80. Is there
    anything wrong with this assumption? (I think there might be)

    Your assumption is incorrect. Just like the DNS example you found, 99
    times out of 10, the web client will connect from a local port number
    other than 80. Unless the client code makes an explicit bind() call,
    when it connect()s to port 80 on the web server, the local port number
    will be selected from the "ephemeral" (sometimes called the
    "anonymous") port range of the client's TCP stack. That will vary
    with client OS, but generally speaking it will be port numbers higher
    than 32768 or 49152 and lower than 61000 or 65535.

    The port numbers are part of how TCP "names" a connection. The
    four-tuple of local and remote IP address and local and remote port
    number for the "name" of the TCP connection. Those uniquely identify
    it from all other TCP connections.

    If your web client connected from port 80 to port 80 on the web
    server, there could then be only one unique TCP connection between
    them - clientIP,serverIP,80,80.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From adnanchowdhury88@gmail.com@1:0/0 to All on Fri Jun 14 19:03:44 2013

    On Friday, June 14, 2013 1:54:46 PM UTC-4, Rick Jones wrote:



    I am trying to grok network ports and how they work ... Mainly

    because I was trying to see if a machine at work could see my local

    DNS and I looked up the port binding used by DNS servers and read

    this:



    "In general, all DNS queries are sent from a high-numbered source

    port (49152 or above) to destination port 53, and responses are sent

    from source port 53 to a high-numbered destination port. The

    following table lists the UDP and TCP ports used for different DNS

    message types."



    When I access a website, I am assuming that my outbound traffic is

    going out port 80 and reaching the server's port 80, and when the

    server responds it sends through its port 80 to my port 80. Is there

    anything wrong with this assumption? (I think there might be)



    Your assumption is incorrect. Just like the DNS example you found, 99

    times out of 10, the web client will connect from a local port number

    other than 80. Unless the client code makes an explicit bind() call,

    when it connect()s to port 80 on the web server, the local port number

    will be selected from the "ephemeral" (sometimes called the

    "anonymous") port range of the client's TCP stack. That will vary

    with client OS, but generally speaking it will be port numbers higher

    than 32768 or 49152 and lower than 61000 or 65535.



    The port numbers are part of how TCP "names" a connection. The

    four-tuple of local and remote IP address and local and remote port

    number for the "name" of the TCP connection. Those uniquely identify

    it from all other TCP connections.



    If your web client connected from port 80 to port 80 on the web

    server, there could then be only one unique TCP connection between

    them - clientIP,serverIP,80,80.



    rick jones

    --

    The computing industry isn't as much a game of "Follow The Leader" as

    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."

    - Rick Jones

    these opinions are mine, all mine; HP might not want them anyway... :)

    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    Thanks for the explanation Rick I found it very helpful. I admit though, I still don't have a firm understanding of it all.

    If I make a request for website A.com, the outgoing traffic will leave through an ephemeral port to be received by A.com's port 80, correct? And when the server responds, will it leave its own ephemeral port to be received by my port 80?

    Do you have any articles/documentation on the matter that could explain the process further?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Moe Trin@110:110/2002 to All on Fri Jun 14 19:58:04 2013

    On Fri, 14 Jun 2013, in the Usenet newsgroup comp.os.linux.networking, in article <b4b24feb-ff6d-42f1-a411-47086367c95f@googlegroups.com>, adnanchowdhury88@gmail.com wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    Rick Jones wrote:

    Your assumption is incorrect. Just like the DNS example you found,
    99 times out of 10, the web client will connect from a local port
    number other than 80. Unless the client code makes an explicit
    bind() call, when it connect()s to port 80 on the web server, the
    local port number will be selected from the "ephemeral" (sometimes
    called the "anonymous") port range of the client's TCP stack.

    If I make a request for website A.com, the outgoing traffic will
    leave through an ephemeral port to be received by A.com's port 80,
    correct? And when the server responds, will it leave its own
    ephemeral port to be received by my port 80?

    [fermi ~]$ whatis netstat
    netstat (8) - Print network connections, routing tables,
    interface statistics, masquerade connections, and
    multicast memberships
    [fermi ~]$

    Run the command 'netstat -antu' after you read that manual page.
    No, you make a connection from port $FOO (example 21289) to their
    port 80 - so their reply uses that connection - i.e. it comes from
    their 80 to your $FOO (example 21289). The word is "connection".

    Do you have any articles/documentation on the matter that could
    explain the process further?

    http://www.netfilter.org/documentation/HOWTO/

    [TXT] NAT-HOWTO.txt 05-Oct-2012 10:33 25K
    [TXT] netfilter-double-nat.txt 05-Oct-2012 10:33 9.4K
    [TXT] netfilter-extensions-HOWTO.txt 05-Oct-2012 10:33 80K
    [TXT] netfilter-hacking-HOWTO.txt 05-Oct-2012 10:33 81K
    [TXT] netfilter-mirror-HOWTO.txt 05-Oct-2012 10:33 7.8K
    [TXT] networking-concepts-HOWTO.txt 05-Oct-2012 10:33 28K
    [TXT] packet-filtering-HOWTO.txt 05-Oct-2012 10:33 51K

    You want to read the "networking-concepts" and "packet-filtering"
    documents. Another item that would help is RFC1180

    1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991.
    (Format: TXT=65494 bytes) (Status: INFORMATIONAL)

    You can use a search-engine to find a copy of RFC1180 in dozens of
    places.

    Old guy

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: When in doubt, use brute force. (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Fri Jun 14 22:25:12 2013

    adnanchowdhury88@gmail.com wrote:
    Thanks for the explanation Rick I found it very helpful. I admit
    though, I still don't have a firm understanding of it all.

    If I make a request for website A.com, the outgoing traffic will
    leave through an ephemeral port to be received by A.com's port 80,
    correct? And when the server responds, will it leave its own
    ephemeral port to be received by my port 80?

    No. In this case the only ephemeral port is on the client. Source and destination port numbers get swapped when going the other way.

    From your client, it will be source port == yourephemeral; destination
    port == 80. When the server replies it will be source port == 80
    destination port == your ephemeral.

    Do you have any articles/documentation on the matter that could
    explain the process further?

    The works of the late W Richard Steves would be one source.

    rick
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Tauno Voipio@110:110/2002 to All on Sat Jun 15 14:40:12 2013

    On 15.6.13 1:25 , Rick Jones wrote:
    adnanchowdhury88@gmail.com wrote:
    Thanks for the explanation Rick I found it very helpful. I admit
    though, I still don't have a firm understanding of it all.

    If I make a request for website A.com, the outgoing traffic will
    leave through an ephemeral port to be received by A.com's port 80,
    correct? And when the server responds, will it leave its own
    ephemeral port to be received by my port 80?

    No. In this case the only ephemeral port is on the client. Source and destination port numbers get swapped when going the other way.

    From your client, it will be source port == yourephemeral; destination
    port == 80. When the server replies it will be source port == 80
    destination port == your ephemeral.

    Do you have any articles/documentation on the matter that could
    explain the process further?

    The works of the late W Richard Steves would be one source.

    rick


    You should start with:

    TCP/IP Illustrated, Volume 1, The Protocols

    Be warned, there are hundreds of pages to read end understand.

    --

    -Tauno Voipio


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Martijn Lievaart@1:0/0 to All on Sat Jun 15 14:39:12 2013

    On Fri, 14 Jun 2013 12:03:44 -0700, adnanchowdhury88 wrote:


    The port numbers are part of how TCP "names" a connection. The

    four-tuple of local and remote IP address and local and remote port

    number for the "name" of the TCP connection. Those uniquely identify

    it from all other TCP connections.



    If your web client connected from port 80 to port 80 on the web

    server, there could then be only one unique TCP connection between

    them - clientIP,serverIP,80,80.



    rick jones

    --

    The computing industry isn't as much a game of "Follow The Leader" as

    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."

    - Rick Jones

    these opinions are mine, all mine; HP might not want them anyway... :)

    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    Thanks for the explanation Rick I found it very helpful. I admit though,
    I still don't have a firm understanding of it all.

    If I make a request for website A.com, the outgoing traffic will leave through an ephemeral port to be received by A.com's port 80, correct?
    And when the server responds, will it leave its own ephemeral port to be received by my port 80?

    Reread the above again. And stop thinking of ports as entities, think of
    them as labels. They are only small integers, nothing more, nothing
    less. A packet will not "leave a port", it will be sent with it source
    and destination port fields set to some value.

    When you create a (tcp) connection, we say the connection is identified
    by IP-A:Port-A and IP-B:Port-B. Machine A will see this as a connection
    from IP-A:Port-A to IP-B:Port-B but machine B will think of this as a connection from IP-B:Port-B and IP-A:Port-A. It is the same connection,
    but seen from the two endpoints.

    It is just as valid to identify this connection by IP-A:Port-A and IP-
    B:Port-B as to identify it by IP-B:Port-B and IP-A:Port-A. When we
    humans identify a connection, we always put the machine that initiated
    the connection as the first machine, but this is just a convention (and a useful one at that). Once the connection is established there is
    technically no difference between the two endpoints and you cannot
    determine any more who started the connection without further context.

    So any packet from A to B for this connection will contain the fields source-IP=IP-A, source-port=Port-A, dest-IP=IP-B, dest-port=Port-B.

    Any return packet, that is any packet sent from B to A as part of this connection, will have source and destination reversed, so source-IP=IP-B, source-port=Port-B, dest-IP=IP-A, dest-port=Port-A.

    when machine A receives the return packet sent by B, it looks up which connection this packet belongs to, by looking at it's connection table.
    As said above, machine A "knows" this connection as "from IP-A:Port-A to IP-B:Port-B". But the return packet is˙from IP-B:Port-B to IP-A:Port-A.
    So to find a connection in its connection table for any received packet, machine A has to reverse the source and destination ip:port pairs in
    order to look the connection up.

    HTH,
    M4

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jorgen Grahn@1:0/0 to All on Sat Jun 15 21:00:40 2013

    On Sat, 2013-06-15, Martijn Lievaart wrote:
    ....

    And stop thinking of ports as entities, think of
    them as labels. They are only small integers, nothing more, nothing
    less.

    Yeah. Just when I started doing network programming, the names "port"
    and "socket" were major sources of confusion. I suspect that with
    some more thinking, someone at Berkeley could have come up with better
    names. (The abstractions themselves are sound, though.)

    A packet will not "leave a port", it will be sent with it source
    and destination port fields set to some value.

    A bit too concrete to be useful in practice, perhaps. I think of it
    as the packet having a return address which allows a reply not only to
    the /host/, but to the actual /program/ on that host (if the program
    is still alive at that time).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb