BPQ Accessing the Winlink CMS

From Digital Traffic System
Jump to: navigation, search

Accessing the Winlink CMS

Contrary to common believe you do not need to have a BBS in order to run a Winlink RMS. Both applications are independent of each other. All you need to run a RMS is a local internet connection, and a BPQ node with both a telnet and a radio port.

Remember again that this document is not a substitute for the official BPQ documentation you should refer to when in doubt. Additionally, the Winlink website at www.winlink.org provides further helpful resources.


Winlink 2000 basics

Winlink 2000 or WL2K for short is an internet email to radio gateway system allowing radio amateurs to send and receive email by radio using the B2F message exchange protocol. WL2K calls itself a network but note that the network component is part of the internet.

From an internet point of view WL2K is an email provider (for the winlink.org domain). The feature that makes the difference to other providers is that WL2K makes email accessible by radio. Therefore only duly licenced radio amateurs (or stations of other radio services) are allowed as users of this system. For radio links the B2F messaging protocol is used as a substitute for the standard internet email protocols (SMTP, POP3, IMAP4 etc.) because B2F deals more efficient with the limited bandwidth.

Here is the basic design:

           radio           radio           internet
           WL2K user       WL2K user       WL2K user
          +---------+     +---------+     +---------+
          | msging  |     | msging  |     | msging  |
          | program |     | program |     | program |
          |         |     |         |     |         |
          | B2F     |     | B2F     |     | B2F     |
          | radio   |     | radio   |     |         |
          +----+----+     +----+----+     |         |
               |               |          | TCP     |
            RMS|GW          RMS|GW        |         |
          +----+----+     +----+----+     |         |
          | radio   |     | radio   |     |         |
          +---------+     +---------+     |         |
          | CMS     |     | CMS     |     | CMS     |
          | accesss |     | access  |     | access  |
          |         |     |         |     |         |
          | gateway |     | gateway |     | client  |
          | mode    |     | mode    |     | mode    |
    +- - -|- - - - -|- - -|- - - - -|- - -|- - - - -|- - -+
          +----+----+     +----+----+     +----+----+
    |          |               |               |          |
               | B2F           | B2F           | B2F
    |          | over TCP      | over TCP      | over TCP |
               |               |               |
    |     +----+---------------+---------------+----+     |
          |  TCP server                             |
    |     |  server.winlink.org:8772                |     |
          +-----------------------------------------+
    |     |  B2F + authentication                   |     |
          +-----------------------------------------+
    |     |  Common Message Servers (CMS)           |     |
          |                                         |
    |     +-----------------------------------------+     |
          |  winlink.org SMTP MTA                   |
    |     +--------------------+--------------------+     |
           Core Winlink system |
    |                          |                          |
                               |
    |     +--------------------+--------------------+     |
          |  any.other.domain SMTP MTA              |
    |     +-----------------------------------------+     |
          |  ISP SMTP/ POP3                         |
    |     +---+-------------------------------------+     |
              |
    |         |                                           |
              |
    |     +---+---+                              internet |
    +- - -|- - - -|- - - - - - - - - - - - - - - - - - - -+
          |  MUA  |
          +-------+
           email
           user

At the heart of the Winlink system are the Common Message Servers (CMS) a cloud-like geographically distributed message store which holds all email messages addressed to and from @winlink.org and exchanges email messages with other domains using standard internet infrastructure and protocols.

The CMS offer a TCP server interface at server.winlink.org:8772 which can either be accessed directly by users over the internet or via RMS (Radio Mail Server) gateway stations. Users always need to authenticate with Winlink when accessing the CMS.

A relay in Winlink-speech is an alternate server to server.winlink.org offering the same functionality as the original Winlink server. Relays relay messages to and from the Winlink CMS. Most relays use TCP port 8772 as the original Winlink server does.

Accessing the CMS directly over the internet as shown on the right-most side in the above diagram offers the same functionality as connecting to your ISP with an email program. The main difference is that B2F is used instead of SMTP/ POP3.

A RMS is a radio station registered with Winlink to make the CMS interface available by radio. Basically it translates TCP to a radio mode (packet, Pactor, Winmor).

When a user establishes a radio connection with an RMS the station makes up a TCP connection to the CMS over the internet and authenticates with the CMS. This CMS connection is then used as a kind of tunnel for the user to communicate with the CMS. Note that both the RMS gateway station and the user authenticate with the CMS.

Today, WL2K also provides a mechanism with backup radio links compensating for a local outage of the internet connection at an RMS. We will however not cover this feature.


CMS TCP connections

Outbound TCP connections are performed by the BPQ telnet server port (see the section on the telnet server port above). BPQ needs to authenticate with the CMS when connecting to the CMS servers either in gateway mode or in client mode. The telnet server port knows how to do this and this is why CMS TCP access is part of the telnet server port configuration. The basic setting is to either enable (CMS=1) or disable (CMS=0) CMS TCP access:

    PORT
      ID=telnet
      PORTNUM=1
      DRIVER=TELNET

      CONFIG
        ... ... ...
        ; disable WL2K CMS TCP access
        CMS=0
    ENDPORT

CMS=0 is assumed if the CMS switch is not listed in the port configuration. The telnet server port status window in the BPQ console displays the configuration status in either red (disabled) or green (enabled) colour. Enabling CMS access means that a node user can use your internet connection to access the Winlink CMS.

You may also use the GUI to enable CMS access. In the BPQ console window select the Telnet Server Status sub-window and choose "CMS Access Enabled" from the Actions menu.

When accessing the CMS in gateway mode the two parameters CMSCALL and CMSPASS are used to authenticate with the CMS:

    PORT
      ID=telnet
      PORTNUM=1
      DRIVER=TELNET

      CONFIG
        ... ... ...
        ; RMS gateway config
        CMS=1
        CMSCALL=DB0NTS-10
        CMSPASS=SECRET
    ENDPORT

This applies to registered RMS gateway stations only. All SSIDs (if any) and the base callsign share the same Winlink password. See the Winlink FAQ for more details on this. Please note that Winlink also requires operating times and frequencies to be reported when running a RMS gateway.

In client mode the user callsign together with a pre-defined (fixed) password are used instead. This is activated by neither specifying CMSCALL nor CMSPASS in the configuration and it is recommended to list both parameters as empty strings to this end:

    PORT
      ID=telnet
      PORTNUM=1
      DRIVER=TELNET

      CONFIG
        ... ... ...
        ; enable WL2K CMS TCP client mode
        CMS=1
        CMSCALL=;
        CMSPASS=;
    ENDPORT

Whichever mode you use the switch command "C p CMS" where p is the port number of the BPQ telnet server port initiates a CMS connection. Details like host names (server.winlink.org) and TCP ports (8772) are encapsulated in the telnet server port implementation.

The CMS server name server.winlink.org randomly resolves to one of the five geographically distributed CMS servers. However, your operating system may cache the result so that subsequent requests for server.winlink.org always resolve to the same server. DNS caching may result in a non-reachable CMS server being tried to be connected again and again although other CMS servers are available.

Disable your local DNS cache to avoid this. In modern versions of Windows you need to deactivate the "DNS client" service to achieve this. There is also an option "Using Cached CMS Addresses" to cache server addresses by BPQ. You will find it in the Actions menu of the BPQ console window when the Telnet Server Status sub-window is selected.

The following diagram shows a user accessing the WL2K system through a station running BPQ. This works with either gateway or client mode.

      +-----------+
      | messaging |
      | program   |
      | (B2F)     |
      +-----------+
      +-----------+
      | TNC       |
      +-----------+
      +-----------+
      | radio     |
      +----+------+
           |
           | radio link        user station
    - - - -|- - - - - - - - - - - - - - - -
           |                    BPQ station
      +----+------+
      | radio     |
      +-----------+
      +-----------+
      | TNC       |
      +-------+---+
              |
          +---+-----+  +---------------+
          | port 1  |  |               |
          | packet  |--|-c->-+         |
          | radio   |  |     |         |
          +---------+  |     |C 2 CMS  |
                       |     |         |
          +---------+  |     |         |
          | port 2  |  |     |         |
          | telnet  |--|-c-<-+  BPQ    |
          |         |  |        switch |
          +---+-----+  +---------------+
              |
    - - - - - | - - - - - - - - - - - - - -
              | TCP connection         WL2K
              |
      +-------+------------------------+
      | TCP server                     |
      | server.winlink.org:8772        |
      +--------------------------------+
      | B2F + authentication           |
      +--------------------------------+
      | Common Message Servers (CMS)   |
      +--------------------------------+

BPQ handles the user's radio link, connects to the CMS and authenticates with the CMS. After establishing both connections BPQ simply moves all data back and forth between the user and the CMS in both directions. Note that the B2F messaging protocol is transparent to BPQ. The user's messaging software and the CMS know how to talk B2F but BPQ does not.

Instead of connecting to the standard CMS servers (server.winlink.org) you may also specify an alternate host (a relay host in Winlink speech) with the RELAYHOST keyword. A connection with the relay host is established with the "C p RELAY" command.

Logging of CMS TCP connections is controlled with the CMSLOGGING (CMSLOGGING=0,1) statement. For client mode logging is not really needed as all information is contained in the BBS log anyway. Daily log files

    ...\AppData\Roaming\BPQ32\Logs\CMSAccess_YYYYMMDD.log

(YYYY=year, MM=month, DD=day) are created in the standard logs directory.

    C:\Users\BPQ\AppData\Roaming\BPQ32\Logs> type CMSAccess_20160502.log
    16:55:44 10 DB0NTS Connected to CMS
    16:55:45 10 Callsign :
    16:55:45 10 DB0NTS
    16:55:45 10 Password :
    16:55:45 10 CMSTELNET
    16:55:45 10 [WL2K-3.2-B2FWIHJM$]<cr>
    16:55:46 10 ;PQ: 32091644<cr>
    16:55:46 10 Wien CMS ><cr>
    16:55:46 10 ;FW: DB0NTS DF0NTS|35447849 DL4FN|01328932<cr>
    16:55:46 10 [BPQ-6.0.12.35-B2FIHJM$]<cr>
    16:55:46 10 ;PR: 93479689<cr>
    16:55:46 10 FF<cr>
    16:55:46 10 FQ<cr>
    16:55:47 10 Disconnected. Bytes Sent = 85 Bytes Received 49 Time 3 Seconds

The second column contains the stream number to distinguish multiple concurrent CMS connections. In the above example a connection using client mode is shown.

CMS Logging can also be activated from the GUI. In the BPQ console window select the Telnet Server Status sub-window and choose "Log CMS Connections" from the "Logging Options" entry in the Actions menu.


Relaying

There is also an option to set up a relay to serve inbound TCP connections. The basic concept is to configure an application inbound TCP connections are routed to which is achieved with the RELAYAPPL keyword.

When a RELAYAPPL is defined the BPQ telnet server port binds TCP port 8772 to the specified application. Note that there is no relation between RELAYAPP and CMS access in the first place.

                  +----------------+  +---------------+
                  |                |  |        BPQ    |
    inbound ----->|-> port 1 ->----|--|-c->-+  switch |
                  |                |  |     |         |
                  +----------------+  |     |         |
                                      |     |         |
                  +----------------+  |     |C 2 CMS  |
    outbound      | port 2, telnet |  |     |         |
    CMS server <--|-< CMS access <-|--|-c-<-+         |  +-----------+
                  |                |  |               |  |           |
    inbound ----->|tcp/8772 ----->-|--|-c->------->-c-|--| RELAYAPPL |
                  |                |  |               |  |           |
                  +----------------+  +---------------+  +-----------+

If you want to divert users to RELAYAPP in case the CMS connection fails you have to separately configure this with the FALLBACKTORELAY=1 statement. Setting the value to 0 explicitly disables this, e.g.

    PORT
      ID=telnet
      PORTNUM=1
      DRIVER=TELNET

      CONFIG
        ... ... ...
        ; bind BBS to 8772/tcp
        RELAYAPPL=BBS
        FALLBACKTORELAY=0
    ENDPORT

In this example the BBS application is made accessible through TCP port 8772.

Typical applications for using RELAYAPPL as a fallback for CMS connections (FALLBACKTORELAY=1) are the BBS, or a connection to a far-away RMS gateway station. However, when performing an outbound call from RELAYAPPL to CMS you may end up talking to yourself. In BBS connect script this is prevented with the NOFALLBACK telnet port command. In order for the command to be sent to the port instead of the switch the port needs to be ATTACHed first in the connect script:

    ATTACH p
    NOFALLBACK
    C p CMS


RMS gateway configuration

When you want to operate an RMS gateway first read the instructions on the Winlink website carefully. Operating an RMS gateway comes with a couple of duties. One of them is to register with Winlink i.e. to create a Winlink sysop record. As a result of this step you will receive a password for gateway mode (see CMSPASS above).

Additionally you will need to create a Winlink sysop record. This may be performed with BPQ once WL2K reporting is configured (see below). Either use the "WL2KSYSOP SET" node command (available to BPQ sysops) or the "Update WL2K Sysop Record" entry in the Actions menu of the GUI. The WL2KSYSOP node command can be used to display your data.

Winlink reporting is configured with the WL2KREPORT config statement which is part of the relevant radio port configs after the CONFIG line. The command has the following parameters:

    WL2KREPORT svc, host, port, callsign, locator, hours, freq, mode, power, antHeight, antGain, antDir
svc

Winlink service code, e.g. EMCOMM, MARS, or PUBLIC; an RMS gateway open to all amateurs has service code PUBLIC

host, port host and TCP to send reports to, typically server.winlink.org:8085
callsign callsign of the RMS gateway station including SSID if needed
locator Maidenhead Locator of the RMS gateway station
hours

Time range the report is valid for in hh-hh format. The starting time is at 00 minutes and the end time at 59 minutes of the hour. 00-23 means 0000-2359 i.e. the whole day. Multiple ranges may be separated by colons e.g. 03-09:12-14.

freq centre frequency in Hz
mode
  • PKTspeed for packet radio, e.g. PKT1200, PKT9600;
  • ROBUST for robust packet radio
  • WINMORbw for WINMOR, e.g. WINMOR500, WINMOR 1600
  • Pnm... for Pactor (same syntax as for the scanner), e.g. P4, P123
power (optional) transmitting power in W PEP
antHeight (optional) antenna height above ground measured in feet
antGain (optional) antenna gain in dBd
antDir antenna direction; 0 = ND, 360 = north

An example line is

    WL2KREPORT PUBLIC, server.winlink.org, 8085, GM8BPQ-10, IO68VL, 00-23, 28110000, P123, 50

The function of the RMS gateway is to offer CMS access to it's users which is achieved with an BPQ application typically named "RMS". Something like

    APPLICATION 3,RMS,C 1 CMS,DB0NTS-10,,0

will do the job at least for VHF/ UHF packet radio. For HF ports either use a dedicated callsign for the RMS gateway or share a single callsign for several applications each of which has dedicated frequencies. The latter approach is shown in the following longer example showing a configuration for an SCS Dragon controller with both a packet radio and a Pactor port.

    PORT
      ID=Telnet
      PORTNUM=1
      DRIVER=TELNET
      QUALITY=0

      CONFIG
        LOGGING=0
        DisconnectOnClose=1

        ; Winlink gateway mode
        CMS=1
        CMSCALL=DB0NTS
        CMSPASS=SECRET
        CMSLOGGING=1

        ; BBS on tcp/8772
        RELAYAPPL=BBS
        FALLBACKTORELAY=0
    ENDPORT

    ; Pactor port
    PORT
      ID=PTC
      PORTNUM=2
      DRIVER=SCSPactor
      QUALITY=0

      COMPORT=3
      SPEED=38400

      PORTCALL=DB0NTS

      CONFIG
        ; dial frequencies with applications
        ; Pactor: dialFreq = centerFreq - 1.5 kHz
        RIGCONTROL
        COM1 9600 ICOM IC7410 0C
        6,3.5904,USB,F2,D,P12,APPL=BBS
        6,3.5915,USB,F2,D,P12,APPL=*RMSHF
        13:00
        6,14.1065,USB,F1,D,P1234,APPL=*RMSHF
        6,14.1089,USB,F1,D,P1234,APPL=BBS
        ****

        ; Winlink reporting
        WL2KREPORT PUBLIC, server.winlink.org, 8085, DB0NTS, JN49MP, 00-12, 3593000, P12, 40
        WL2KREPORT PUBLIC, server.winlink.org, 8085, DB0NTS, JN49MP, 13-23, 14108000, P1234, 40
        WL2KREPORT PUBLIC, server.winlink.org, 8085, DB0NTS-10, JN49MP, 00-23, 438525000, PKT1200, 5

        ; Pactor controller config
        DD
        CLR
        MODE 2
        HCR 0
        CONTYPE 3
        STATUS 1
        CWID 4 0
        TONES 4
        FSKA 390
        PSKA 390
        APOW 0
        ... ... ...
        ... ... ...
        PAC MYALIAS DB0NTS-10
        PAC BAUD 1:1200
        ... ... ...
        ... ... ...
        DRAGON
        MAXLEVEL=4
        DEBUGLOG 0
    ENDPORT

    ; applications
    APPLICATION 1,BBS,,DB0NTS,,0
    APPLICATION 3,RMS,C 1 CMS,DB0NTS-10,,0
    APPLICATION 4,*RMSHF,C 1 CMS

We are looking at the above configuration sample from the perspective of a connecting user.

1. The node command list shows the BBS and the RMS application as additional commands. Note that *RMSHF is not part of the command list because the application name starts with an asterik. The sole purpose of this application is to bind the application command to scanner frequencies. From the node the RMS gateway can either be invoked by entering the RMS command or by connecting to it's application callsign DB0NTS-10. The same goes for the BBS running on DB0NTS.

2. The Dragon packet radio port has two callsign: the PORTCALL DB0NTS and the MYALIAS DB0NTS-10 which are the application callsigns of the BBS and the RMS gateway, respectively. Thus connecting to DB0NTS invokes the BBS and connecting to DB0NTS-10 invokes the RMS gateway. Note that the RMS gateway packet radio frequency and callsign (DB0NTS-10) are reported to WL2K using a WL2KREPORT statement.

3. The Dragon Pactor radio port has a single callsign which is the PORTCALL DB0NTS used for both the BBS and the RMS gateway. To this end scanning frequencies are bound to applications with the APPL keyword and for the RMS gateway the *RMSHF application is used. Note that the scanner configuration and the WL2K reporting match (times, frequencies, modes). Scanner frequencies are dial frequencies (e.g. 3.5915 MHz) whereas WL2K reporting frequncies are centre frequencies (e.g. 3.593 MHz).

The reason for introducing an additional application *RMSHF for the HF RMS gateway is application callsigns. Contrary to the RMS application there is no application callsign configured for *RMSHF and thus the controller's callsign DB0NTS is preserved preventing that an application callsign is set on the stream and shows up in the controller's CWID. When you use APL=RMS in the scanner configuration instead of APPL=*RMSHF the CWID will read DB0NTS-10 (the RMS application callsign) and the SSID may confuse users. As an alternative you may also deactivate the CWID and use APPL=RMS in the scanner configuration instead of *RMSHF.


Related Links