From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 25 Aug 2011 08:47:17 +0200 From: Andrew Lunn Message-ID: <20110825064717.GA28359@lunn.ch> References: <30568448.oAQcoQ5y1R@sven-laptop.home.narfation.org> <20110824071841.GA7895@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [B.A.T.M.A.N.] A case for batman-11s Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yeoh Chun-Yeow Cc: devel@lists.open80211s.org, The list for a Better Approach To Mobile Ad-hoc Networking , Clara Gnos On Thu, Aug 25, 2011 at 09:36:14AM +0800, Yeoh Chun-Yeow wrote: > Hi, all, > > Although batman-adv is a layer 2 routing that works across multiple access > technologies (not so sure about other technologies, because it mainly use > for WiFi), but it only make senses if we configure the wireless interface > operating in adhoc or adhocdemo mode. If we configure the wireless interface > as Infrastructure mode, all the traffic will go to the AP first, even if we > can direct communicate between the two STAs. > > Correct me if I am wrong. Ideally, you have BATMAN on the AP as well as the STA. So you never do STA->AP->STA hops between BATMAN nodes, you only do a STA->AP BATMAN hop followed by a AP->STA BATMAN hop. Performing two BATMAN hops means BATMAN knows the transmit quality of each of the two wireless hop, not the combined transmit quality of the STA->AP->STA path. So BATMAN running on the AP can then decide if it makes sense to take a different path. There is code to enforce this, i.e. blocking STA->AP->STA transfers, in the development tree and it has been push upstream to be included in the mainline kernel. Andrew