Nmap Development mailing list archives
Re: Nsock unconnected sockets
From: Kris Katterjohn <katterjohn () gmail com>
Date: Mon, 04 Oct 2010 23:01:50 -0500
-----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 argThis 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/
Current thread:
- Nsock unconnected sockets David Fifield (Oct 03)
- Re: Nsock unconnected sockets Kris Katterjohn (Oct 03)
- Re: Nsock unconnected sockets David Fifield (Oct 04)
- Re: Nsock unconnected sockets Kris Katterjohn (Oct 04)
- Re: Nsock unconnected sockets David Fifield (Oct 04)
- Re: Nsock unconnected sockets Kris Katterjohn (Oct 04)
- Re: Nsock unconnected sockets David Fifield (Oct 05)
- Re: Nsock unconnected sockets David Fifield (Oct 09)
- Re: Nsock unconnected sockets Kris Katterjohn (Oct 10)
- Re: Nsock unconnected sockets Ron (Oct 14)
- Re: Nsock unconnected sockets David Fifield (Oct 15)
- Re: Nsock unconnected sockets Patrik Karlsson (Oct 15)
- Re: Nsock unconnected sockets David Fifield (Oct 04)
- Re: Nsock unconnected sockets Kris Katterjohn (Oct 03)