[mc1322x] 6LowPAN data payload

[Daniel Berenguer]

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?

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
>
>