Subject: [manet] Re: ODMRP Glomosim forwarding group formation

From: Sochi K <[email-masked]>
Date: Sat, 20 Mar 2004 17:54:33 -0800 (PST)

Hello, I had earlier sent the question copied below, after having trouble
figuring out why the Join Reply was never received by the sender's
neighbors, thus inhibiting the formation of forwarding groups. 

The Join Reply is sent by the method NetworkIpSendRawGlomoMessageToMacLayer. Smaller packets such as Join Query are sent by the method NetworkIPSendPacketToMacLayer. I tested the process by sending a test message using both methods, and it was effectively
broadcast if sent by NetworkIpSendPacketToMacLayer, but not when sent by 
NetworkIpSendRawGlomoMessageToMacLayer. The difference in the two methods is merely AddIpHeader added in the body of the latter. In both cases, ANY_DEST was used as the next-hop, and no other modifications have been made to the odmrp code that comes with glomosim.

Has anybody else found this..? Please email me back if anyone has any
suggestion. Thank you, 

Harleen

On Fri, 19 Mar 2004, Harleen Dhillon wrote:

> 
> 
> Hi, I found this while tracking the formation of forwarding groups in 
> ODMRP. I was wondering if anybody else has found the same and have a 
> solution to this.
>  
> I use a simple simulation scenario, such as 10 nodes, in a 1000 x 1000 
> area. Assume that one node is the source and some node 3-4 hops away is 
> the intended receiver for the multicast packets. While trying to trace 
> the formation of forwarding groups, I realized that the forwarding group 
> flag was never being set. What is actually happening is that the join 
> reply, although being created at the receiver node - and supposedly sent 
> to the mac layer to be broadcasted - is never being broadcasted to the 
> other nodes, thus no forwarding groups formation is taking place. 
>  
> The join reply at the receiver node is being relayed by using the 
> method 
>  NetworkIpSendRawGlomoMessageToMacLayer(
>                         node, newMsg, lastAddr, CONTROL, IPPROTO_ODMRP, 
> 1, DEFAULT_INTERFACE, ANY_DEST);
>  
> This is called from the method: RoutingOdmrpSendReply in odmrp.pc. This 
> should send the join reply to the neighbors of the receiver node toward 
> the source, setting the forwarding group flags along the way.
>  
> From my understanding of this code, any packet upon broadcast by the 
> mac layer would be received by the method RoutingOdmrpRouterFunction in 
> odmrp.pc, which would determine whether it is a data packet or a control 
> packet, done by  the following comparison: 
>  
> ipHeader->ip_p == IPPROTO_ODMRP.
>  
> Thus, if a Join Reply is received by a node, it will have this 
> ipHeader->ip_p field value set as 145 (for odmrp). I find by some
> debugging that all the
> packets which are handled by this function have ipHeader->ip_p = 17, that is, 
> are data packets. None of them have this field set as 145. Hence, since 
> no join replies are ever received, no forwarding groups etc. are 
> formed. My guess is something is amiss in the header value settings in the 
> join reply formation. I have not altered the ODMRP code that came with 
> Glomosim. (The method NetworkIpSendRawGlomoMessageToMacLayer calls AddIpHeader 
> and then NetworkIpSendPacketToMacLayer. In AddIpHeader, the ipHeader->ip_p
> IS set to 145 at certain points, meaning that a Join Reply or Ack type of
> packet is created at certain points in the simulation, but the only ones
> that are received by any node have ip_p field as 17... so is something
> missing between the creation of the ip header and the receiving
> of packets by the nodes?).
>  
> I'm not very familiar with the mac layer code in glomosim, so if anyone 
> could please suggest something that might be missing in the code or an 
> error in my findings, it would be appreciated.
>  
> Thanks.
> 

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.