<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hello,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm new to OLSR and am finding the learning curve steep. I'd like to make several comments to clarify things in my mind and I'd be terribly grateful to hear your comments and corrections. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It appears to me that there is a huge misconception between the designers of OLSR and much of the current user base (myself included, actually maybe I'm the only one with the misconception). </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As best I can tell, OLSR is fundamentally different than OSPF or RIP in that it propagates routes for HOSTS rather than networks - by default. I suppose this makes sense as many ad-hoc mesh networks may be comprised of "sensor nodes" in which each node both "does something" (measures the temperature maybe) and is also a router. In this way, each sensor is a possible path for data transmission, and since each node is a router, one need only route directly to interfaces and not to networks.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>However, this is very different from the model that many people are used to in which an ad-hoc mesh of nodes provide routing services between networks to which other clients can connect. For example, a community wireless project in which each node in a network provides both a local AP functionality for client computers and a wireless link to other nodes. In this scenario OLSR might be chosen so that non-persistent nodes installed on busses or ferries or whatever are handled gracefully. Here, OLSR is meant to provide routing between NETWORKS rather than just the network interfaces of the node. This is much more like a mobile meshed LAN providing dynamic networking for client machines rather than a mesh sensor network. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>When you set up OLSR and configure the "interfaces" entry in olrsd.conf, you propagate routes to those interfaces through the network. But you don't propagate routes to the networks those interfaces are attached to, and so clients on those networks are unreachable. This fact was and is very confusing to me, as a very similar entry in ospfd.conf will propagate routes to the networks those interfaces are connected to, rather than just the interface itself. A review of this list archives seems to show that it is confusing to many others too. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm probably missing something, but I cannot see a reason why an "interface" entry in olrsd.conf should not simply propagate a network address rather than a host address. It seems to me the more general case of a network address would serve to provide a route to both the network interface and other addresses on that network - in much the same way as other common routing protocols. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Thanks for listening - this wasn't meant to be a rant. I look forward to your comments.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-Val</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV> <BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>------------------------------------------------------</DIV><DIV>Val Schmidt</DIV><DIV>CCOM/JHC</DIV><DIV>University of New Hampshire</DIV><DIV>Chase Ocean Engineering Lab</DIV><DIV>24 Colovos Road</DIV><DIV>Durham, NH 03824</DIV><DIV>e: vschmidt [AT] ccom.unh.edu</DIV><DIV>m: 614.286.3726</DIV><BR class="Apple-interchange-newline"></SPAN></SPAN></SPAN> </DIV><BR></DIV></BODY></HTML>