Hi Lin & Chun-Yeow, Thank you very much for your help and time. I'll install the patch and let you know if it solved my problem.
Regards, Siva. > > Message: 1 > Date: Mon, 11 Mar 2013 13:46:41 +0000 > From: Chaoxing Lin <[email protected]> > To: "[email protected]" <[email protected]> > Subject: RE: mpath dump showing a path with next_hop address > 00:00:00:00:00:00 > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > I guess your mp is added to bridge since you mentioned "Ethernet" MAC. > I saw the same problem and solved it long ago(meaning, I can't remember > exact scenario to reproduce it). > > Below is the note when I fixed it. I hope it will help. > I believe the mesh_hwmp.c maintainer would know what's going on after > reading it. > > > "The problem is that code always looks up DA from mpath table. > Only when there is no entry in mpath table, it looks up DA from mpp table. > If neither table has an entry for DA, code adds an empty entry with DA in > mpath > table and starts path request with the hope that this entry will be filled > when > path reply packet comes back. In this case(DA is not a MP, it's Ethernet > MAC), there won't be path reply, which > results in a dead entry in mpath table. > > This dead entry prevent future communication because code won't look up DA > from > mpp table any more (there is an entry in mpath table, although it's dead). > > The fix for the bug part is to delete dead entry in mpath table when DA is > learned in mpp table. Now, valid entry can be found in mpp table and there > is no > need to do path request(meaning, no further dead entry later on)" > > > > From: [email protected] [mailto: > [email protected]] On Behalf Of Sivateja Patibandla > Sent: Saturday, March 09, 2013 3:19 PM > To: [email protected] > Subject: mpath dump showing a path with next_hop address 00:00:00:00:00:00 > > Hi, > > Sometimes my mpath dump shows paths with next hop address > as?00:00:00:00:00:00. And destination address as Ethernet's MAC address of > the destination.? > For example: Let's consider node A is trying to reach node B with wireless > MAC: 00:15:6d:ec:33:Fa and Ethernet MAC: 00:15:6d:ed:33:Fa. And the mpath > dump on node A is as follows. > > Dest Addr ? ? ? ? ? ? ? ? ? ? ?Next Hop ? ? ? ? ? > 00:15:6d:ec:33:Fa ? ? ? ? ? 00:15:6d:ec:33:fa > 00:15:6d:ed:33:Fa ? ? ? ? ? 00:00:00:00:00:00 > > When the mpath dump show this kind of paths. B won't respond to ping from > A. If I delete the second mapth by iw wlan0 mpath del 00:15:6d:ed:33:Fa > then it starts perfectly working fine. > > Any comments on what's going on? > > Regards, > Siva. ? > > > > ------------------------------ > > Message: 2 > Date: Mon, 11 Mar 2013 23:45:59 +0800 > From: Yeoh Chun-Yeow <[email protected]> > To: [email protected] > Subject: Re: mpath dump showing a path with next_hop address > 00:00:00:00:00:00 > Message-ID: > < > caefj984q+qd125o+phbody2uqae6b+w0vcngvdf8gn5-aiq...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, Chaoxing > > Yes. You are correct. As pointed out, the following patch is intended > to solve this: > > http://lists.open80211s.org/pipermail/devel/2013-February/004149.html > http://www.spinics.net/lists/linux-wireless/msg103642.html > > --- > Chun-Yeow > > On Mon, Mar 11, 2013 at 9:46 PM, Chaoxing Lin > <[email protected]> wrote: > > I guess your mp is added to bridge since you mentioned "Ethernet" MAC. > > I saw the same problem and solved it long ago(meaning, I can't remember > exact scenario to reproduce it). > > > > Below is the note when I fixed it. I hope it will help. > > I believe the mesh_hwmp.c maintainer would know what's going on after > reading it. > > > > > > "The problem is that code always looks up DA from mpath table. > > Only when there is no entry in mpath table, it looks up DA from mpp > table. > > If neither table has an entry for DA, code adds an empty entry with DA > in mpath > > table and starts path request with the hope that this entry will be > filled when > > path reply packet comes back. In this case(DA is not a MP, it's Ethernet > MAC), there won't be path reply, which > > results in a dead entry in mpath table. > > > > This dead entry prevent future communication because code won't look up > DA from > > mpp table any more (there is an entry in mpath table, although it's > dead). > > > > The fix for the bug part is to delete dead entry in mpath table when DA > is > > learned in mpp table. Now, valid entry can be found in mpp table and > there is no > > need to do path request(meaning, no further dead entry later on)" > > > > > > > ------------------------------ > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > > > End of Devel Digest, Vol 13, Issue 13 > ************************************* >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
