UDP endpoint always connected

[roughnecks]

Describe the bug

I set up a udp endpoint to check ETS2 Dedicated Server. If I stop ETS2 the endpoint still shows the service as connected.

What do you see?

No response

What do you expect to see?

I'd expect it to fail when the service is not running.

List the steps that must be taken to reproduce this issue

1. Start ETS2
2. Add this config to config.yaml

  - name: euro truck sim 2
    group: game
    url: "udp://IPADDRESS:27016"
    interval: 60s
    conditions:
      - "[CONNECTED] == true"
    alerts:
      - type: email
        description: "healthcheck failed"
        send-on-resolved: true     

3. Monitor it, is up
4. stop ETS2
5. monitor it, it's still up for gatus

Version

GO

Additional information

No response

[Katzenbiber]

I have the same issue with TeamSpeak3. Additionally, the ping times seem unreasonably low with 17ms Europe <-> USA, while normal HTTP trafic takes around 300ms.

[lefes]

@TwiN Hello! Can you assign this issue to me? I’ll try to solve it.

[Katzenbiber]

I just tested if gatus even sends anything with Wireshark. No wonder there's something wrong, there is literally no packets sent xD

[Katzenbiber]

Ok, I tried sending just some random bytes over UDP, but at least Teamspeak doesn't react to it. It strengthens my suspision, that you wouldn't be able to make a generic UDP endpoint tester, as the protocol is different from program to program.

In theory you could make it send a configurable message which you would expect a response for, and look if the response actually comes back.

[lefes]

Ok, I tried sending just some random bytes over UDP, but at least Teamspeak doesn't react to it. It strengthens my suspision, that you wouldn't be able to make a generic UDP endpoint tester, as the protocol is different from program to program.

In theory you could make it send a configurable message which you would expect a response for, and look if the response actually comes back.

I agree with you. It seems the UDP endpoint checker is not functioning correctly in this case. A better solution would indeed be to add an option to configure a specific message to check the availability of the service, as you suggested. The default value for this message could be an empty string.

I will work on implementing this feature.

[lefes]

@Katzenbiber, I’ve done some more research, and it seems to be a more complex problem. For example, we cannot trigger a UDP port with simple plain text on Teamspeak due to the binary protocol. It seems more logical to monitor these services using other ports (like TCP) or by checking the status of the daemon or containers. Implementing a body to check the response doesn’t make any sense. :(

[Katzenbiber]

@lefes, thank you for putting in your effort. Yeah, completely agree, either we would have to reverse-engineer every protocol we want to support or make a system flexible enough to let people insert their own protocol into gatus.

@TwiN Do you have any input as to where you want this feature to be going? As far as I can tell, the feature is broken (and hasn't worked probably ever).

[TwiN]

@lefes, thank you for putting in your effort. Yeah, completely agree, either we would have to reverse-engineer every protocol we want to support or make a system flexible enough to let people insert their own protocol into gatus.

@TwiN Do you have any input as to where you want this feature to be going? As far as I can tell, the feature is broken (and hasn't worked probably ever).

Personally, I would want this feature to work - at least to some extent.

If you want to give it a shot, I'd be more than happy to guide you!