The channel has a static IP address, but a static address is vulnerable to a DDoS attack.
The goal is to minimize the impact of a theoretical DDoS attack on an gateway IP.
Thus, we took the very first step to replace the static IP address of the channel with a personal DNS record.
The panel now displays the channel URI as a DNS record.
We recommend that you use a DNS record for all future connected devices and, if possible, reconfigure existing ones.

adsa

As a part of our anti-DDoS preventive measures we are softly switching from IP-based channel specification to DNS-based. Each channel is assigned its unique DNS record in form {channel-id}.flespi.gw. Currently it is resolved as a CNAME type record to gw.flespi.io for EU region and ru-gw.flespi.io for RU region which by itself are A-type records to the underlying IP address which was recently a part of channel’s URI.

It means that except the visualization part currently there are no actual changes occurred in the endpoint where to connect your telematics devices. However we strongly recommend you to update the server address of your devices from IP-based format to the new DNS format as proposed by the channel uri property.

In case of any kind of DDoS attack we will immediately manipulate with these DNS records to reroute devices to different multiple IP addresses and save and secure the traffic from your devices. If you use the DNS address of your channel you will be safe. If you use an old fashioned IP address - the traffic from your devices may be blocked for some period of time.

Moreover later we will introduce more IP addresses for communication with devices and even may install and rotate channel listeners in different datacenters to improve reliability and performance. Please use the DNS name of your channel everywhere and together with flespi prepare for the future.

For all new channels created from this point of time, with ID higher then 18000 for RU region and 22000 for EU region we expect that the devices connect to DNS name and we may further change IP address it points to without additional notice. Please be aware.

      18 days later

      We have added an "IP whitelist" optional property to the all channels configuration, where the channel is dealing with incoming connections (most of the protocols at this time).
      Now you may set a comma-separated list of IP addresses (or a wildcard-masks like 192.168..) to allow incoming connections only from such IP addresses.
      scr

      20 days later

      One of flespi access methods - pull based access to channel messages via REST API will update range values of some input parameters from 32-bit unsigned integer to 64-bit unsigned integer.

      Methods and parameters affected:

      In most processing systems these methods will continue to operate as is, cause in Javascript, Python and most of other languages there is no specific datatype for number limitation up to 64-bit.

      This message for you is just a notice to check your code and prepare for the upcoming update from flespi side.

        6 days later

        shal We upgraded curr_key/delete_key precision from 32-bit to 54-bit to preserve compatibility with javascript. The update has been installed, please check if your code is OK if you rely on the updated REST API methods.

            shal One additional update: we lowered returned key value from 54-bits to 53-bits and suggest you to restart your consumers for GET /gw/channels/messages API method users, if any.

                6 days later

                • shal

                • Post #29
                • Edited

                We released the second version of the plugin system to extend device functionality. All plugins for the initial release (the first version of plugins system) were converted into this new one and messages flow should be unaffected.

                From that moment we will add features to it on a constant basis. Plugins system is still considered experimental at the moment and thus we may introduce changes to its API without prior notice.

                In short, plugins allow you to define extra fields to messages published to devices. You define the schema of each plugin and its fields (name, parameter alias, actions with fields - store in the database, publish to MQTT, publish to device telemetry, etc) and after that, you may add devices to the plugin by filling their fields.

                Plugins can be used just to store and reference any extra information about the device and use it with REST API selectors. E.g. to extend each device with special customer number, plate number, or even to add a phone number or SIM ICCID.

                Some plugins, which are part of a complex pipeline process, like tollbg are available as a template making it simple to create and use them in one click.

                REST API is available here. You may read about associated plugins GUI changes here.

                We plan later to publish a few articles in our blog covering the most popular use cases for the plugins.

                We also plan later introduce plugins to other types of flespi entities, e.g. channels.

                Be aware that the number of plugins you may create is limited by your flespi plan. Free flespi users can create just one plugin. And Commercial flespi users have two plugins included in the base package and each extra plugin will cost $20.

                  12 days later

                  We implemented special REST API method to move device between various flespi accounts: PUT /gw/devices/{devices-selector}/cid

                  This is quite a complex method and may be used by our commercial users that can organize their flespi account into subaccounts hierarchy on a per-project basis and to distribute devices between subaccounts persisting their settings, storage, calculation and streaming configurations.

                  We do not plan to add button to call this method from GUI at the moment - it will remain available only via REST API.

                  2 months later

                  • shal

                  • Post #31
                  • Edited

                  Please take a look at flespi database changelog message as it may affect the operation of the flespi telematics hub for you. We ensure our users to test their integrations and keep an eye on it during the transition period.

                    • kial

                    • Post #32

                    We've added the last_active field to the devices in the REST and MQTT. This field contains a timestamp where the platform received the last data piece from device over TCP/UDP/etc.
                    This field can be used to determine "alive" devices working over UDP or other connectionless transports.

                    • kial

                    • Post #33
                    • Edited

                    Dear flespi users!

                    We're announcing an upcoming change in the output of the REST API method GET /gw/devices/<selector>?fields=settings

                    For now, the output of this request contains an array with device settings as a JSON object, and every object contains such fields:

                    • address
                    • current
                    • mode
                    • pending
                    • schema
                    • tab
                    • tags
                    • updated

                    Next week, on August 28 the following fields will be removed from this list:

                    • address
                    • mode
                    • schema
                    • tab
                    • tags

                    All these fields can be obtained using another REST API request: GET /gw/protocols/all/device-types/<device-type-id-from-device>?fields=settings

                    8 days later

                    Dear flespi users!

                    We've installed the update mentioned above: kial

                        24 days later

                        • adsa

                        • Post #35
                        • Edited

                        We are going to rename "gw/protocols" to "gw/channel-protocols". This will allow us to implement other protocol entities such as "gw/stream-protocols" etc. REST API methods based on "gw/protocols" are deprecated and will be removed on November 23rd.

                        List of affected methods:

                        Get protocols matching filtering parameters. Deprecated method:
                        GET /gw/protocols/{protocol-selector}
                        New method:
                        GET /gw/channel-protocols/{protocol-selector}

                        Get commands supported by protocol. Deprecated method:
                        GET /gw/protocols/{protocol-selector}/commands/{protocol-cmds-selector}
                        New method:
                        GET /gw/channel-protocols/{protocol-selector}/commands/{protocol-cmds-selector}

                        Get device types supported by protocol. Deprecated method:
                        GET /gw/protocols/{protocol-selector}/device-types/{devtypes-selector}
                        New method:
                        GET /gw/channel-protocols/{protocol-selector}/device-types/{devtypes-selector}

                        25 days later

                        • adsa

                        • Post #36
                        • Edited

                        We are introducing a new REST entity called stream-protocols. The purpose and use of this entity is exactly the same as the previously mentioned channel-protocols:
                        curl -X GET --header 'Authorization: FlespiToken XXXX' https://flespi.io/gw/stream-protocols/all

                        To create a new stream, you must get the available protocols, and then pass the identifier of the desired one to the stream configuration:
                        curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{},"protocol_id":1}]' 'https://flespi.io/gw/streams'

                        By the way, the legacy format is still available until December 16:
                        curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{"protocol" : "http"}}]' 'https://flespi.io/gw/streams'

                        a month later

                        • adsa

                        • Post #37

                        adsa Deprecated REST API methods have been removed.

                            • namo

                            • Post #38

                            This is to announce an important update of azure_iot stream implementation.
                            Update is planned for Monday, 30-Nov-2020 12:00 UTC

                            property_bag with Content -Type=application/json and Content-Encoding=utf-8 will be added to IoT Hub MQTT topic name. This will prevent base64 encoding of message body at Azure side.

                            Example of Azure event message before and after the update illustrates the upcoming change:

                            • before:
                              {
                              "EnqueuedTimeUtc": "2020-11-25T12:24:40.7280000Z",
                              "Properties": {},
                              "SystemProperties": {
                              "connectionDeviceId": "namo-device1",
                              "connectionAuthMethod": "{\"scope\":\"hub\",\"type\":\"sas\",\"issuer\":\"iothub\",\"acceptingIpFilterRule\":null}",
                              "connectionDeviceGenerationId": "637418276273362219",
                              "enqueuedTime": "2020-11-25T12:24:40.7280000Z"
                              },
                              "Body": "eyJiYXR0ZXJ5LmxldmVsIjo5OSwiY2hhbm5lbC5pZCI6MTE3ODEsImRldmljZS5pZCI6MTMwNzI0MSwiZGV2aWNlLm5hbWUiOiJuYW1vIHdpYXRhZyIsImRldmljZS50eXBlLmlkIjoxOCwiZ3NtLmNlbGxpZC4xIjoxMzk1MywiZ3NtLmxhYy4xIjoxMDQwMSwiZ3NtLm1jYy4xIjoiMjQ2IiwiZ3NtLm1uYy4xIjoiMiIsImdzbS5uZXR3b3JrLm5hbWUiOiJmdXNlZCIsImlkZW50IjoibmFtbyIsInBlZXIiOiI3OC41OS4xMjQuMjA0OjE0MzAiLCJwb3NpdGlvbi5hbHRpdHVkZSI6MTkyLjIwMDAxMiwicG9zaXRpb24uZGlyZWN0aW9uIjo1NCwicG9zaXRpb24uaGRvcCI6MjQuMjYxOTk5LCJwb3NpdGlvbi5sYXRpdHVkZSI6NTQuNzAyMDIxLCJwb3NpdGlvbi5sb25naXR1ZGUiOjI1LjIzMTUzNywicG9zaXRpb24uc2F0ZWxsaXRlcyI6OSwicG9zaXRpb24uc3BlZWQiOjAsInByb3RvY29sLmlkIjoxMSwic2VydmVyLnRpbWVzdGFtcCI6MTYwNjMwNzA3OS4xNTgxNCwidGltZXN0YW1wIjoxNjA2MzEwNjQyfQ=="
                              }
                            • after:
                              {
                              "EnqueuedTimeUtc": "2020-11-25T12:43:25.3050000Z",
                              "Properties": {},
                              "SystemProperties": {
                              "connectionDeviceId": "namo-device1",
                              "connectionAuthMethod": "{\"scope\":\"hub\",\"type\":\"sas\",\"issuer\":\"iothub\",\"acceptingIpFilterRule\":null}",
                              "connectionDeviceGenerationId": "637418276273362219",
                              "contentType": "application/json",
                              "contentEncoding": "utf-8",
                              "enqueuedTime": "2020-11-25T12:43:25.3050000Z"
                              },
                              "Body": {
                              "channel.id": 103,
                              "custom.s_on": 0,
                              "device.id": 171,
                              "device.name": "namo wiatag",
                              "device.type.id": 1,
                              "ident": "namo",
                              "peer": "127.0.0.1:33016",
                              "protocol.id": 1,
                              "server.timestamp": 1606307390.550142,
                              "timestamp": 1606310980
                              }
                              }
                            19 days later

                            • adsa

                            • Post #39

                            adsa

                            The new REST API for streams was announced a few months ago, and the new and old format were available until mid-December.
                            The obsolete format has now been removed and is no longer supported.

                            Please let us know if you have any problems with streaming.

                              9 days later
                              a month later
                              11 days later

                              • omol

                              • Post #42
                              • Edited

                              Support of self-signed certificates for third-party servers will be discontinued in 1 week (on February 17). MQTT channels and streams now support custom root certificates (ca field in configuration object) so you can use this option for proper and fully secure TLS/SSL usage.