FujiNetWIFI
CoCo firmware - network_json_query returns 0xD and sometimes additional characters in addition to query value
When using network_json_query to query a parsed json response, the return value has either a carriage return (0xD), or a carriage return plus other random characters appended to the return value.
This was tested using a test program found in the CoCo weather client in the coco/work/testprg folder. Run the wctest application from the wgtest.dsk disk image.
As you can see from this test, the "success" message from the json returned from the ip-api call has a CR (0xD) at the end. Press any key after every new URL test to move to the next one. Because of the extra characters, the URL for the next call is mangled with CRs in the middle, so the calls fail.
If you want to see what everything is SUPPOSED to look like, run wctesttr.bin. It does the same test, but it trims every response string from the network_json_query calls by truncating them at the first CR:
Using Xroar and FujiNet firmware 672c0a0ed I don't get the \x0D on success. Let me try another setup.
ARGH. Sorry. I forgot that the checked-in version of wctest.c has code in it to clear out the 0xD.
Please look at wctest.bin and wctesttr.bin from here: https://github.com/RichStephens/fujinet-weather/tree/coco-test
The wctest has the 0xd in all the returns from the initial ip-api call, which messes up the subsequent URL. wctesttr has the code to clean out the 0x0d (which is like what you saw).
Yeah, I don't think I tested this one against 1.5.1. Just did. Yep. Me too.
I guess it could be a fujinet-lib bug, but I really can't see how. Perhaps a firmware bug that's been around for a bit?
I guess it could be a fujinet-lib bug, but I really can't see how. Perhaps a firmware bug that's been around for a bit?
Do you have an example where it works without appending \x0D?
In every case where I have seen network_json_query, it has returned the data, followed by 0xD, followed by 0 or more garbage characters. Usually 0, but sometimes more. I'm not aware of a case where this does not happen. I modified my test client (and the weather client) to truncate all responses from network_json_query at the first 0xD.
I was thinking about this, and any extra characters I'm seeing beyond the 0xD are probably just what was in the target buffer before. I thought at first it was that whatever is parsing the json wasn't taking the null terminator into account, but that doesn't make sense because it's consistently returning a 0xD after the actual data.
Here's a look at the serial log from a network_json_query call:
OP_NET: 1
comnd: 'S' 83,0,0
drivewireNetwork::sio_status_channel(1)
sio_status_channel() - BW: 8 C: 1 E: 1
00 08 01 01
OP_NET: 1
comnd: '' 1,0,4
drivewireNetwork::send_response[4]:
OP_NET: 1
comnd: 'R' 82,0,8
drivewireNetwork::read( 8 bytes)
OP_NET: 1
comnd: '' 1,0,8
drivewireNetwork::send_response[8]:success
OP_NET: 1
Notice that the 'S'tatus call, says there are 8 bytes to return. The response returns 8 bytes, but you can see there's a CR (the blank line after the response "success").
The ugly, dumb way to fix this is in the network_json_query method in fujnet_lib, and I know exactly where to do that, but the BEST way to fix it is wherever the actual json query code is in the firmware. I just haven't been able to figure out exactly where that is.
Whatever the problem is, it's either somewhere in lib/fnjson/fnjson.cpp, OR in /components_pc/cJSON/cJSON_utils.c, I'd bet. Not clear where, though.
OK....we've determined that this is not a problem. It's a feature. So, I think we can close this as "as intended".