adab azeez,

As previously recommended by Zoltan and Santosh, the primary method to manipulate Total Float for a selected chain of activities is to modify the late dates using a (FOB) constraint.  You state that you have done this, but "...none of them is working."  Although you have not described why, I suspect that your interpretation of Total Float is complicated by the intersecting driving logic paths in WBS 2.  In P6 there are two obvious ways to differentiate those paths and gain clarity:

1. Set the date of the suggested FOB constraint on the WBS 2 completion milestone substantially (say ~100 days) before its Early date.  This will create negative float on the activities leading to the constrained milestone, while those (presumably WBS 3) activities that control the project's finish date will remain at TF~0.  The negative float is artificial.  While useful for identifying driving and near-driving paths to the constrained milestone, the values are essentially meaningless.  They should not be shared.

2. Remove the constraint, and replace it with a super-long dummy activity that is applied as a successor to the WBS 2 completion milestone.  Set the duration of this "super-long trailing dummy" long enough to substantially extend the finish date of the entire project.  (Also ensure that there are no other late or mandatory constraints and that the project has NO "Must Finish by" date assigned.)  As a result, the driving path to the WBS 2 completion milestone will have TF~0, and its near-driving paths will have small positive values.  Other activities (e.g. WBS 3) will gain substantial positive float.  In this case, the WBS 2 float values may be useful for internal reporting, but the corresponding float values for WBS 3 will be incorrect and should not be shared.

In general, your desire, "...I want the float based on WBS.2 finish date," is not universally compatible with accepted definition of Total Float.  In all cases, Total Float is the difference between an activity's Late date and the corresponding Early date, where these dates are derived from the most stringent restraints of the entire logic network.  If a given WBS.2 activity must be finished no later than a certain date to avoid delaying the project completion BUT a later finish could be allowed without violating the WBS.2 finish constraint, then the Late dates of the activity (and the corresponding Total Float) must reflect the most stringent successor condition - i.e. the project completion, NOT the WBS.2 finish.

Note: while these methods are useful for analysis of a well-constructed, logic-driven project schedule, their use must be TEMPORARY and for specific analyses only.  Any schedule modifications whose primary purpose is manipulation of Total Float should be reversed prior to any formal issue or distribution.  

While they are excellent analysis techniques, neither the MFP analysis suggested by Johannes nor the click-tracing method suggested (most recently) by Zoltan will affect the Total Float calculation.  Consequently, I don't think they address your explicit question.