-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document Using COSMOS Bridges #1508
Comments
|
when i try the third instruction (ruby COSMOS/cosmos/bin/cosmos bridgesetup) |
Ok. It is missing running "rake build" in the COSMOS/cosmos folder to build the C extensions. Do that, and then try ruby COSMOS\cosmos\bin\cosmos bridgesetup again |
okay when running "rake build" in COSMOS/cosmos folder. rake aborted! |
Now missing "bundle install", before "rake build". |
Now i get There was an error parsing
|
Arg. Ok need to set RUBYGEMS_URL too. |
After setting RUBYGEMS_URL "source ENV['RUBYGEMS_URL']= 'https://www.rubygems.org'" and sucssesful exicuting "bundle install" and "rake build". Then tring ruby COSMOS\cosmos\bin\cosmos bridgesetup again the error didn't get fixed. /var/lib/gems/3.0.0/gems/cosmos-0.0.6/lib/cosmos/service.rb:9: warning: already initialized constant Middleware::Runner::EMPTY_MIDDLEWARE |
Run: I'm not sure how COSMOS 0.0.6 gets installed, but that breaks everything. COSMOS 5 is not (yet) installed as a gem. It gets added to the path through RUBYLIB variable in this example |
unfortunatlly even after running "gem uninstall cosmos" the error is still there. internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in |
Unless there is more to that message, it would indicate that RUBYLIB isn't set. If you do, you should be able to run 'irb' and then: |
I am following this example on Windows with Ruby version 3.1.1 I get an error when running
Here is output from running
|
You'll need to have the Ruby Installer + Devkit from rubyinstaller.org to compile the C extensions. Did you install the Devkit version? |
I had the Devkit installed, but I missed a step in setting it up. I needed to do |
Running on Ubuntu 18.04 I'm trying to follow the steps to setup cosmos bridges but I'm having a problem. I have done the following:
I then get the following error: internal:/usr/local/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb:85:in Can someone please help me resolve this. |
You were probably missing the zlib-devel package when you built ruby. (maybe zlib1g-dev on Ubuntu). Probably need to apt install that and rebuild ruby. |
I ran:
When I rebuild ruby I noticed the following: *** Following extensions are not compiled: When I look at mkmf.log for zlib I find various undeclared errors for deflateReset error: ‘deflateReset’ undeclared (first use in this function) Any ideas? |
This has the recommended apt installs for building ruby: and then this: These are against Debian buster (Ubuntu 20.04 equiv), but should be similar |
Thanks so much for your help Ryan! I was able to successfully build ruby, run bundle install and rake build. I then generated my bridge.txt file, modified it and ran "ruby COSMOS/cosmos/bin cosmos bridge" {"time":1650326922815774501,"@timestamp":"2022-04-18T18:08:42.815-06:00","severity":"INFO","container_name":"precision-vm","log":"Processing Bridge configuration in file: /home/precision/bridge.txt"} I updated my plugin.txt file to use a tcp-ip interface. INTERFACE <%= draco_target_name %>_INT tcpip_client_interface.rb host.docker.internal 8080 8081 10.0 nil BURST I'm getting the following error when Cosmos tries to connect to my interface. DRACO_INT: RuntimeError : Invalid hostname: host.docker.internal I'm so close and excited! Can you help me in how I need to properly configure the tcp ip client interface for the bridge? David |
Try: 172.17.0.1 instead of host.docker.internal https://stackoverflow.com/questions/48546124/what-is-linux-equivalent-of-host-docker-internal If that doesn't work then we'll need to dig into your docker install a bit more |
I'm now getting DRACO_INT: Connection Failed: ECONNREFUSED : Connection refused - connect(2) for 172.17.0.1:8080 On the console that the I'm running "ruby COSMOS/cosmos/bin cosmos bridge" I noticed the following: {"time":1650329273466803495,"@timestamp":"2022-04-18T18:47:53.466-06:00","severity":"INFO","container_name":"precision-vm","log":"SERIAL_ROUTER: Tcpip server accepted connection from UNKNOWN(172.29.0.6):49656"} ... |
Can you share your bridge config file, and plugin INTERFACE lines? I think the default bridge config uses port 2950 instead of 8080, but it seems close to connecting so that's probably not the issue. It feels like the connection is working in one direction, so maybe some kind of firewall issue |
Also are you trying this with rootless docker? |
I don't think I'm using rootless docker. I admit I wasn't even sure what it was so I googled. I did not taken any steps to configure it. Is there a way I would know for sure? |
Bridge.txt:
plugin.txt
|
Replace 8080 8081 in plugin.txt with 2950 2950 |
Wahoo!!!! It's up and running now. Thank you sooooooo much!!! |
Hi Ryan, Thanks again for all your help getting my bridge going! I was wondering if you could point me in the right direction and offer some hints on debugging the bridge code. I have a defined 6 simple cmds and can receive all of them successfully except for one. For some reason if the id, used for PKTID, is set to 3 then I will not receive the last byte of the packet which is this ID. If I just change this to another value, i.e. 7, then I receive it no problem. I appreciate any hints you have. Thanks, David --------------------------------_ccsds_cmd.txt------------------------------------------------ PARAMETER CCSDSVER 0 3 UINT 0 0 0 "CCSDS primary header version number" --------------------------------cmds.txt------------------------------------------------------- COMMAND TEST TRANSFER_EVENT_DATA BIG_ENDIAN "Send event data" COMMAND TEST TRANSFER_HS_DATA_BUF BIG_ENDIAN "Send high speed data buffer" COMMAND TEST SUCCESSFUL_DOWNLINK BIG_ENDIAN "Indication that a successful downlink occurred. Trigger delete of event record" COMMAND TEST CHANGE_PARAMENTER BIG_ENDIAN "Change parameter" COMMAND TEST NOOP BIG_ENDIAN "No-op command" This will work if I just change 3 to 7. COMMAND TEST TRANSFER_HS_DATA_BUF BIG_ENDIAN "Send high speed data buffer" |
I don't have a specific reason for the 3 versus 7 thing, but my guess is it is because you are putting the wrong value into the CCSDS_LENGTH field. For CCSDS source packets, a length of 0 = 1 byte of data. So for your packets with 2 bytes of data, the CCSDS_LENGTH field should be set to 1 (not 2). |
@ryanatball, we were able to get the ethernet bridge working on Windows. However, I'm trying to get it working with It looks like
Does that imply it would not be possible to use the bridge in its current form? I tried adding Do you have any ideas on a possible solution? Edit: Maybe a solution is to manually forward port 2950? Update: I tried to get this working with some combination of port forwarding, |
I haven't tried getting to the host from podman yet, so I can't answer if that works or not. A good solution would probably be to swap the client/server design. Make the bridge be a tcpip_client_interface that connects to COSMOS, and have the COSMOS Interface be a tcpip_server_interface. You'll need to open up whatever port you use in compose.yaml for the cosmos-operator process as well. |
@ryanatball, is it as simple as changing the interface type in the bridge and plugin files? |
@bradley-harden-apl It should be mostly swapping the bridge ROUTER line parameters and the plugin INTERFACE line parameters, and then opening the port in compose.yaml to the cosmos-operator container. |
The BRIDGE router would then connect to "localhost" |
Note, it is still a ROUTER in the bridge, and an INTERFACE in the plugin. |
I was just about to ask that |
@ryanatball, it looks like that doesn't work. Or maybe I did something wrong. Like you said, I brought down COSMOS, added ports:
- "2950:2950" to the Then I swapped the client and server interfaces, and made the client point to Any ideas? |
That should work. Can you share your exact config lines? |
bridge.txt:
plugin.txt:
|
Alternatively, maybe it would be easier to just expose |
Still don't see anything wrong with your config. Check the CmdTlmServer log messages and interfaces tab and make sure the INTERFACE is happy and running. Then maybe do a netstat or something to see if the port is open and listening on localhost (should be if the compose line worked). I think getting devices into rootless Podman is probably not going to work... Should be possible with normal Docker |
The plugin looks happy. I only see "Connection requested", "Connecting ..." and "Connection Success". Maybe adding |
Ah, no, that won't work. Edit with link for posterity |
OH! Duh....
That's way simpler than an ethernet bridge or trying to get groups forwarded into the container. And even though I don't really care about security, it wouldn't even be a security risk if I did, because it's just a serial port. It looks like that works, so I think it will be my path forward. |
@ryanatball, I was able to fix the inverted ethernet bridge. I had forgotten that I modified my |
@bradley-harden-apl I'm glad you got this working. Could you please post your final solution of plugin.txt, bridge.txt and whatever changes you needed to make to the compose.yaml? I'm sure this will help others with the same issue. |
diff --git a/compose.yaml b/compose.yaml
index 3133b162..616c5391 100644
--- a/compose.yaml
+++ b/compose.yaml
@@ -86,6 +86,8 @@ services:
- ".env"
extra_hosts:
- host.docker.internal:host-gateway
+ ports:
+ - "2950:2950" |
Here is my other solution, where the device is mounted into the container:
No bridge
diff --git a/compose.yaml b/compose.yaml
index 3133b162..4db43d7b 100644
--- a/compose.yaml
+++ b/compose.yaml
@@ -86,6 +86,8 @@ services:
- ".env"
extra_hosts:
- host.docker.internal:host-gateway
+ devices:
+ - "/dev/ttyUSB0:/dev/ttyUSB0" In a shell:
|
Documented here: https://openc3.com/docs/v5/bridges |
Primarily provide serial example, but maybe provide hints for FFI as well.
The text was updated successfully, but these errors were encountered: