flowgrind/flowgrind — pull request #176 by kramudhan (2014-11-03 13:19:37+00:00)
Title: Fix for Segmentation fault in controller due to daemon wildcard IP address binding

Test case:
1. Consider node M1 has 3 Ethernet interface M1a, M1b, M1c and Node M2 has 3 Ethernet interface M2a, M2b, M2c.
2. Daemon D1 running in M1 and D2 running in M2.
2. Run the controller C with first flow option, -F 0 -H s=M1a,d=M2a -F 1 -H s=M1b,d=M2b -F 2 s=M1c,d=M2c and second flow option -F 0 -H s=M1a,d=M1b.
3. Both flow option results in the segmentation fault in controller.

Problem:
1. Running the daemon without binding to XML-RPC server bind address(flowgrindd -d), binds daemon to the wildcard address (0.0.0.0) for RPC communication between daemon and controller.
2. The report matching in controller report_flow() depends on comparing report ID and flow ID, and also comparing daemon RPC URL connection string.
3. When C asks for source report in M1 for source M1a, then daemon D1 generate reports of M1a, M1b, and M1c and report it to C. This is because daemon D1 is running in wildcard address in M1 for RPC communication.
4.This is the same scenario in local host condition also. Single daemon generate report for both source and destination for 2nd flow option.
5.When C asks for destination report in M2 for destination M2a, then Daemon D2 generate reports of M2a, M2b, and M2c and report it to C1. The same scenario as explained in the step 3.

Bug:
1.Considering daemon and controller RPC URL connection string for M1a report as a comparison to ​​match exact report became irrelevant, because daemon D1 generating reports for M1b, M1c irrespective of request made to it to generate report for M1a only.
2.The present controller can't distinguish reports based on PRC URL connection string between daemon and controller. So in this case, controller fail to distinguish the reports.
3.The controller write invalid data in intermediate result and case segmentation fault in final report.

Fix:
​1.Best approach to this issue is that daemon giving it's own binding address along with other metrics​ report to controller, so that controller able to distinguish the reports based on it. But the problem also comes in this case.
2.For example, let us take this flow option for controller -F 0 -H s=M1a,d=M2a -F 1 -H s=M1a,d=M2b -F 2 s=M1a,d=M1c . All flows source address points to a single interface M1a. In this case, controller can't distinguish reports based on binding address alone.
3.Here where, report ID and flow ID plays a vital role. Daemon running in wildcard address can't have same report ID for its interfaces in a single node.
4.By comparing both daemon bind address and controller test address along with daemon report ID and controller flow ID resolve our bug in controller report_flow().

Implementation and changes in the code:
1.​​Added binding address data of daemon in report_flow() in daemon and retrieve the same data in controller fetch_reports().
2.Changed matching comparison in controller report_flow() to compare both daemon and controller binding address and report ID.