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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ