Sent a mail to Dan regarding the --ignore-after thing. I was right that it should be >= for both the integer and percentage check.
Working on the --ignore-after option.
Will commit the TTL thing.
//TODO
Worked on the --ignore-after option.
Dan summarized the changes for --ignore-after on the list. However, I think some changes might be needed. Will talk to him about it.
Got green signal on list to commit the TTL patch.
Worked on --forget-after option.
Had a meeting with Dan today. Discussed about TTL patch. Will be committing the current version of the patch and be leaving a lot to work on later. Discussed a lot on --forget-after which will now onwards become --ignore-after.
Worked on the --forget-after option.
Patrick gave another idea for the intensity for NSE version scripts thing. See thread. Don't think I'll be implementing it that way however.
Dan has given a long reply for the TTL patch. See thread. Will need to discuss this with him in the next meeting.
Submitted the Intensity for NSE version scripts patch onto the list.
Worked on and submitted the Showing TTL in default output patch onto the list.
Cleaning up nmap.version_intensity() code. Testing the full feature.
Whoa! The problem lied in a stupid spelling mistake in the testing! I was using script-intnsity from Nmap's CLI instead of script-intensity. Not a syntactical mistake so never got caught. If only I had rewritten the command once instead of using bash history.
Cleaning up the code (for nmap.version_intensity()) to work nicely.
Submitted weekly report 8.
Travelling to Roorkee today. Will work on the flight etc. Hopefully rooms are allotted when I reach.
Started to read up on a lot of LuaAPI. Will be using it to code in nmap.version_intensity() so that it automatically uses script-intensity script-arg whenever it can.
Have come up with a rudimentary idea but for some reason the tests aren't working. Will need to debug.
Rooms were not allotted. Took up too much time to get anything (just to sleep for 2 nights until they allot rooms on 15th.
I tried coding in the script-intensity with version-intensity thing as a thing under nmap.version_intensity() and nmap.intensity but it doesn't seem that clean to me. Will look into it further.
Working on the --forget-after option, I've come up with something. But I think I'll stall it for now.
Working on the script-intensity thing, I think that adding a rarity field might be nice.
Had a meeting with Dan today. Lot of discussion on whether rarity variable should be added or not. Will decide later; but I think I'll be submitting both with and without rarity since I've already written the code for rarity.
I can work on showing TTL with --reason -v or with -vv later on.
Dan also had an idea for capabilities for unprivileged user. Will look into it later.
Committed the documentation for --data and --data-string as revision 33212.
Working on the --forget-after option based on Fyodor's inputs.
Back from Goa! My inbox has crazy loads of mails unread right now (just coz I missed a couple of days)!!!
Sent in weekly report 7.
Worked on improving the Zenmap Topology Noise patch. Submitted a modified one to the list which now maintains info about number of hops.
Fyodor said that I should probably modify the documentation for --data and --data-string (let the user know that the comments will usually never be read except in rare cases). Made the modifications and sent it back. If no objections, I will commit in the documentation tomorrow.
There is discussion with respect to a --show-ttl option on the dev list and IRC. Maybe I can work on this.
Submitted the OS detection patch.
Found out that the trip is a day longer than I initially assumed it to be. Cannot work on 5th, 6th, 7th and 8th of this month.
Added the --exclude-ports option to Nmap trunk. Committed as revision 33161 and 33162.
Still have some tiny modifications to make to the patch to clean it up. Will submit to dev-list by night probably.
Have a meeting with Dan today. Should discuss about the next thing to do (script intensity).
Corrected some typos in portlist.h. Committed as revision 33160. We are approaching r33333 fast. Hopefully it doesn't get used up in the time I am not here (5th to 7th of this month).
Had the meeting with Dan. Discussed quite a bit. Read the log for details.
Added the OS detection when "tcpwrapped" thing to the todo list
o If Nmap uses a "tcpwrapped" port to do fingerprinting on, OS detection
might give false matches/results. Since it doesn't really matter which
open port gets chosen, we should move onto another open port if we
notice "tcpwrapped".
Finally seem to have got everything working smoothly with the patch. Will run a few more tests and then maybe submit to list tomorrow.
The start of a new month!!!
Set up a few VMs for testing the OS detection when "tcpwrapped" thing. I've also almost worked out the patch for it. Most tests seem to work fine but some of the VMs are just not accessible at all. Donno what is wrong.
Committed the MemoryError Catching patch as revision 33140. Finally!!!
Modified and added more stuff to the Memory Analysis of Zenmap. Sent in to mailing list. I will be committing it in tomorrow if there are no objections.
Tried setting up a testing scheme for the OS detection when "tcpwrapped" thing. scanme.nmap.org is too many hops away. Talked to d33tah about it. Will have to set up my own thing at home (maybe use VMs).
Sent in weekly report 6. Also mentioned that I will be submitting next report a day late.
Started to learn some of Lua's subtleties.
Analyzed a possible way to work on the OS detection when tcpwrapped thing. Still need to come up with a valid testing setup to test the usage of the change.
Committed the Zenmap Terminal Interaction patch as revision 33106.
Worked on the documentation for --data and --data-string options in docs/refguide.xml.
Analyzed Zenmap's memory usage further. Put results into Analysis.md.
Dan will look into all the stuff that I've posted already. Currently, I'll work on documentation (for the features that I've added). Next, I'll work on a problem with OS detection when a port is "tcpwrapped". Will look into the script intensity thing later after getting more familiar with Lua and NSE. As for the Memory Analysis of Zenmap, I should sample memory even after the message is shown. Also, I should put raise MemoryError in some places and see if saving files works (to show that it isn't caused by the patch).
Worked on and sent in a modified patch for the Zenmap Terminal error.
Some crazy problem with the spam filter blocked my patch. Resent.
Worked on a IRC bot "NLog". Seems to be in working condition now. Deployed onto #Nmap now. Will see how it works.
Went for driving test to get my Permanent Driving License. Couldn't work a lot on Nmap as a result.
d33tah sent a error report for a race condition on IRC. Need to look into it later.
Adding a "show only hosts that have all the specified ports open" NSE script might be nice. Could work on this later (if someone else doesn't work on it).
Completed and sent in the analysis for Zenmap's memory usage.
Had a discussion on IRC related to badly named output files (such as those caused by commands like nmap -oX -sV abc.xml). Wrote a patch and submitted onto the list. Committed as revision 33074.
Submitted the --forget-after patch. This is an experimental un-"planned" patch.
Continued working on the Zenmap Memory Analysis. Will probably post results of that tomorrow or day-after.
A discussion of SYN+ACK with bad checksums occurred on IRC today. My suggestion was to rescan any bad checksums to rule out environmental noise. If we do get bad checksum again (highly unlikely in normal situation) then we can assume that some machine is maliciously trying to disrupt Nmap.
Sent in weekly report 5.
Will write the Mid Term thing.
Worked on figuring out how much memory is used in Zenmap by looking at peak memory usages. Most of it is there in the GitHub repo.
Most tests pass. The ones that don't are because I'm unsure of how Zenmap should respond in such cases.
I still need some feedback on how to go about for some cases. Uploaded patch onto dev list and asked for feedback for the same.
Worked on the parallel anonymous hops thing in Zenmap.
Had a meeting with Dan. Discussed on what possible corner cases might be there for the above. Discussed what I can work on next (read logs). Also looked into the terminal tty problem.
Seem to have worked out parallel anon hops thing completely. May need some further testing.
Seems like the port exclusion misses host discovery when --top-ports is used. This is caused since I added a line that doesn't do port exclusion in some cases. Removing this line makes it work fine again.
Dan sent a mail which details possible ways to work on reducing memory consumption in Zenmap.
Sent in the modified patch for the --exclude-ports option.
Got rid of unnecessary spaces in blank lines in all *.cc and *.h files. Committed as revision 33038.
Modified the code to allow getpts() accept input even when -sn is called. This should not affect -p since -p is not allowed when -sn is used.
Modified the code so that the subtractions work fine.
I've added some warnings for host discovery so that for example, if TCP Ping is requested but all TCP ports are blocked (or 80,443) is blocked, then warning is shown.
Submitted the patch for review.
I think I've identified the changes I'll need to make to make host-discovery work fine.
Host discovery seems to not be affected by --exclude-ports even after the changes. Maybe getpts() doesn't give me anything if I have run Nmap with -sn.
I may have to rewrite the port subtraction to make SYN_PING get subtracted by TCP, ACK_PING get subtracted by TCP, etc.
Realized that I can speed up the --exclude-ports option and also get rid of the sort() that I needed to do. Will probably have list submitable code by tomorrow or day-after.
Still looking into the host-discovery thing.
Submitted a patch to make Zenmap close Nmap more nicely. This allows for terminal interaction to be proper.
Sent in weekly report 4.
A bunch of mails related to errors in Zenmap have popped up. Seems like they might be related to the changes I made but I cannot seem to reproduce them. I sent a mail to Dan to ask if I should send a mail to the OPs to ask for steps to reproduce.
Received a mail with a green signal for --data and --data-string options. The hex code need not be put into Nbase. Reasons are there in the email.
Received a reply from Dan saying that the bugs are fixed in SVN which is why they cannot be reproduced. He's sent private replies to them (that they should either use SVN instead of release or add the patches in manually).
Committed the --data and --data-string options as revision 33014.
I should probably update the CHANGELOG.
I need to write up some documentation for the features (--data and --data-string) in docs/refguide.xml.
Updated the CHANGELOG and committed as revision 33015.
Rewrote parts of the --exclude-ports option code to make it more readable.
Looked into how host discovery works. Currently no error is thrown for nmap --unprivileged -sn -PE -PP which is same as nmap --unprivileged -sn --exclude-ports 80,443 for which there are no available probes to run discovery. It gives host is up in all cases then (giving reason as "received user-set"). Should probably look into this.
--exclude-ports give a segfault!!! I think I might have messed up something related to dynamic memory allocation.
I tested Henri's patch for slightly larger files and it still runs marginally faster. I will write up a mail explaining this later on.
Had a meeting with Dan. Discussed how exactly I'm working on --exclude-ports and that I think I've fixed the segfault. I need to look into host discovery too. --exclude-ports should really exclude all ways.
Seems like my stance on the --exclude-ports thing is fine and I can start coding it in. Have started.
I'm considering one of two methods now to code it in. Will see which one is better/easier and then do it.
Currently, I'm coding in the parts that are common to the two methods. By tomorrow, I'll decide on the better technique and then start that too.
Henri has sent a mail. I've looked into the patch and it does run faster for smaller files. However it should probably run slower for larger files (due to asymptotic complexity); but I need to test to be sure.
Dan and Fyodor have send some replies to the RFC mail related to --exclude-ports.
I put up a question on Stack Exchange in relation to how Nmap should behave when --exclude-ports and --top-ports are used together.
I sent a mail detailing use cases that explain why my stance for the above is correct.
Received a mail from the original author of the patch that removes one anonymous hop saying that now, the patch file in the original mail is no more "403 Forbidden".
Started to read through the patch for the anonymous hop thing.
Looked into possible ways to code the --exclude-ports option.
Seems like the speed up patch broke my MemoryError patch. Turns out, some places in the code were using nmap_output is not None which would always be true with the new speeded up version. This is what cause the error message to not appear on screen. Changing the code to nmap_output != "" makes everything work fine now. Committed as revision 32985.
Henri Doreau commented on r32985. He says that PEP-0008 says, "For sequences, (strings, lists, tuples), use the fact that empty sequences are false."
Changed if nmap_output != "": to if nmap_output:. Committed as revision 32986.
I have started to come up with a prototype for the --exclude-ports option but now feel that I should probably come up with some test cases first; atleast until Dan sends a reply to yesterday's mail.
I started to look into the thread named "Reduce zenmap topology noise (patch)". The older part of the thread is here.
Committed in a patch to speed up zenmap's file opening routine by orders of magnitude (r32983). Large scans now open in seconds instead of hours.
Send in a followup patch for the speed up thing that conditionally uses cStringIO instead of StringIO whenever possible. Gives a 10-15% increase in speed.
Committed in the follow up patch.
Started looking at the --exclude-ports option thing. Found a patch by Chris Woodbury that adds the option but it seems to have some flaws. Reading through Nmap's code shows that the patch needs to be much more intrusive if we want to be able to satisfy everything in the RFC Discussion. I've sent a mail to Dan about this.
Wrote an experimental patch for a --forget-after option that allows users to stop looking at a host once X number of ports are found open. Experimental because not sure if it breaks anything. Further testing will allow me to be able to put this patch on the list. I could post the patch, however as a response to the Portspoof IDS trouble mail, strictly marking it as experimental and see what it leads to.
Sent in weekly report 3
Fixed the slow opening thing. Had to modify some parts of the code to be able to use the new StringIO object without trouble. The refactoring was needed since nmap_output is a property and has getter and setter defined, but is not used consistently. Some places use _nmap_output directly instead.
Submitted in the patch for the slow opening thing. Should probably get committed soon.
Fixing the "Cancel Scan" MemoryError involves adding in a different error message to the error message function. Modified the code to make it look more nicer.
The slow file opening this is caused by heavy use of string concatenation. Python is slow at string concatenation. (Python takes O(A+B) time to concatenate two strings of length A and B). This makes the whole algorithm quadratic. A better thing to do would be to use StringIO. A comparitive study says that this might be the best thing to do.
Sent in the MemoryError catching patch.
Turns out that the change in the configure script done in r32919 (to add randomization to ASCII art) would be overwritten next time someone ran autoconf. Changed configure.ac instead and ran autoconf 2.69 to regenerate configure. Committed as r32965.
Got reviews related to libpcap update patch. Seems like patches NMAP_MODIFICATIONS/0003-*.patch and NMAP_MODIFICATIONS/0004-*.patch have already been handled upstream (not the patches actually, but the issues are rectified - differently). Other than that, patch seems fine. Committed it in as r32966.
Upon running ./configure, there are two new files generated in the libpcap/ directory. These files need not be there in SVN, so added them to svn:ignore.
Got some comments on the --exclude-ports option thing. I wrote a clarification email that explains exactly how the options -p and --exclude-ports interact (by using examples).
I have a meeting with Dan today. I'll be discussing the --data option Mini Project as well as the Zenmap MemoryError one. I have some other project ideas in mind for the future. I will discuss these as well.
Bonsaiviking (paraphrasing): Parkinson's law of triviality says that the most trivial thing in the MemoryError patch (the error message) is what will generate the greatest discussion.
We can look at translatibility of the error string later (if needed, since if we fix the MemoryError itself, then we won't need it).
Will start to work on the --exclude-ports option thing soon.
Whoops! One of the tests for the MemoryError thing failed. Pressing the "Cancel Scan" button causes a MemoryError. I had caught this before, but I had later removed the try-except wrap since I felt it was unnecessary. Will fix this tomorrow.
Testing opening large scans, it takes way too long to open. Using Dan's progress.sh script, I can see that the file open is actually so slow, it'll take hours to complete. And this is with a scan that took 30 seconds to run and 1 second to save!!!
Found out about pv command. Need to look into this and use it more.
d33tah gave a "Protip": cat /proc/`pgrep zenmap`/fdinfo/9, where 9 is the fd number for the file being opened.
Did a little more testing of the MemoryError fixing patch. I may be able to post it on to the Dev list maybe tomorrow. A few final tests need to be done so that I'm sure that I've not missed anything. I also need to make sure that I have handled only the cases that need handling.
Turns out that Dan had misunderstood the libpcap patch. Explained to him that it was a diff of a diff and that's why I'd written the shell script. Maybe by tomorrow, the patch's review will be done and I can commit it in.
Checked out a clean copy of the code and ran some tests. Turns out Dan's code for go_to_host causes a problem if you click on a host which is not there in the scan (i.e. a host from a different scan).
Modified Dan's code and committed it in as r32939.
Seemed to have found key places in the code to put try-except blocks. Need some more testing.
Testing is a pain in the a$$. The command that I've been running until now takes WAAAAY too long to complete. I've talked to Dan about less time consuming commands which generate more output. Seems like I may have to use -d9. The command that he gave doesn't work directly, but a modified version does. The modified command is nmap --packet-trace -r --top-ports 1000 127.0.0.1/24. I think I can put a -T5 also in there but I'll do this tomorrow. Way too sleepy...
I think that saving and opening may also work now. Need to see. Also have to test printing.
As for the try-except being used now, it spans too many commands. I need to see if I can make it span lesser commands and that way, not unnecessarily catch too many errors.
Continued to analyze Zenmap. Turns out that lots of other stuff gets affected.
Clicking on Hosts on the left panel causes a problem. Trying to save causes a problem. Trying to print causes a problem. All this makes me think that even trying to open a file with large Nmap output would cause a problem.
I think I should clear out everything and start again: analyze the key points and modify only those.
Talked to Dan. He updated the NmapOutputViewer.go_to_host to be more efficient (use less memory by using iterators and iterating over the buffer). I have a feeling that there may be a bug in the code but this may be caused due to my modifications too.
Further analysis shows that it may turn out to be too big a thing to modify the way Gtk.TextBuffer is used in the program. The problem is too spread throughout Zenmap.
Maybe I can just catch the error; stop updating the Nmap Output display; and show the user that they should either use only the other parts of Zenmap or they should run the command at terminal. I tried to do this, but even this is not really trivial.
Need to read through more code in order to figure out how much this may actually affect other stuff.
Sent in Weekly Report 2.
The start of a new month :)
mmap may not actually be useful (esp. on 32 bit systems), is what some reports on StackOverflow etc. say.
One way to reduce memory usage may be to prevent word wrapping. Need to see if this reduces memory problem. I know it doesn't remove the MemoryError but it seems to allow for more input to come on screen before crashing.
The problem may lie in Gtk.TextBuffer storing the whole thing in memory. Maybe rewrite some parts of it or fill it up with \n for all lines except those on screen (and some on both sides). StackOverflow has something to say on this (though not much.)
Made 2 commits
- "Add randomizer to configure script so that a random ASCII art from docs/leet-nmap-ascii-art*.txt is printed" as revision 32919
- "Correct the Target MAC Address in Nmap's ARP discovery to conform to what IP stacks in currently popular operating systems use" as revision 32920
Started to analyze how to do the file-backed paging thing for Zenmap. mmap looks promising but I'll have to look into it properly to see if it can be used.
Almost conclusively proved that the problem in the Zenmap MemoryError thing lies in the Nmap Output tab itself. Generated XML files (from Nmap) imported into Zenmap cause no problems but same command in Zenmap causes MemoryError if output size is too large.
Had another meeting with Dan. Discussed on how I can go about with Zenmap's MemoryError. Also discussed on some past patches.
- [Zenmap] Memory error: There seem to be multiple ways to go about it
- Catch the error at the function that causes the problem
- Simply disable the normal output and let the scan complete using only XML output
- Keep the output, but strip the sytnax coloring portion
- Investigate a file-backed paging solution - This is what should probably be done
- Write Nmap's output to a temp file and page it in through the viewer
- To remove the problem of REALLY huge output, we keep a limit on number of lines in memory and we page in only the necessary part
- Bonsaiviking: There are probably "standard" or at least documented examples of how to do this out there
- libpcap update patch: Dan spoke to Fyodor and he is in favour of accepting the patch if all looks good
- Further discussion on 3rd party libs etc. should probably happen on the dev list even if patch goes in
- --exclude-ports option: Should start a discussion on the dev list since it'll have design implications
- How does it interact with -p, --top-ports, and -F (which takes precedence)? Specifically, how many ports does
--top-ports 100 --exclude-ports 80scan? 100 or 99? - Should there be a 1-letter flag for it, and what should that letter be?
- Worth posting as an [RFC]-tagged message.
- How does it interact with -p, --top-ports, and -F (which takes precedence)? Specifically, how many ports does
- ARP patch: Has been up on the dev list for 3 days without comment (other than Dan's), so I should commit it in.
- --data options patch: Dan will do some testing soon. Can expect a comment on that early next week.
- Will have to modify docs/refguide.xml
- Dan will put a comment on how to do that in his email
- Will have to modify docs/refguide.xml
- ASCII Art Patch: Looks good. Dan will send a follow-up message so that the commit doesn't catch others off guard. Can commit after that.
Seems like I have a hackish way of using memory_profiler with classes. May have to use this method or look for other profiling techniques.
For now, I cannot seem to find any place where the problem might be. I think that the scrolling window thing is actually a red herring itself.
Received some feedback on the ARP Ping patch. Seems like the MAC address doesn't matter and that Solaris even uses ff:ff:ff:ff:ff:ff. However, since most common OSes use 00:00:00:00:00:00, it may be better to conform to this. If there is no objection by tomorrow, then Dan will give me the green signal to commit it.
Read through quite a bit of Zenmap's code.
Looked through other different ways to profile memory in python. This way, I can find leaks in memory (if any). There is a problem with memory_profiler when we use classes but I may be able to figure a way around that.
Uploaded the arp ping patch. Will wait for reviews on that now.
Should probably get a green signal for the scan comment (data and data-string) patch by evening. Will commit it in then.
Have to send in a mail reminding about the KRAD Ascii Art.
Have to start to code in atleast some prototype for the Zenmap memory error thing. May start by figuring out if linux has any way to limit memory for a process or process group. (Maybe look at ulimit? Not sure yet.) This way, I can force a MemoryError to occur even for small scans. Maybe this'll give some sort of idea as to where the problem is.
I can also start to read through dev list archives to see if I find something. Chances are, I won't.
Turns out that ulimit is not good enough but softlimit is. I can reproduce the bug now on my Ubuntu 14.04 using softlimit -a 800000000 zenmap and putting nmap 127.0.0.1/24 --packet-trace -p- -r as the "Command". It takes a while but after that, it crashes with MemoryError.
I have also started to use memory_profiler module with Python so as to be able to pinpoint the source of the problem. So far, nothing seems to be the problem. Maybe I just have to dig deeper into all the function calls (related to the bug obviously). The problem may lie in the scrolling thing but this may as well be a red herring.
Did some more testing of the arp ping thing. All tests seem fine. Nmap just becomes more "stealthy" so trivial discovery of Nmap's scans cannot be done.
Continued to read more on Python and error catching. May be able to start to start working on something for Zenmap tomorrow, or the day after.
Seem to have figured out the arp ping thing. May have to do more testing before I put on the dev list.
Noticed that the Makefile generated at nsock/tests (after running a ./configure is not ignored by svn). Made a commit to add it to the svn:ignore list.
Tried using vagrant. Seems a bit too unwieldy to use. I think I'll stick to normal virtualbox instead.
Read up a bit on errors in Python.
Started to look into arp pings. Read up on how the packet is arranged for arp requests.
Committed in a small indentation problem that was there in nping/utils.cc
Worked out the --data and --data-string options for Nmap using some hex handling code in Nping. Put it up for review.
Had meeting with Dan to discuss what to do next. The plan for further work is to work on the MemoryError in Zenmap (that seems to be the most pressing issue right now, atleast on the dev lists). This part will be in python, so I'll have to learn/relearn errors and how to catch MemoryError etc. Another thing to work on is the thing at http://seclists.org/nmap-dev/2011/q3/547. This is more of a C++ one where I'll have to dig deep and find out where the thing is caused.
Wrote some small scripts to make it easier to code and read code.
Tomorrow's plan should probably be to set up a nice VM where I can test for MemoryError. Maybe the Vagrant thing from yesterday might be useful after all.
Committed one patch yesterday. Turns out Dan went offline only for a short while. Committed in the OpenSSL "--ssl" option one. Also added to CHANGELOG. Revision 32873 with commit message "Fixed a bug which caused Nmap to be unable to have any runtime interaction when called from sudo or from a shell script".
Committed in one patch today. Revision 32881 with commit message "When Ncat is compiled without OpenSSL and if --ssl argument(s) are given, then show error message that OpenSSL was not compiled in."
Set up a meeting with Dan for tomorrow. Will discuss the plan for the week.
Finished up the libpcap patch as a script+patch. Should write it in the formal log properly now.
I also put up the idea for discussion as to whether we should continue putting 3rd party libraries with Nmap. Will see how that goes.
Found out about a new thing called Vagrant. Is a nice virtual machine handling thing that may be worth looking into for some other stuff.
Started to look through the nmap private svn directories. Found some pretty nifty stuff. Will have to see how I can incorporate atleast some of these later on.
Read through a lot on info and documentation about SVN and git-svn. Seems like I'll use SVN for a week and then git-svn for the next and then see which one is more useful.
Just got a green signal for two patches that I've to commit in. I've asked Dan to tell me if my procedure is correct and once he says yes, it is committed! Will commit in tomorrow morning most probably since Dan is offline right now. The two patches are the "--ssl without OpenSSL [Ncat]" and the "Runtime interaction bug while using sudo" ones.
Took a look at Dan's bug/issue tracker system. Got some small hiccups but looks very promising. Hope to be able to work much better with that.
Seems like the scan comment patch can be better designed. A better naming would be "--data " and "--data-string ". This should be incorporated into the patch for now. As a follow up to this feature, testing with IPv6 and adding support for Jumbograms may be done because warning about data length > 1400 is needed only for IPv4.
Got some comments on the ideas list I had sent to Dan.
The user id and password now work on the book access online.
Have written a script that does the updating libpcap thing properly. I still need to test some more before putting it on the list. We need to consider the question, however, that "is it worth spending time updating 3rd party libraries like this?" Quoting Dan, "The basic question is, should we bundle readily-available third-party libraries with Nmap? Sometimes we need to make modifications; sometimes (like liblinear) the libraries are not readily available; but we don't want to get into this problem of needing to keep them updated all the time!". This is something to look into and probably bring up on the list.
Saw that Fyodor has sent a HUGE number of mails in the SOC list. Read all of them but some need one more read maybe.
Got to start refreshing my SVN and GIT skills so that I don't get stuck later on in GSoC. This should be highest priority for now.
Dan has replied to the ideas. Seems like committing in some of my patches is infact what I need to do right now after waiting for some comments. Maybe the refreshing SVN and GIT skills will occur faster due to this.
Come up with a (possible) fix for the --ssl without OpenSSL thing in Ncat (was there in the todo list). Need to get some feedback. Made some assumptions which hopefully are fine.
Looking at an old species of libpcap which should've probably evolved to a newer form by now. Will review why the patch I had given is not as effective. I have a feeling that it is due to the fact that it is waaaay too long. Guess I will rewrite it in such a way that it becomes a very short script that just needs to be run.
Started to write a formal log of all the miniprojects that I'll work on for GSoC 2014.
Decided to write Dan a mail with the ideas for (possibly) next week. Will start working on (atleast) one of them tomorrow.
Need some rest after the previous hyperjump.
Continuing to read through the code. Warp speed ahead.
Rewrote the patch using ideas from the source code of Chirp. Seems to work fine with any tests I throw at it. Submitted to nmap-dev list. Waiting for feedback.
Patrick says that the patch looks okay. Dan says that he'll take a little time to test it and then will commit possibly on stardate 2014-05-19.
Patrick says that exit is not "async-signal-safe". Will have to figure out some new way of handling the problem with SIGINT. The problem with keyboard interaction is fixed with getpgrp instead of the getpid.
Submitted a patch to try to fix the problem with runtime interaction when using sudo. Unsure of the security risks that lie in doing a simple exit(). Will wait for further developments in this.