ashrafalhajjeh
commented
4 years ago After doing a little digging into this issue, here's what I found:
In pdu.c, the PDU length is packed on lines (269->272) as big-endian:
In pdu.c, the received file data packet struct generation also interprets PDU length as big-endian:
which is good.
The reason I was having issues now come from the following two pieces of code:
In cf_app.c:
In pdu.c:
Where the length is interpreted as a struct parameter assuming the machine's endianness (in my case little-endian). In the cf_app.c case, this forced me to create a very large incoming packet buffer (>60k bytes) for file chunks of just 200-500 bytes. In the pdu.c case, I ended up running into the "Incoming Nak truncated to fit in storage" message due to the pdu length indicating a large memory size for the NAK struct creation.
I think the two areas that use the length in an endianness dependent manner should be changed to accommodate running on a little-endian machine.
meleffendi
skliper
Hi, I have setup two cFS projects on a Linux VM with CF running on each one with CI and TO to test file transfer between the two projects as shown below:
When I try to transfer file /cf/cf.so from one side to the other (destination file name /cf/cf_sent.so) I get the following result (file sent from ppesim-cfs to pdpmep-fsw):
When I change the code at cf_app.c line 1030 from:
To:
The received packet's length is shown to be correct but the file still doesn't make it across.
If I attempt to run the unchange CF code between the Linux VM (little endian machine) and a powerPC (big endian) I get a segmentation fault (most likely because the powerPC is running the cFS project as root which I confirmed by running the receiving end of the VM version as sudo and I got a segmentation fault as well).
To start, is there anything I am missing with setting up two CF applications this way? Or is there any more information you might need me to provide?
Thanks, Ashraf.