Testing on both Ubuntu 20.04 LTS and MacOS Ventura beta, the UnetSocket C API can successfully transmit data, but consistently received corrupted data.
Instructions to reproduce:
clone unet-contrib
navigate to c gateway directory
"make", "make rxdata", "make txdata"
launch Unet 3.4.0 sample 2-node-network
"samples/rxdata localhost 1101" and "samples/txdata localhost 232 1102"
If the issue is successfully reproduced, and output like this should be observed:
Connecting to localhost:1101 Waiting for a Datagram Received a org.arl.unet.DatagramNtf : [0,232,210,31,116,34,127,0,0,] Reception Complete
Potential Solution:
replace b49c7ac1b071ded3dbd2a58db39818da54a202ba with 229b37c063eec87870cf129dbf94f766a97d0cb0 in the Makefile (which corresponds to v1.9.1 of fjage)
"samples/rxdata localhost 1101" and "samples/txdata localhost 232 1102"
When I perform the above steps to update fjage, my output becomes:
Connecting to localhost:1101 Waiting for a Datagram Received a org.arl.unet.DatagramNtf : [1,2,3,4,5,6,7,8,9,] Reception Complete
Which is the correct representation of the data sent.
It is also worth noting that the test for data reception in test_unet.c only checks to make sure the class is equal to org.arl.unet.DatagramNtf, but takes no steps to ensure that the data transmitted is received correctly. This means that even though data transmitted was not being received correctly, the test was passing. This meant that the issue was impossible to spot via testing before shipping the update.
Testing on both Ubuntu 20.04 LTS and MacOS Ventura beta, the UnetSocket C API can successfully transmit data, but consistently received corrupted data.
Instructions to reproduce:
If the issue is successfully reproduced, and output like this should be observed:
Connecting to localhost:1101 Waiting for a Datagram Received a org.arl.unet.DatagramNtf : [0,232,210,31,116,34,127,0,0,] Reception CompletePotential Solution:
When I perform the above steps to update fjage, my output becomes:
Connecting to localhost:1101 Waiting for a Datagram Received a org.arl.unet.DatagramNtf : [1,2,3,4,5,6,7,8,9,] Reception CompleteWhich is the correct representation of the data sent.
It is also worth noting that the test for data reception in test_unet.c only checks to make sure the class is equal to org.arl.unet.DatagramNtf, but takes no steps to ensure that the data transmitted is received correctly. This means that even though data transmitted was not being received correctly, the test was passing. This meant that the issue was impossible to spot via testing before shipping the update.