[mc1322x] 6LowPAN data payload

[Jon Smirl]

On Wed, Jul 14, 2010 at 10:43 AM, Daniel Berenguer
<dberenguer at usapiens.com> wrote:
> Mar, the patch does not seem to add the fragmentation feature. I'm
> using rpl-border-router + tunslip6 and I'm still unable to receive
> data packets bigger than 88 bytes. Wireshark does show the correct
> data transmitted but I'm not sure that the data is actually
> transmitted. Are you maybe using the linux-zigbee driver?

There are complications in this setup. SLIP has a MTU of 296. RPL has
a MTU of 128. IPv6 requires a 1280 MTU.

You can force the 1280 MTU onto SLIP. But that means that the
rpl-border-router has to dis/reassemble the 6lowpan fragments before
sending them down the SLIP link.


>
> On the other hand, I wanted the fragmentation stuff for my tftp client
> but I could resize the transmit buffer from 512 bytes down to 88
> bytes. This is not a big problem in my case.
>
> Daniel.
>
>
> On 13 July 2010 22:53, Umberto Manzoli <ruytenburch at gmail.com> wrote:
>> On 13 July 2010 20:47, Jon Smirl <jonsmirl at gmail.com> 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.
>>
>> Bye,
>>   UM
>>
>> _______________________________________________
>> mc1322x mailing list
>> mc1322x at devl.org
>> http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>>
>>
>
> _______________________________________________
> mc1322x mailing list
> mc1322x at devl.org
> http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>



-- 
Jon Smirl
jonsmirl at gmail.com