netdev - Re: any way to let host act as TCP server OR client on same IP/port?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E1F1D3A.1030204@hp.com>
Date:	Thu, 14 Jul 2011 09:45:46 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Chris Friesen <chris.friesen@...band.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: any way to let host act as TCP server OR client on same IP/port?

>> In our case we don't need to actually be connected, just be listening
>> and ready to either accept() a connection or connect() to someone else.
>
> It turns out that the application people really do want the server side
> to be able to listen() at the same time as calling connect() from the
> same address/port, so Rick's testcase was accurate.

So, we are left asking "Why do the application people want that?"  Does 
the server connect() to pseudo-random places, or does it only ever 
connect back to clients which have already connected to it?

If the desire is to have the same well-known port number involved in all 
connections to/from the server (perhaps for simplistic firewall rules 
involving serverip.magicport?) then if the connections are back to the 
clients, the clients could simply open listen endpoints bound to the 
magic port number and the firewall rule become "server IP is source or 
destination) AND (magic port is source or destination)" - assuming the 
clients aren't bind()ing to the magic port number before connect()ing to 
the server.

rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html