Networking Problems, Size Missmatch 15 vs 13

[KillerLink]

Hello,
i am currently working on porting zephyr to the Texas Instruments cc2538 SoC. While doing that, i am trying to get Networking to work over the built-in IEEE802154 radio in the cc2538. I already got that to working as far that the echo_client / echo_server samples can communicate with each other successfully with data beeing transmitted correctly.

My development started on Zephyr 1.7 and i recently have moved my implementation to Zephyr 1.11, when i was running on 1.7 the transmission was very smooth and was only subject to errors very rarely (that is less than 1 lost paket in a minute, mostly due to an error on the physical layer). With Zephyr 1.11 i am experiencing delays which i could not identify the source exaclty yet, but i suspected some network caching mechanism, which led me to disabling "Multicast Listener Discovery support" and "Neighbor cache".

In doing so i loose the functionality with the following error:

I was able to track the issue to some degree, but since my understanding of the layer 2 and layer 3 implementation is limited i had given up on my own. My findings were that there seems to exist a discrepancy with what address type is used (PAN ID, Short Address, Extended Address) when computing the header size in the function ieee802154_compute_header_size.

In this context i also found it interesting that the layer 2 implementation in l2/ieee802154_frame.c seems to make a call to a higher layer, the ipv6 layer, which seems uncommon / incorrect in a layered architecture to me. Below you see the piece of code in question, the function call to "net_ipv6_nbr_lookup", i think the other branch is taken between working/nonworking.

Some one else pointed out to me that it might be related to "joining a network" on a certain level, on which it does not know the mode of addressing yet, but sadly i'm could not do much with that information.

Attached you can find the autoconf.h from the working variant (which still suffers from frequent timeouts, but otherwise works) and the nonworking variant which does not send anything because of the explained error. I hope this provides reasonable information about my configuration, if i should / can provide addition information, please tell me to.
autoconf_working.h.txt
autoconf_nonworking.h.txt

The final question therefore is, is this a bug (in calculating the header sizes) or is my second configuration at fault?

[tbursztyka]

15.4 frame headers are of variable size, and it does vary a lot depending on whether it's sent broadcast or to a known peer etc... The way it knows peer is done only through IPv6 (via ND process).

15.4 L2 has a call to net_ipv6_nbr_lookup() to avoid having to maintain its own cache of IPv6<-->IEEE Addresses, so no it's not "incorrect".

Disabling Neighbour cache means no IPv6 Neighbour Discovery. How do you expect to get IPv6 working then on 15.4 without it?

Re-enable it. Your issue is maybe related to it, but disabling it is just giving you a bogus setup.
Can you hook up a sniffer as well, to see what's happening etc...?

Side note: how are you going to get your work merged to master if you work on an old release? Can't you work on latest master, or at least latest release (1.12)?

[KillerLink]

Okay, i can see now that it makes sense that Neighbour Discovery is required for it to work, i was not really aware of that and why but now i understand a little better, thanks for pointing that out.

But i still would argue that, if Neighbour Discovery is required for it to work, shouldn't it be selected by 802.15.4 or IPv6? Why can i even disable it, if it makes no sense to do?

And i also think that the error behaviour is somewhat misleading, since i would expect an error message like "could not determine address type" rather than something like "size mismatch" which does not reflect the real issue encountered (which is, that whithout Neighbour Discovery, it can't know the Address Type), the "size mismatch" seems more like a follow up error to me.

One alternative to the Neighbour Discovery could also be to prime the Neighbour Cache with certain entrys? That could make sense in development situations where you want to rely on as few as possible components to fail to isolate an error?
Another alternative could be to just use multicasts if Neighbour Discovery is not available, but i guess this would be out of standardized IPv6, and would therefore not make to much sense to implement.

I will reenable it and try to find the original problem instead. I got my sniffer only recently to work, but i will use it. A short experiment with the sniffer showed that the echo server should have recieved the complete packet, but transmitted only a part of it pack, interesting is that the the last packet transmitted by the server is a shorter one but in correct frame with correct checksum, which makes it appear as if the server decided to transmit less data back in some cases, which of course is not what the client expects. Might be a fragmentation issue then. But i will open a different issue with more detailed information sepcific to that problem after i tried to solve it that way and have gathered more information.

Regarding your side note about merging, i will of course move to 1.12 / latest master, but i wanted to get it working correctly first, since the code should work in later versions without to many changes. I already tried yesterday, i tested with 1.12 and had the same behaviour as i currently do.

[tbursztyka]

15.4 by itself does not mandate to run ipv6, nor it mandates about ipv6 internals such as ND. Though indeed, it could be set by default.

If you have any patch in mind, go ahead.

15.4 is not meant to be reliable on its basic feature level (with TSCH and all, it is way better), seeing the packet in the sniffer does not mean the actual target got it.

About the fact server sends less and in a good frame format: the checksum is done on the whole 15.4 frame, it's nominal. You have ipv6/udp on top of 15.4: when it receives it builts back the udp packet, and sends it back which means it will refragment and re-frame etc...

Now, echo server receiving less than supposed to, I don't know. You'll have to dig into that.

Btw, are you writing your own driver for cc2538? Because, if I am not mistaken the core of that 15.4 controller is a cc2520 with a bit more. It could be easily adapted to cc2520 driver (it would just need to have a different way to access registers: direct register mapping instead of spi).

[KillerLink]

As far as i am concerned, my problem(s) have been solved now, therefore i will close this issue.

It was more than one error that led to the behaviour i observered, some seem to have been fixed by recent commits to networking and echo_client/echo_server and some were configuration errors of my own (due to my incomplete understanding of ipv6).

Regarding the driver for the cc2538 and its similarities to the cc2520, i noticed that and my driver is somewhat based on the cc2520.

Thanks for the advice given!