pat
pat copied to clipboard
la5nta
Integrate with github.com/n8jja/Pat-Vara
I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.
I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.
I believe this could be implemented in the VARA modem's DialURL function directly? It has access to the full URL, including the query parameters 🙂
I would also like to add bandwidth as a transport URL parameter, but that's a bigger change, and not strictly required right now.
I believe this could be implemented in the VARA modem's DialURL function directly? It has access to the full URL, including the query parameters 🙂
That's where I'd like to pipe it down, and I already look for the bw query param in the transport code. However, actually putting that into the UI feels like a separate task, especially since other transports might also benefit.
I'm not seing any modem teardown in func cleanup(). The tcp connection to the modem should be closed there, for proper app termination.
Missed that, I'll add it! Also, I wasn't aware it was necessary because the TCP connection was being dropped after VARA disconnect, but it's possible that was a bug on my part. Should the TCP connection stay open after VARA disconnect?
And shouldn't the vara package distinguish between modem.Close() and conn.Close()? 🤔 It looks like both the modem connection and the dialed vara connection are represented by the same type (the modem-struct). That's a bit odd IMHO. Wouldn't it be better to let DialURL return a separate type implementing the just the Conn interface?
I can keep Close for aborting the RF connection and expose a new CloseModem for closing the TCP connection, does that sound right?
But that brings up a tangential point I was confused about. Since golang interfaces are duck-typed, and since net.Listener.Close and net.Conn.Close have the same signature, those two must be the same method, right? I guess that's appropriate in this case?
I can keep Close for aborting the RF connection and expose a new CloseModem for closing the TCP connection, does that sound right?
But that brings up a tangential point I was confused about. Since golang interfaces are duck-typed, and since net.Listener.Close and net.Conn.Close have the same signature, those two must be the same method, right? I guess that's appropriate in this case?
The ARDOP and WINMOR stubs both expose Disconnect for RF and Close for Pat's connection to the TNC. Those get used in abortActiveConnection. The PACTOR stub doesn't expose a similar method, but I think it'd be useful to do that for VARA since we're still in early stages. I'll send a PR to add that to http://github.com/n8jja/Pat-Vara.
Wouldn't it be better to let DialURL return a separate type implementing the just the Conn interface?
I think I'm starting to grok what you mean here. Maybe NewModem() should only initialize the cmdConn, and then DialURL can initialized dataConn and return that to the client code instead of implementing net.Conn itself. That way, if a client takes the return from DialURL and calls Close on that, they're only closing dataConn, not the modem. I'll start to rework the transport that way.
I'm proposing changes to the VARA stub API in https://github.com/n8jja/Pat-Vara/pull/10.
I tried separating Disconnect for just RF and Close for RF and TCP, but it turns out the VARA program doesn't tolerate that well (doesn't seem to like rapid TCP disconnect and reconnect), so I'm sticking with the one modem.Close method.
However, the change does separate out modem.Close from conn.Close as you suggested.
I tried separating Disconnect for just RF and Close for RF and TCP, but it turns out the VARA program doesn't tolerate that well (doesn't seem to like rapid TCP disconnect and reconnect), so I'm sticking with the one modem.Close method.
For WINMOR and ARDOP, both data and control sockets are held open even when the modem is idle. Maybe that's what VARA expects as well? Have you looked at the raw tcp frames between VARA and e.g. Winlink Express to see how they've implemented it?
It sounds strange to me that you would need to tear down the modem connection in between sessions. How would that work for incoming p2p connections?
Another concern is the inherit buffering in modems like these. For ARDOP it is very important not to disconnect the data and ctrl sockets until the buffer has been flushed and the modem confirms the disconnect and reaches idle state. If not, the last frames may be lost at either end. Have you investigated this with regards to VARA?
@xylo04 - What's the status on this? Are you awaiting my review and merge?
@martinhpedersen no, I'm not waiting for review at this point. I'm trying to dig deeper with the TCP connection state as you suggested. To do that, I'm trying to set up both sides of a VARA-FM connection to test more reliably, and that has taken me off on a tangent of setting up my own RMS.
If it helps, we can change this PR to draft for now and I'll mark it active again later.
... and that has taken me off on a tangent of setting up my own RMS.
Been there 😆 👍
Thanks for taking the time. My experience is that these transport drivers requires a lot of testing.
I've ordered a RPi 4B in case I have some spare time to do some field testing 🙂 I would also love to see the Listener-interface be implemented. Hopefully I will have time to have a go at it within the next couple of months, if you don't beat me to it 😉
Converting to draft 👍
First, I wanted to say: I used xylo04's vara branch from his repo last week and it worked perfectly for me. (On one computer - the other didn't have enough power to run VARA apparently - it turns out using a 10 year old Intel Atom CPU just doesn't cut it).
Second: I did some diving with Winlink Express, VARA-FM and Wireshark to get you info on how the TCP connection is handled on Windows.
It's important to note that with Winlink Express, the life-cycle of the app is different. Normally, the VARA app is spawned by winlink itself when you hit "Open Session", and closed when you hit "Exit" on the session dialog. It isn't manually run by the user typically, although that can work.
When the session dialog is open, both the Control and Data TCP connections are opened immediately and the control connection gets MYCALL and LISTEN ON flags. If the action session isn't started with the start button, the data connection stays idle, and the control connection gets back periodic IAMALIVE and BUSY ON/OFF messages.
Once the user hits the start button (I did this about 4 minutes after opening the session dialog), the actual exchange takes place. The first packet on the data channel is a PSH/ACK packet from VARA back to Winlink with the start of the session data in it. (I suspect this is likely reversed for the server end; no idea about P2P). After the session completes, VARA sends back DISCONNECTED and CANCELPENDING messages on the control channel, and returns to the idle state, and winlink shows the connection as closed. The user can chose to hit "Exit" which will kill VARA and close the session window, or let it sit. I chose to let it sit.
If the user hits the start button again (I did this about 5 minutes after the end of the last session), the process above repeats, on the same TCP connections. Afterwards, both channels return again to their idle state. When the user finally hits "Exit" in the Winlink session dialog, Winlink sends a "LISTEN OFF" on the Control channel and closes the TCP connection (first FIN packets are from Winlink). Then it kills the TNC software. and closes the dialog.
Hopefully this addresses Martin's questions. If you have any more, let me know - happy to share my pcap or run more experiments.
Cheers! Benjamin, WY2K
(PS: I'm building yet another "how to set up VARA and Pat on Linux" guide as part of build notes for a Winlink node monitoring system. I have install instructions for Debian 11 that I believe are the most minimal needed, as a lot floating around are also for getting RMS Express under Wine. They include instructions for building Chris's fork. I wasn't planning on publishing broadly just yet, but let me know if this is of interest to you and I'll share.)
This is great detail, thank you @bseidenberg! That answers at least one of the big questions we had: the TCP connections are kept open after an exchange. Also, that helps in figuring out when to initiate listening (turns out, right at the beginning). @n8jja FYI!
Did more testing on pi4b with Vara HF and Vara FM/VHF using VOX/Signalink and all is good so far....except P2P. It appears P2P listener side not implemented for VARA. Looking for any pointers regarding VARA protocol commands back and forth for a P2P session. It would be really cool to get P2P VARA working. Currently we have to rely on Ardop P2P and it is a challenge to find other P2P stations accepting this traffic here as VARA is being used more and more as the standard. Nice build / feature set so far. Looking forward to seeing this in the main code stream.
It appears P2P listener side not implemented for VARA.
Hi @gh42lb, that's true that listening is not yet implemented. I had thought I might wait until the outgoing connection code had been merged. However, the latest VARA dev doc does show how to set the TNC for listening, so I might try to squeak this in!
Hi Chris, Awesome!!! LB
On 3/15/22 5:11 PM, Chris Keller wrote:
It appears P2P listener side not implemented for VARA.Hi @gh42lb https://github.com/gh42lb, that's true that listening is not yet implemented. I had thought I might wait until the outgoing connection code had been merged. However, the latest VARA dev doc https://mega.nz/file/3OABQSKa#nhipI88MnTW1uu3BAZebk_-USRDWEIrN-bGz2l05pRM does show how to set the TNC for listening, so I might try to squeak this in!
— Reply to this email directly, view it on GitHub https://github.com/la5nta/pat/pull/280#issuecomment-1068685251, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWEG6GNOEVE5X6Q6MJ4CGPTVAFGMJANCNFSM5DVT57TQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Aloha Chris,
Just a quick note to give you some feedback on the Pata Vara build. I used this extensively on a Raspberry Pi 4b for the April 16th ARES Comex here in Hawaii. I used Vara exclusively for connecting to the HF gateways (Kenwood radio + Signalink + Diamond trap vertical). Connection was from Big Island to Kauai about 500 miles or so running barefoot only. We had very poor HF propagation on the day only 40M was working to some degree and that was marginal however using digital..the Pat Winlink + Vara performed brilliantly. I could see the Vara modem dynamically changing throughput rates based on the ACK codes going back and forward and even though the signal coming back to my station was in the noise my station had no trouble picking this out and sending back an ACK code. Its pretty impressive what you can do with a pi4b+pat Vara. I also was able to use P2P ardop and that also worked great from the pi. You had mentioned that you may be included the P2P vara listener in your check-in. Let me know if you have anything ready to test...so far so good...its performing great!
73
LB
WH6GGO
Message ID: @.***>