WiFi disconnects after enabling MQTT with default settings

[ne0phyte]

Describe the bug

Opening the MQTT settings, enabling MQTT, not changing any other configuration value and saving that, the robot started disconnecting from WiFi in 20s intervals (with 1-3s inbetween while it reconnected).

The web interface would eventually load but by the time I tried to open any dialog or save any settings it was already not responding to requests anymore or the WiFi connection was completely gone again.

To Reproduce

1. Open web interface
2. Go to Settings
3. Go to MQTT
4. Check "Enabled" checkbox [X]
5. Set Server to "foobar.example"
6. Click "Save MQTT configuration"
7. Wait a few seconds

Screenshots

Vacuum Model

S5

Valetudo Version

Tested on 0.5.2, 0.5.3

Firmware Version

2020, no reset fix

User-Agent

Doesn't matter in this case

Expected behavior

Valetudo should not crash, WiFi should not disconnect.

Additional context

Looks like the example mqtt server host is the cause.
/var/log/upstart/valetudo.log:

[2020-07-19T12:10:44.845Z] [ERROR] MQTT error: Error: getaddrinfo ENOTFOUND foobar2.example
Segmentation fault (core dumped)

Since disabling via webinterface is quite tricky once it's in the reconnect/disconnect tango, you can use this (replace ip) to send the rest request the second it connects to wifi again:

curl 'http://192.168.178.50/api/mqtt_config' -X 'PUT' -H 'Content-Type: application/json' \                                                                                                      
--data-binary '{"enabled":false,"server":"foobar.example","port":"1883","clientId":"","username":"","password":"","usetls":false,"caPath":"","qos":0,"identifier":"rockrobo","topicPre fix":"valetudo","autoconfPrefix":"","provideMapData":false}'

[Hypfer]

Valetudo/lib/MqttClient.js

Lines 209 to 215 in 51a3564

	this.client.on("error", (e) => {
	if (e && e.message === "Not supported") {
	Logger.info("Connected to non standard compliant MQTT Broker.");
	} else {
	Logger.error("MQTT error:", e.toString());
	}
	});

Why is this segfaulting 🤨

[Hypfer]

Okay I've been able to reproduce this. The interesting observation is, that it's not enough to stop/restart Valetudo. Even with it stopped, the robot will continue this endless cycle until it is rebooted:

Jul 20 09:25:48 home dnsmasq-dhcp[31893]: DHCPDISCOVER(enp3s0) 78:11:dc:ff:ff:ff
Jul 20 09:25:48 home dnsmasq-dhcp[31893]: DHCPOFFER(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:25:48 home dnsmasq-dhcp[31893]: DHCPREQUEST(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:25:48 home dnsmasq-dhcp[31893]: DHCPACK(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:08 home dnsmasq-dhcp[31893]: DHCPDISCOVER(enp3s0) 78:11:dc:ff:ff:ff
Jul 20 09:26:08 home dnsmasq-dhcp[31893]: DHCPOFFER(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:08 home dnsmasq-dhcp[31893]: DHCPREQUEST(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:08 home dnsmasq-dhcp[31893]: DHCPACK(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:28 home dnsmasq-dhcp[31893]: DHCPDISCOVER(enp3s0) 78:11:dc:ff:ff:ff
Jul 20 09:26:28 home dnsmasq-dhcp[31893]: DHCPOFFER(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:28 home dnsmasq-dhcp[31893]: DHCPREQUEST(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:28 home dnsmasq-dhcp[31893]: DHCPACK(enp3s0) 10.1.2.3 78:11:dc:ff:ff:ff
Jul 20 09:26:48 home dnsmasq-dhcp[31893]: DHCPDISCOVER(enp3s0) 78:11:dc:ff:ff:ff

Only difference here being that it stays responsive for the most part. I'd guess that's because of the router though.