Re: GSOC 2017 related info.

[Luis MartinGarcia <luis.mgarc () gmail com>]

Hi Ibrar,

Thanks for your interest in Nping. As you know, a few years ago I worked on
a branch that added quite a few new features and bug fixes. The branch
never got merged because I was sloppy with my commits and failed to produce
a clean set of patches that could be easily reviewed and merged. I did some
attempt to rebase the commits and produce something cleaner (see
svn.nmap.org/nmap-exp/luis/nping-ng/) but it was still considered too
difficult to review and too big to merge into trunk.

I think the bugfixes and features in the branch are worth integrating into
trunk, but it needs a thorough analysis, a clear plan to merge and most
importantly, a very extensive test plan to make sure the branch is not
introducing new bugs (Fyodor did a simple nping scanme.nmap.org in non-root
mode and saw that RTTs were missing, so most likely the branch will have
bugs that weren't present in trunk). Structurally, the heart of the branch
is the new ProbeEngine, which was needed to introduce a lot of the new
features, so it is important to figure out how we could introduce that in
trunk with minimal impact, and then study feature by feature and bugfix by
bugfix, and merge them progressively, making sure Nping remains stable and
no bugs are introduced after each one.

So if you are interested in tackling this work, my recommendation is to
focus on what would be the plan to selectively merge bugfixes and features
(perhaps starting with the simplest patch that can get the new ProbeEngine
in place without disrupting anything) and all the tests that we'd need to
perform to make sure that Nping remains fully operational and bug free.

I am going to CC you on a private conversation I had with Fyodor, David and
Dan a while ago, where they provided feedback about the branch and
explained their concerns. I think it would be useful for you to see the way
they were looking at the issues, so you can structure your proposal taking
their inputs into account.

Also, I suggest you have a chat with Dan to hear his thoughts directly
before putting a lot of work in the proposal. He's the lead engineer and
likely the one supervising this type of GSoC project, so his inputs are key.

Thanks again and good luck!

Luis MartinGarcia.




On 23 March 2017 at 14:12, ibrar arshad <ibrararshad80 () gmail com> wrote:

> Hello dev-team,
>
> I am interested in working on improving nping during Google Summer of Code
> 2017. I have ~3 years of experiencing of working on developing distributed
> systems and virtual network functions and now I am pursuing a masters
> degree from Technical University of Munich. I just want to get guidance
> about my proposal from the dev team.
>
> First of all there is the matter of the dev branch(http://seclists.org/nma
> p-dev/2012/q4/276) which contains several enhancements/fixes. The latest
> change to that was made in 2013 and I believe the branch hasn't been merged
> in to the trunk yet. Has it been? I plan to start merging patches from that
> into trunk one by one and removing conflicts along the way and add tests
> for the change-set introduced in every patch. Any alternatives or
> suggestions here?
>
> After merging the topic branch into the main branch, I will proceed
> further to reproducing and fixing bugs on top of that. I was looking at
> the currently open bug-list(https://github.com/nmap/nmap/labels/Nping)
> and have shortlisted a few without any associated code or plan-to-fix yet:
>
>    - 180 <https://github.com/nmap/nmap/issues/180> (replace
>    gettimeofday() calls with alternative monotonic timestamp calls):
>    - gettimeofday is prone to skewness by NTP syncs so instead, system's
>       own monotonic clock should be used to generate timestamps for comparison
>       where needed. Finding a portable way of generating monotonic timestamps
>       across platforms is the only major challenge. Some implementations have
>       already been mentioned in the ticket? Further suggestions on how to go
>       about it?
>    - 729 <https://github.com/nmap/nmap/issues/729>(Nping: Handle sending
>    IPv6 on Windows without manually setting addresses). Two issues here:
>       - Don't try sending raw packets on windows systems and enforce
>       sending of ethernet packets by default on a windows system. Can be done
>       fairly easily by examining the code around the routine/s that generate the
>       packets.
>       - When using --send-eth, don't ask for v6 addresses and mac
>       addresses. Rather, derive these from existing functions and helpers.(again
>       needs digging into the code)
>    - 458 <https://github.com/nmap/nmap/issues/458> (traceroute mode for
>    nping)
>    - I think this can be done by examining response icmp packets. I think
>       maybe the use-case needs to be refined here a bit? Any suggestions?
>    - 361 <https://github.com/nmap/nmap/issues/361>(nping should show
>    latency distribution)
>       - Perhaps per probe stats can be maintained and visualized using
>       something like gnuplot <http://www.gnuplot.info/>?
>    - 360 <https://github.com/nmap/nmap/issues/360>(Unrealistic Min RTT
>    (with --rate))
>       - The root cause analysis has been provided in the ticket. Code
>       needs to be probed for a solution.
>    - 278 <https://github.com/nmap/nmap/issues/278>(Audit/change use of
>    unsafe str* and *printf functions)
>       - Required replacing unsafe string functions with safer ones. A few
>       that need replacing are mentioned in the ticket. Code needs to be probed
>       for further non-safe usages.
>    - 125 <https://github.com/nmap/nmap/issues/125>(fix TODO and FIXMEs)
>    - A quick grep into latest code revealed around 32 of TODOs and 8
>       FIXMEs. Needs delving into the code to fix.
>
> I have listed an overall approach towards merging the code from the topic
> branch and fixing these and other bugs that may arise. I'd request for
> feedback around this rough proposal in order to improve it. Should I dig in
> deeper and figure the code details in order to make a convincing proposal?
> Should I include the details for every bugfix or improvement I intend to
> make to the tool? Also there is a todo list for nping related tasks(
> https://svn.nmap.org/nmap/todo/nping.txt), can somebody confirm if its up
> to date and if the tasks marked done are part of the main branch? Also, are
> these still valid after the code changes available in the topic branch?
> Thanks.
>
>
> --
> Ibrar Arshad
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/