when i'm listening on wlan0 with tcpdump or even wireshark,
I'm always disconnected in 30s to 5 min.
Do you have any idea how to fix this?
I'm on a debian 64bits, i tryed wpa_spupplicant and network-manager.
Finally after 5 month I found how to fix this issues.
I just have to update my network card drivers (in my case, iwlwifi)
Related
I wonder if others noticed this issue with the WSL2 Debian implementation of TCP.
I am connecting from a Docker container running WSL2 Debian v. 20
The TCP client sends a Keep-Alive packet every second which is kind of overkill. Then after roughly 5 minutes, the client terminates the connection without any reason. Is anybody seeing this behavior?
You can reproduce this by just opening a telnet session to another host. But the behavior happens on other types of sockets too.
And before you ask, this issue is not caused by the server, it does not occur when opening the same tcp connection from other hosts.
wireshark dump of the last few seconds of the idle TCP connection
I had the same problem with Ubuntu on WSL2. An outbound ssh connection closed after a period of time if there was no activity on that connection. Particularly anoying if you were running an application that produced no screen output.
I suspect that the internal router that connects wsl to the local network dropped the idle TCP connection.
The solution was to shorten the TCP keep-alive timers in /proc/sys/net/ipv4, the following worked for me:
echo 300 > /proc/sys/net/tcp_keepalive_time
echo 45 > /proc/sys/net/tcp_keepalive_intvl
So I figured this out. Unfortunately, the WSL2 implementation of Debian seems to have this hardcoded in the stack. I tried to change the parameters of the socket open call and they didn't cause a change in the behavior.
Look at this trace result:
>tracert -d 172.18.0.6
Tracing route to 172.18.0.6 over a maximum of 30 hops
1 2 ms 2 ms 2 ms 192.168.2.1
2 3 ms 3 ms 8 ms 10.11.7.113
3 * * * Request timed out.
You see on the second hop, it's trying to reach an IP that can not see the IP of the running docker image which is 172.18.0.6. I don't know where it is configured.
You may see my docker desktop network config here:
I already whitelisted all possible IPs in the firewall. Also, I have no problem running the images. The images see each other with no problem. But, they can't see the host either.
The Docker Gateway IP is 172.18.0.1 which is whitelisted in the firewall too.
Any help would be appreciated
If someone experiences the same problem, it looks like the problem came with upgrading to the new version of Docker Desktop which was 2.2.0.4.
Even uninstalling and reinstalling that version did not help.
So, I uninstalled the Docker Desktop and re-installed the older version 2.1.0.5. It started working again. There has to be some networking problem with the new versions.
I have faced issues while I want to reload my mosquitto services (MQTT) by /etc/init.d/mosquitto reload.
The MQTT broker doesn't start and I can see my MQTT Port is no longer in netstat.
So far, I only get this following error code that capture from syslog.
segfault at 88 ip 0000000000423f5c sp 00007ffd0f26f530 error 4 in
mosquitto
I am pretty sure the configuration is good to go. However, I faced this issue like yesterday.
I have tried restart the services and yes it worked. But not for reload.
Assuming you are running with mosquitto 1.6.6 then this is a regression that has been fixed in the latest release (1.6.7).
https://mosquitto.org/blog/2019/09/version-1-6-7-released/
Sometimes my ArangoDB is going down with next error:
Error message 'Could not connect to 'tcp://127.0.0.1:8529' 'connect() failed with #10061
I can't understand the reason. It's look like I am turning on my PC and nothing do not work.
Before I fixed this problem with reinstall, but is there any better solution?
OS Windows
ArangoDB 2.8.7
The V8 version used in the pre ArangoDB 3 had occasional troubles in the garbage collection which would make ArangoDB in term go down.
This is fixed with ArangoDB 3.
Please upgrade your installation, and report back whether the problem still persists.
You can use netstat to check whether ArangoDB is listening to its default port 8529:
netstat -a
Active Connections
Proto Lokale Adresse Remoteadresse Status
...
TCP 127.0.0.1:8529 meschenich:0 LISTEN
...
If thats not the case, your client has nothing to connect to.
This could be due to firewall of an antivirus.
In my case it was Avast antivirus that was blocking connecting to that port.
I disabled all the antivirus shields and checked loading arangodb web server
http://127.0.0.1:8529
It connects after few minutes.
Reference : No connection could be made because the target machine actively refused it
I fixed the problem by restarting Windows.
I'm pretty new to icinga so maybe it's only a tiny problem which I don't understand....
I configured a nrpe_check command to monitor a disk on a host. This works pretty good:
nagios#icinga-server: /usr/lib/nagios/plugins/check_nrpe -H host.mydom.com -c check_smart_attributes
OK (sda) |sda_Media_Wearout_Indicator=097;16;6
As you can see, the nrpe connection is working and also the script returns the right data...
But at the icinga-web frontend it says always:
SMART attributes CRITICAL 2014-01-31 09:25:40 0d 1h 21m 6s 4/4 Connection refused by host
Does anyone could help me with this problem?
Tanks, regards
Andreas
Bloody typos...
After a long time and some holidays I solved the problem. I forgot a number at my IP address so it was 123 instead of 23...
Sorry for this bloody typo...
Regards Andreas
check if you did the right thing:
1. /etc/icinga/ host.mydom.com.cfg
2. commands.cfg