nasa
Enable Tlm IP address communication fails at initialization
Describe the bug With an unmodified build of integration-candidate including the fix for #852, opening cFS Ground System->cFE/CFS Subsystem Commands->Enable Tlm and entering a remote IP address in the Input field and clicking "send" does not properly initialize communication with CFS on the satellite machine. Other behaviors (see below) indicate the entered IP address is not propagated internally either.
To Reproduce Steps to reproduce the behavior:
- Configure a "satellite" machine and a remote "Ground Station" machine.
- Start cFS/build/exe/cpu1/cpu/core-cpu1 on the satellite machine, as instructed in the README
- On the ground station machine, click through "CFS Ground System"->"Start Command System"->"Enable Tlm"
- Enter the IP address of the remote satellite machine in the Input field
- Click "send"
- Note that the terminal on the satellite machine shows no data connection or receipt of packets (this is in contrast to the behavior if you run the Ground Station system on the same machine as the satellite CFS processes)
- Then, on the Subsystem Commands window, note the "Send to" fields all contain localhost (127.0.0.1) and cannot be changed.
- Click "Display Page" next to any subsystem, e.g., "SB No-Op"
- Change the "Send To" value at the top of the window to be the remote IP address of the satellite machine
- Click "Send" next to CFE_SB_NOOP_CC
- Note the terminal window on the satellite machine displays information about receipt of the no-op
Expected behavior The Ground Station system should properly use the entered remote IP address and initialize TLM. The entered IP address should propagate throughout the subsequent Ground Station windows and child windows.
Code snips I haven't figured out exactly where the problem lies, so cannot provide a context diff.
System observed on:
- Raspberry Pi 4 (both computers)
- OS: Raspberry Pi OS, latest build and patched
- Versions [e.g. cFE 6.6, OSAL 4.2, PSP 1.3 for mcp750, any related apps]
- Raspberry Pi OS version 10 (Buster)
- CFS - integration-candidate branch as of 2020-09-03, 1700 hours
- cFE v6.0.0-rc1+dev42 release v6.7.0
Additional context
- Running systems in permutations of root/non-root does not change the behavior (so not a socket() permission problem)
- Running systems on the same machine works, but not on remote machines (implies entered remote IP address not be used properly internally - perhaps a failed class attribute update - maybe in an instance of GroundSystem.ipAddressesList[]?)
- Manually changing the "Send To" IP address in "Subsystem Commands"->[anything]->"Display Page" produces output as expected on the satellite machine (which means the UDP communications work, it's just the IP address handling inside the Ground System code has a bug?)
Reporter Info Phil Moyer (hukuzatuna on GitHub, [email protected] or [email protected]) No company (yet), individual user
Note of caution - we often break integration-candidate as it's our staging branch for CI (https://github.com/nasa/cFS/wiki/The-cFS-CCB-Process). Main is the more stable development branch.
Thank you for the caution. I didn't (don't) know how to merge #852 in with main, so I checked out integration-candidate. Please let me know if you'd like me to do anything else to help investigate!
On Fri, Sep 4, 2020 at 7:58 AM skliper [email protected] wrote:
Note of caution - we often break integration-candidate as it's our staging branch for CI (https://github.com/nasa/cFS/wiki/The-cFS-CCB-Process). Main is the more stable development branch.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nasa/cFS-GroundSystem/issues/134#issuecomment-687201668, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUGJ76YR32QNL46G72YMUDSED6CZANCNFSM4QYQQSPA .