Re: Nsock unconnected sockets

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/04/2010 10:18 PM, David Fifield wrote:
> On Mon, Oct 04, 2010 at 09:17:07PM -0500, Kris Katterjohn wrote:
> > Well, given that scripts shouldn't be connecting multiple times (which leads
> > me to believe there should be one connect() for each new_socket()), then a
> > possibility is this:
> >
> > s = nmap.new_socket(<protocol>, <optional family>)
> > s:connect(host, port) -- remove/deprecate protocol arg
>
> This has a little bit of a problem, though, which is the address family.
> Currently you can do
>
> s = nmap.new_socket()
> s:connect("::1", 80)
>
> and it will work fine. If OS socket creation always happens when
> new_socket is called, then it becomes necessary to declare the address
> family in advance (even if implicit). Consider that someone may give an
> address in a script argument--then it becomes necessary to analyze its
> address family before calling new_socket.

Ah, good point!  But isn't this also a problem with setup/sendto if you send
to a user-given address?

> Another thing to consider is that at least one function, bind, needs to
> be called before the socket is connected.

Sorry, but I'm not sure how this would be an issue.

new_socket("tcp")
bind("192.168.10.69", 31337)
connect("192.168.10.1", 80)

and

new_socket("udp")
bind("192.168.10.69", 31337)
sendto("192.168.10.1", 53, "stuff")

How would these not work?  I suspect something may have to be moved around,
but are these really not possible?

I remember when I wrote the set_localaddr function in Nsock I had to save the
data for when the socket was connected (and I think I recall reading this was
being changed?).  So after the socket is created with new_socket(), couldn't
the address be binded to immediately (if its not done currently)?  And even if
not, how does creating the socket before the connect() affect keeping the
local address information and setting it in connect()?

If I've just been away from some of this code long enough for my suggestions
to be totally off-base, please tell me :)

> I expect that connected sockets will be used far more often. So it makes
> sense to make the shorter and simpler code favor that. Having an extra
> line for an unconnected socket is a tip-off that something unusual is
> going on.

Well, yeah, that's true.

> > A socket just created with new_socket() is (I think) essentially useless until
> > you connect it or "setup" it, so I'm not sure we're losing much in that.
> > Scripts should know what protocol they want to use by the time they call
> > new_socket() anyway.  For example, scripts shouldn't call new_socket() and
> > immediately pass it to some function for connecting when the function can
> > create it itself (I'm trying to think of any reason why new_socket() calls and
> > connect() calls may legitimately not be in sync).
>
> The argument against immediate connect/setup is that it leaves no chance
> to call bind or set_timeout. I suppose these could be made into
> additional arguments to new_socket.

Again, I'm not sure how bind and set_timeout are affected as you say, but when
you say "immediate connect" I think you may be mistaken about what it is I'm
suggesting.  My last email shows connect() following new_socket(), which would
(should!) allow for bind() and set_timeout() to be called and properly used.

> David FIfield

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMqqMtAAoJEEQxgFs5kUfu6lUQALGCi7wAAM8piGFOA2/cqkGp
WqiaxGUpR9fkoqtgwsukRaqjD80eLOd8hH+cdlCCTyTIsHX+OfOKcfYX6uoWsfKh
PkRH09S7dc5ebGEJ/Bzy4afkPqoQJEI92l2feyvYzDJ6PYhnAc0qDO4zg3OLBBNO
YzYmdkcK3yXaFEpNXjJ/iGLORzl48LC7opzWzPAIhpi4IrQflsjyHixO0tSd6coj
4uearU7EdibjiTcIljn4dfPJIoUqd1hj9CiA07YTuOmejcn33FPx0/XM3F40LuqW
Hbcel2QnT0zqYjasMeh4EGBXvDz/KLAImsDVLh8pIRzQCoMicf5k12KAyvsv0hxr
d46toBjl7kJuaBmdnAVPf545u6e5ac+RWm0lhxifpYZC+dXwm8wCRAYDlX4/UnLw
2vOPhnIW/mvlkNHc2iQV6gsr1ncUBXwKcRoMgweUKQuZM/hnCh4a2fXPvH1lPZDP
QJ1v1BPqX/wQ8G51TQHrVrt9DmW9qz3fFeN42cofs4DcJ2ye3U4diyOzSmmnlGUP
i3iuc3KoMhckr5KjR3xTH5vYl4QS1Q+qdLPWiMtu1V4oLZxL1xaasHh6GWLjhrSc
u7XdNZgjf5aUQtoYN++bXudzFh3Yk4UVdoNgqDNGnuRvTeOEkLcOlJUdYjFf/fA+
ML1mzpTIZMsgDdkNXiHk
=18Ff
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/