Somewhere in a dark room a brilliant mind sits typing out an email in reply to a posting on the gentoo user mailing list. He's right in the middle of a sentence about how some dude named Richard uses some specific text editor for all the work that he (Richard) does. Meanwhile in the background, a thread within a process springs to life, sensing that danger is imminent. An annoyance filter, but not just any ordinary annoyance filter, has seen the future, and has seen that someone in a bright room, surrounded by lame things like a Windows XP box, and not one, but two copies of Hacking Exposed (First Edition), is about to post to the mailing list with some information not worthy of the annoyance filter's owner's time. A new entry appears in the kill file, and though the owner is not even aware of it, he is now better off for it. A crisis diverted. Twenty minutes later, the owner is still working on something very cool, and is not disturbed when the posting is delivered.
I think what Grendel meant to say was yes, you are correct. try catting
/proc/net/tcp, just for the heck of it. You'll see that both the local
address and remote address are IP:Port pairings, and that's essentially
what the kernel uses to make sure that the incoming data is available to
the correct socket. For an even better understanding of this point (and
not some other mostly irrelevant point like IP forwarding for example),
you can note that the socket API was designed so it could be thought of
as a "generalization of the UNIX file access mechanism for communication"[1], and that you're returned a descriptor when you open a
socket, just like if you had opened a file. Keep that in mind when you
look at the columns of the /proc/net/tcp "lookup table".
I hope I've provided some insight into the issue at hand.
cheers, jordan
[1]: Douglas E. Comer, Internetworking With TCP/IP: Volume 1, Section 22.4, pg. 415.
PS: The subject contain the letters OT, so it's your fault if you read the first paragraph and are pissed off. Your kill filter just isn't advanced enough.
Neal Lippman wrote:
> Thanks. So this would imply, as Jason Stubbs also emailed, that the kernel
> keeps a mapping of the src-ip:src-port pairing to local sockets, so that a
> packet coming in to dst-ip:dst-port can be demuxed to the appropriate local
> process based on the src-ip:src-port information?
>
> nl
>
> On Sunday 22 February 2004 09:12 pm, Jordan Frank wrote:
>
>>hi neal,
>> you may have more than one connection from your computer to the remote
>>system, but you will use a different src-port for every new connection.
>>so say you're ip is 1, and the server's is 2, and the server is
>>listening on port 80, then when you make the first connection, it can be
>>identified by 1:12345->2:80, but then if you make another connection to
>>that same server, it will be 1:12346->2:80, (note the source port won't
>>necessarily be incremented by 1), but now this second connection can be
>>uniquely identified as the source port is different. now, if you connect
>>to a remote server twice using the same source port, then problems
>>arise, but this doesn't happen (your system would try to allocate a new
>>port to send out from, and it would not be assigned a port that is in
>>use). hopefully this answers your question, if not let me know.
>>
>>cheers,
>>jordan
>>
>>Neal Lippman wrote:
>>
>>>I know this is way way way OT, but I figured someone on here could maybe
>>>answer this question.
>>>
>>>I'm trying to understand a probably very fundamental concept in the way
>>>that internet sockets work. I understand that for a TCP socket, four
>>>parameters define the connection, the source and destination IP
>>>addresses, and the source and destination ports, so a TCP socket has four
>>>parameters once the connection is established: src-IP, src-PORT, dst-IP,
>>>dst-PORT.
>>>
>>>Here is what confuses me. Let's say I open a connection from my computer
>>>to a remote website. I create a local socket, fill a sockaddr_in
>>>structure with the remote IP address and port to connect to (call it
>>>remote-IP and 80 for the www port), and call connect. Locally, my
>>>computer's TCP/IP stack will use the my local IP address and will obtain
>>>an unallocated local port for the src end of the connection.
>>>
>>>At the remote end, the http server has, in essence, allocated a socket,
>>>filled a sockaddr_in structure with the local address and port to listen
>>>on (again 80 for www), used bind to associate the socket with the local
>>>IP address/port 80 in the sockaddr_in, and called listen to let the
>>>system know the port it is going to listen on.
>>>
>>>THe server then loops on the accept call, to accept incoming connections,
>>>and when one is received, the accept call returns a NEW socket connected
>>>to the remote host.
>>>
>>>Now, is that new socket's local port 80, or is a new port allocated for
>>>this connection on the server end?
>>>
>>>If a new port is allocated and used for this connection, then packets
>>>arriving on this connection would have the wrong port in them, because my
>>>local program thinks it is connected to port 80...unless the
>>>establishment of the connection returns to me the actual port in use,
>>>which my TCP/IP stack keeps internally. Yet, this doesn't seem to be the
>>>case, because netstat shows the remote port on all open connections as
>>>being the ones I would expect, eg imap2, www, etc.
>>>
>>>On the other hand, assuming that the remote port is still 80 after the
>>>accept, then how does the system demultiplex incoming packets, because
>>>the only identifying info in the TCP and IP headers are src-IP, src-PORT,
>>>dst-IP, and dst-PORT, and so how does it know WHICH connection from my
>>>computer to the server a given port belongs to in order to deliver it to
>>>the correct socket - I may have more than one www connection from my
>>>computer to the remote system.
>>>
>>>Anyone who can provide me with some clarification on how this works would
>>>be appreciated.
>>>
>>>Thanks
>>>nl
>>>
>>>
>>>--
>>>[EMAIL PROTECTED] mailing list
>>
>>--
>>[EMAIL PROTECTED] mailing list
>
>
>
> --
> [EMAIL PROTECTED] mailing list
>
>
>
-- [EMAIL PROTECTED] mailing list
