Since no broadcast ARP request generated by the Ping machine (ARP table is not reflushed), it seems that "re-enabled mesh interface" mesh node treats the ICMP echo request as unicast with unknown forwarding information. Thus, go to ieee80211_xmit and trigger path discovery. But the other mesh node does not process the PREQ with proxied target address according to current stack.
--- Chun-Yeow On Fri, Feb 8, 2013 at 7:43 PM, Yeoh Chun-Yeow <[email protected]> wrote: > Hi, Cedric > > Yes. It was helpful. > > I can only reproduce the problem whenever I have specified a specific > MAC address on my Ping machine by doing "arp -s 192.168.1.1 > 00:11:22:33:44:55". > > If you refer to the attached wireshark file, the mesh action frame > will have the target STA address of 00:11:22:33:44:55. The mesh node > keeps sending the PREQ frame which is not replied by another mesh node > which is also confirmed in your mesh node. > > DEST ADDR NEXT HOP IFACE SN METRIC QLEN > EXPTIME DTIM DRET FLAGS > 00:09:90:00:2d:ee 00:00:00:00:00:00 wlan0 0 0 1 > 0 200 1 0x2 > > If you do ARP table flush in your Ping machine and also delete "iw > wlan0 mpath del 00:09:90:00:2d:ee", it should work, right? > > Perhaps, need to re-look on path table and also handling of PREQ frame > for target STA address outside the MBSS. Any comments? > > ---- > Chun-Yeow > > P.S: I may not available next week due to Chinese New Year. _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
