<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1886288660;
mso-list-type:hybrid;
mso-list-template-ids:-191436850 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Henning,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I ran a number of scenarios today. If I don’t use the IP tables on my gateway (no other nodes have it, by the way), an nslookup will never succeed as I progress down the nodes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Here is a quick status to date:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>With or without the iptables, when I ping the gateway, the ping returns DUP quite often and sometimes hangs for a considerable time before returning<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The default gateway only propagates through the network nicely with a netmask of 255.255.0.0<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>When I use olsrv2.lan=0.0.0.0/0 rather than lan_import=eth0, the network sets itself up nicely<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have validated using “ip route” that all looks OK for each node on the network. However, it isn’t operating reliably. Once I have a youtube session up and running and I don’t move around, it plays perfect. It’s just getting it set up and understanding the duplicate pings.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think that using the ACL option, I might be able to get it to work reliably as I am guessing that the network is reconfiguring itself on the fly.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>More later. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Peter E.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Henning Rogge [mailto:hrogge@gmail.com] <br><b>Sent:</b> Monday, July 18, 2016 5:33 AM<br><b>To:</b> Peter Emanuel<br><b>Cc:</b> olsr-dev<br><b>Subject:</b> Re: [Olsr-dev] Propagating a default gateway OLSRv2<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hmm?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>You are using IPtables to forward traffic between eth0 and wlan0?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That sounds dangerous at best. Why do you do this?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Henning<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Jul 15, 2016 at 10:47 PM, Peter Emanuel <<a href="mailto:peter@sistreaming.com" target="_blank">peter@sistreaming.com</a>> wrote:<o:p></o:p></p><div><div><p>I have an update on this. I stumbled into a prior discussion on this forum from 2012 about this exact problem. The solution was to change the netmask on the WiFi from 255.255.255.0 to 255.255.0.0. This definitely helped as there were default gateways specified in each of the nodes in the chain pointing at each connected/edge node. (I personally don't understand why this changed anything as all of my nodes were on the same subnet - 192.168.18.x. This is probably my own lack of understanding).<o:p></o:p></p><p> <o:p></o:p></p><p>My gateway to the Internet was node 192.168.18.2. I was able to ping this IP from the last node in my chain of my 6 nodes (192.168.18.201) but couldn't get to the Internet although the DNS lookup appeared to work fine. I tried accessing <a href="http://youtube.com" target="_blank">youtube.com</a> and <a href="http://google.com" target="_blank">google.com</a>. Again, once my edge node was 1 hop from the gateway, everything started working as expected (192.168.18.201 connected to 192.168.18.3).<o:p></o:p></p><p> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><img border=0 width=624 height=115 id="_x0000_i1025" src="cid:image001.png@01D1E104.A2475E40"><o:p></o:p></p><p> <o:p></o:p></p><p> <o:p></o:p></p><p>One added piece of information is that I had to set up the following iptable rules to actually get the packets to pass through on the gateway.<o:p></o:p></p><p> <o:p></o:p></p><p> WlanIP=" $( ifconfig wlan0 2>/dev/null)"; # note leading space<o:p></o:p></p><p> WlanIP=${WlanIP#*inet addr:}; # extract the address<o:p></o:p></p><p> WlanIP=${WlanIP%% *} # but if none<o:p></o:p></p><p> <o:p></o:p></p><p> # forward all traffic coming from wlan0 (that's not destined for the laptop) to eth0<o:p></o:p></p><p> iptables -A FORWARD ! --dst ${WlanIP} -i wlan0 -o eth0 -j ACCEPT<o:p></o:p></p><p> # forward traffic coming from wlan0 to eth0<o:p></o:p></p><p> iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT<o:p></o:p></p><p> # forward traffic coming from eth0 to wlan0<o:p></o:p></p><p> iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT<o:p></o:p></p><p> # setup Network Area Translation (NAT) so that all forwarded traffic to eth0 appears to be coming from the laptop's IP address<o:p></o:p></p><p> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<o:p></o:p></p><p>Any help in getting the Internet access working properly would be greatly appreciated.<o:p></o:p></p><p> <o:p></o:p></p><p>-----Original Message-----<br>From: Peter Emanuel [mailto:<a href="mailto:peter@sistreaming.com" target="_blank">peter@sistreaming.com</a>] <br>Sent: Thursday, July 14, 2016 1:44 PM<br>To: 'Henning Rogge'<br>Cc: 'olsr-dev'<br>Subject: RE: [Olsr-dev] Propagating a default gateway OLSRv2<o:p></o:p></p><p> <o:p></o:p></p><p>I am still a little confused about how the default gateway should propagate. When I fired up multiple nodes in my home, everything worked great. When I started stringing nodes into trees across the neighborhood with line of sight between consecutive nodes, all of the nodes appeared in the routing table but the default route wasn't present in nodes 2 hops or more down the chain. I did only have a single node to single node communication as the route back to the gateway which I presume isn't an issue. Is there something that I am doing wrong or is there some configuration setting that I am missing? <o:p></o:p></p><p> <o:p></o:p></p><p>-----Original Message-----<o:p></o:p></p><p>From: Henning Rogge [<a href="mailto:hrogge@gmail.com" target="_blank"><span style='color:windowtext;text-decoration:none'>mailto:hrogge@gmail.com</span></a>] <o:p></o:p></p><p>Sent: Friday, July 08, 2016 1:56 AM<o:p></o:p></p><p>To: Peter Emanuel<o:p></o:p></p><p>Cc: olsr-dev<o:p></o:p></p><p>Subject: Re: [Olsr-dev] Propagating a default gateway OLSRv2<o:p></o:p></p><p> <o:p></o:p></p><p>On Thu, Jul 7, 2016 at 8:55 PM, Peter Emanuel <<a href="mailto:peter@sistreaming.com" target="_blank"><span style='color:windowtext;text-decoration:none'>peter@sistreaming.com</span></a>> wrote:<o:p></o:p></p><div><div><p>> Hi Henning,<o:p></o:p></p><p>> <o:p></o:p></p><p>> Brilliant! Thanks so much. The Wiki page was extremely informative too. Not sure how I didn't run into it before.<o:p></o:p></p><p>> <o:p></o:p></p><p>> Both methods worked. I had tried<o:p></o:p></p><p>> <o:p></o:p></p><p>> olsrd2_static --set lan_import.interface=eth0 wlan0 lo &<o:p></o:p></p><p>> <o:p></o:p></p><p>> without success. I am not sure whether the [lan_import=1] in the config file is significant. Regardless, I can move forward using the config file.<o:p></o:p></p><p> <o:p></o:p></p><p>Yes, the "=1" makes a difference...<o:p></o:p></p><p> <o:p></o:p></p><p>("olsrd2_static --set lan_import[1].interface=eth0 wlan0 lo &" should work too)<o:p></o:p></p><p> <o:p></o:p></p><p>why?<o:p></o:p></p><p> <o:p></o:p></p><p>2 reasons:<o:p></o:p></p><p> <o:p></o:p></p><p>- you might want to have multiple lan_import sections... the name gives you the way to put them into a config file<o:p></o:p></p><p>- you don't want to have a default value active for lan_import. Think about sections like "global" or "olsrv2". Both have an effect even if they are not present in the configuration... lan_import can be dangerous, so I made it into a named section similar to "interface".<o:p></o:p></p><p> <o:p></o:p></p><p>> Which of your 2 methods is preferable since both seemed to work?<o:p></o:p></p><p> <o:p></o:p></p><p>Your choice. The lan_import way means you don't have to put your IP configuration into the olsrd2 config, which makes it easier to handle for multiple routers.<o:p></o:p></p><p> <o:p></o:p></p><p>> On the Android front - there are a number of caveats that I need to point out (even though I am not an Android guru). I ran into these when using olsrdv1.<o:p></o:p></p><p>> Starting with Android release KitKat and onwards, Google started introducing more and more security. From a mesh standpoint, it became more of a pain.<o:p></o:p></p><p>> 1) They introduced secure linux as the only kernel the bootloader would boot.<o:p></o:p></p><p>> 2) They enforced compiling with -fPIE (Program Independent <o:p></o:p></p><p>> Executables) as well using as -fPIC<o:p></o:p></p><p>> 3) Worse yet, only authorized networks would work. The connection manager inside Android would not allow connecting to an Adhoc network like OLSRD. The connection manager needs to be modified inside Android authorizing the olsrd as a valid network and any application that wants to connect to the network has to register with the network (using Java Reflection or some such method). Local network communications work fine using later releases of Android if you compile with -fPIE when communicating from node to node but not when passing through the connection manager.<o:p></o:p></p><p> <o:p></o:p></p><p>Yes, the "no adhoc mode" thing is a pain...<o:p></o:p></p><p> <o:p></o:p></p><p>> It's a pain to modify and recompile android. So, I plan to address this issue later but am sticking to my Android development using Jellybean (4.2.2) for now. Olsrd2 seems to work just fine with this Android release. That said, I targeted my Android build to platform android-18 even though the latest build is android-24 so I cannot vouch for any android platform after android-18. Using kitkat, the updated Chromium browser doesn't work nor does YouTube even on Jelly Bean. Opera and the built in browser works fine. YouTube from the browser works fine.<o:p></o:p></p><p> <o:p></o:p></p><p>> Two other thing I ran into with the olsrd2 sources is that epoll_create1 is only supported by later kernels that came into existence with android-21 so I had to modify your sources to use the prior epoll_create call rather than epoll_create1. I also had to pull in a separately compiled version of the netlink library to support linking the nl80211 listener.<o:p></o:p></p><p> <o:p></o:p></p><p>epoll_create1 was introduced in kernel 2.6.27... that is too new for android 4.x *sigh*<o:p></o:p></p><p> <o:p></o:p></p><p>Is there a good feature request macro to test for it?<o:p></o:p></p><p> <o:p></o:p></p><p>Henning Rogge<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>