|
From: David K. <da...@em...> - 2011-09-24 22:30:22
|
radvd configures all the windows boxes with the ipv6 prefix assigned to its eth0 interface. Then all ipv6 packets from windows go to the radvd box, and on to the internet if it has ipv6 connectivity, e.g. a sixxs tunnel. With the jackdaw plugged into the radvd box you assign aaaa::1/64 to the RNDIS interface and have radvd send RAs; they go out 6lowpan and configure the contiki nodes. Any reference to aaaa:: goes out the jackdaw interface, and NS/NA will operate to show neighbors. With rpl the NS/NA/RA's are ignored so you need to some other way to pass the prefix and find the connected nodes. Slip passes a prefix with a ?P !P interchange so the prefix does not have to be hard coded like it is for the jackdaw border router. aaaa::/64 packets are routed to the tun0 or rndis interface as before, and arp is turned off so no NS/NA will go to the border router; if the unicast destination is in the border router route table it will go out. Again, if you can reach it from linux you can automatically reach it from any lan or wan request. But I don't know what happens if the linux box is not the default ipv6 route. It may advertise the aaaa::/64 prefix through the lan, I think I have seen that. -----Original Message----- From: Maciej Wasilak Sent: Saturday, September 24, 2011 4:17 PM To: Contiki developer mailing list Subject: Re: [Contiki-developers] WSN border router in LAN environment-discovery Thanks for your replies. David: I'm not sure if I understand correctly, but will the PC's on the network be able to contact RPL nodes automatically? If not, maybe the static routes are necessary like Mohammad says. But I don't know if searching static routes happens before checking if destination is on-link. Jon: it seems that radvd uses RFC 4191 (it wouldn't be possible to advertise a default route without it). If I understand it right, in your setup Linux hosts receive RFC 4191 Router Advertisments and insert default route into their routing tables. According to Microsoft, Windows hosts also should understand it. Therefore it's safe to assume that RFC 4191 is a standard now. It shouldn't be hard to implement it in Contiki. Last thing I wonder is if it's possible to determine what is the next free subnet in some automatic way. Best Regards Maciek 2011/9/20 jon...@gm... <jon...@gm...> On Tue, Sep 20, 2011 at 8:16 AM, Mohammad Abdellatif <moh...@gm...> wrote: > i think this is really the easiest way.. :) > another harder way would be to enable ip forwarding on the linux machine > "with the border router connected" and then add a static route on the > other > machines to the rpl network through the linux ethernet interface. You shouldn't need to add static routes. http://www.dslreports.com/forum/r25832421-Multiple-IPv6-routers-on-LAN > > Mohammad Abdellatif > Phd student at Faculty of Engineering University of Porto (FEUP) > Researcher at Inesc Porto, UTM, WiN > http://win.inescporto.pt/mma > > > > On Sun, Sep 18, 2011 at 10:09 PM, David Kopf <da...@em...> > wrote: >> >> The easiest way is to have a linux box as the switch and router, then >> radvd will handle everything. Plug the rpl border router into >> that and it will pick up its assigned prefix and advertise it through >> rpl. >> radvd autoconfigures all your devices and routes between >> its local interfaces and the internet. RPL nodes could perhaps >> periodically send packets to some well known address that the linux >> box can use to keep a list of the active ones and perhaps enter the names >> in the hosts file. >> >> Don't know what happens when you introduce another ip6 router. >> >> >> >> -----Original Message----- >> From: Maciej Wasilak >> Sent: Sunday, September 18, 2011 4:39 PM >> To: Contiki developer mailing list >> Subject: [Contiki-developers] WSN border router in LAN environment >> -discovery >> >> Hello, >> >> I would like to ask your opinion about the theoretical home LAN setup: a >> Contiki-based WSN border router plugged into a switch with >> a home router (switch and home router might be in the same device), and >> some number of PC's or smartphones. Border router has some >> nodes on its 802.15.4 side and uses RPL (with no other IPv6 ND or >> 6lowpan-ND functionality). PC's use Linux/Windows (powerful OS >> with its own routing tables), smartphones use Android or other OS (also >> powerful but not as much). >> >> The problem is how to make the devices in LAN discover the WSN border >> router without disrupting their communication with internet. I >> am thinking about two scenarios: >> >> 1) RFC4861 + RIPng - WSN border router sends standard Router >> Advertisements. Home router does the same. Hosts are not able to >> recognize which router is better for WSN or Internet. It is possible to >> implement some simple routing protocol like RIPng - the >> Contiki border-router should be powerful enough to run it. When hosts >> send >> internet traffic WSN border router, it should send a >> Redirect pointing to the home router. Similarly the home router should >> redirect the WSN traffic to the WSN border router. >> >> 2) RFC4861 + RFC4191 (+ RIPng) - WSN border router sends modified Router >> Advertisements with Route Information Option containing RPL >> prefix. Home router also sends Router Advertisements with Route >> Information Option containing default prefix ::/0. Both advertise >> themselves as default routers (so that if one of them fails, the other >> one >> still works) and with medium priority (WSN and Internet >> don't overlap, so priority is useless). Hosts should immediately know >> where to send their traffic - no redirects should happen. To >> redirect traffic from WSN to Internet RIPng is still necessary. >> >> My question is which of these tactics has a better chance of working? >> >> >> >> ------------------------------------------------------------------------------ >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> http://p.sf.net/sfu/rim-devcon-copy2 >> _______________________________________________ >> Contiki-developers mailing list >> Con...@li... >> https://lists.sourceforge.net/lists/listinfo/contiki-developers > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Contiki-developers mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/contiki-developers > > -- Jon Smirl jon...@gm... ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Contiki-developers mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/contiki-developers ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Contiki-developers mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/contiki-developers |