RIS Live partial message error

[digizeph]

On version eda9e77

limbo@bgpstream-test:~/libbgpstream$ bgpreader -p ris-live
WARN: No time window specified, defaulting to live mode
2020-04-16 12:17:26 32667: bs_format_rislive.c:245: ERROR: Failed to parse RIS Live raw data (Partial Message)
2020-04-16 12:17:26 32667: bs_format_rislive.c:313: WARNING: Corrupted RIS Live message: {"type":"ris_message","data":{"timestamp":1587064364.36,"peer":"91.206.52.201","peer_asn":"210036","id":"20-91-206-52-201-125221","raw":"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF001501","host":"rrc20","type":"NOTIFICATION","notification":{"code":1,"subcode":2,"data":"4F50454E2068617320616E20696E76616C6964206D657373616765206C656E677468206F66203231"}}}

Formatted message:

{
  "type": "ris_message",
  "data": {
    "timestamp": 1587064364.36,
    "peer": "91.206.52.201",
    "peer_asn": "210036",
    "id": "20-91-206-52-201-125221",
    "raw": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF001501",
    "host": "rrc20",
    "type": "NOTIFICATION",
    "notification": {
      "code": 1,
      "subcode": 2,
      "data": "4F50454E2068617320616E20696E76616C6964206D657373616765206C656E677468206F66203231"
    }
  }
}

Also noticed that the time it takes to establish the ris-live connection has been very long sometimes, while directly calling curl command seems to be instantaneous for me.

Related to #116 and #155.

[alistairking]

It's probably not that it takes a long time to establish the connection, but maybe because wandio has rather large buffers that take a while to fill?

[digizeph]

After further investigation, we found that RIS-live server is producing problematic NOTIFICATION messages.

For example, the following message was copied from the ris-live webapp:

{
    "timestamp": 1587142491.92,
    "peer": "2.56.184.254",
    "peer_asn": "54574",
    "id": "24-2-56-184-254-116736",
    "raw": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0015030605",
    "host": "rrc24",
    "type": "NOTIFICATION",
    "notification": {"code":6,"subcode":5,"data":"0605"}
}

The raw message indicate there should be no data value in this notification message, only code and subcode (6 and 5 respectively). However, the JSON object's notification.data mistakenly put the code and subcode hexcode (i.e. 0605). These happens consistently at the time of testing.

In the context of libbgpstream, we currently do not process OPEN, NOTIFICATION, and KEEPALIVE messages. Therefore, in #185 we skip the processing of these messages in ris-live format. From the user's perspective, the aforementioned corrupted message warning for such messages should not appear anymore for ris-live stream.