I added the Contiki and linux-zigbee lists.... On Tue, Jul 13, 2010 at 4:53 PM, Umberto Manzoli <[email protected]> wrote: > On 13 July 2010 20:47, Jon Smirl <[email protected]> wrote: >> >> PPP/SLIP are adding an unnecessary layer of complexity. For example >> I'm not sure yet if they work right for IPv6. It also makes routing >> more complex. Now the 802.15.4 LAN is hooked to the Ethernet LAN by a >> PTP link instead of a direct connection. Broadcast packets are not >> normally forwarded over PTP links so radvd is messed up. All of this >> is making me learn a lot more about IPv6 than I wanted to. >> > The main problem is that PPP - because of the presence of a "type of upper > protocol" field in its frame - can handle different protocols in its > payload, so there are extensions for IPv6 and IPv6CP (IPv6 Control Protocol > for PPP). Moreover, through LCP packets, it is possible to manage the status > of the link, i.e. it is possible to send and receive alive packets to and > from the device and thus to automatically disconnect from the serial device > and make some further retries. > RFC 5072 : IPv6 over PPP > RFC 5172 : IPv6CP > > SLIP is not recommended for IPv6 operations and IPv6 extensions are not > supported by all operating systems, as it is only a straight-and-forward way > to encapsulate IP frames into a serial stream. There is no link control, > neither different protocol handling. > > The big problem with PPP is that the connected device turns into a router, > so a lot of Contiki routing stuff should be rewritten in order to process > and forward IP packets (maybe in different context/prefixes). This means > that device should answer to router-broadcast FE80::2 and forward them. > The other main problem is that, as the connected device acts as a router, > you cannot easily copy-and-forward packets from one interface to another, > but you should route them. So radvd should/could run over the connected > device and the 6LoWPAN nwk and the PPP link should be given different > prefixes and a way to correctly define routing should be provided, at least > at application level, once the PPP link is up. > Again, it is supposed that Linux sets up a PPP link as a slave (i.e. similar > way to the one you use when connecting to a standard modem). Thus, up to > now, IPCP and IPV6CP do provide needed IPv4 addresses and IPv6 interface > identifiers. As PPP means point-to-point, Linux do not forward neighbour > discovery/solicitations over the PPP link.
I'm about ready to declare that hooking these devices up over a PTP protocol link is too much trouble. The alternative is the linux-zigbee model. That means treating the USB stick as a dumb radio and running 6lowpan/RPL on the Linux host. I'm looking for a good routing solution to the multiple gateway problem. Say you have a net of 200 RPL devices and five gateways. I want the RPL devices to use the nearest gateway. I don't want the packets making 10 hops to getting to a gateway that is far away. Complicating things more, my gateways are wired together with 1GbE. How are the packets gong to figure out that it is faster to hop to a gateway, use the 1GbE and then hop back into the RPL net. > > Bye, > UM > -- Jon Smirl [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
