Getting started questions

[chelliwell]

I don't yet have access to stellarstation, but am devising a client app (a Windows service) for a 2021 satellite using stellarcli. So to get an initial understanding of open-stream in particular, I have set up your fake-apiserver. I can connect to the server, and with --debug I see that the cli is receiving the data. However I'm not seeing any tcp or udp being sent out by the cli. Is it because the data generated by the server is invalid (random)? Or am I missing something else. Both are using 'localhost'. Thanks.

PS: Can I suggest you document 'STELLARSTATION_API_URL' - it took me some time to discover it!)

[davidk81]

Thanks for leaving a question, and also for your valuable feedback. Regarding your question, "I'm not seeing any tcp or udp being sent out by the cli," do you have --proxy tcp enabled? eg: ./stellar sat open-stream 5 --proxy tcp

In another terminal, you may use netcat to redirect the telemetry data to file if you are using linux/mac. netcat -w1 127.0.0.1 6001 > output_file

We have update readme per requested - https://github.com/infostellarinc/stellarcli/pull/121

[chelliwell]

Thanks. I've tried both tcp and default udp, but still not seeing any packets. I'm using mainly Wireshark on a loopback adapter to watch for them. (Again, I do see the traffic between fake server and cli). Currently using it on Win10, btw

[chelliwell]

Hacking about a bit (bearing in mind I don't know Go!), it's not getting past the switch at line 271 of stream.go - I guess because the data is so random?

[davidk81]

random data shoudn't be a problem, yesterday i tested latest master on stellarcli with the fake-api-server (should be pretty close to the recent releases) which i believe is the same setup as you are doing; perhaps with exception i'm using mac and linux for testing (don't have access to a windows machine)

can you clarify what you mean by "it's not getting past the switch at line 271 of stream.go" ?

can you also try the --output-file command? eg: ./stellarcli satellite open-stream 5 --output-file sat_output.bin --stats -v --debug

if the file is writing correctly then it should be "getting past the switch line 271"

thanks!

[chelliwell]

Sorry, that was my mistake. Yes, it is doing that part - the packets are written to the output file. I still can't capture the output packets at all. Also tried a Linux HyperV virtual machine - but neither netcat nor tcpdump seem to get the packets. I'll keep looking for anything I'm getting wrong.

[chelliwell]

Ok, think I've found it. On both Linux and Windows, the UDP datagram is rejected if it's too long - though no error reported by CLI.... If I set fakeserver's TM_PAYLOAD_SIZE to <64K then the data is sent ok.

[davidk81]

Glad you were able to figure out the issue. In our production environment we are using telemetry payload sizes ranging from 1KB to 8MB (although we currently recommend 1MB for high throughput satellites > 100 Mbps). I have not tested UDP specifically, but we have not experienced any issues using --tcp-proxy with 1MB payloads in production environment.

As for fake-api-server, I tested TCP with default payload size (seems like it's 1M). Not sure if OS configuration could be causing the difference in our test results (?) I'll try to do more testing when I get the chance.

[danada]

This is starting to remind me of another user report of not being able to use the TCP proxy to write to a file via netcat. This user was using RHEL which may impose different restrictions when compared to debian/ubuntu. @chelliwell which distro of linux did you test the CLI with?

The solution to this might involve having the client output to the proxy 64K (or whatever the limit may be) at a time.

[chelliwell]

I was using Ubuntu 20

[danada]

@chelliwell thanks for the info. I'll see if I can reproduce this.

By the way, are you already in contact with sales or somebody at Infostellar? If not feel free to send me a message at dan@istellar.com and we may be able to set you up with access to the API.