I’m trying to get my Raspberry Pi Zero to work with SSH, to be able to access it remotely.
On a fresh install, I’ve got Dropbear installed, and if I try to connect from the Raspberry itself to its local address (something like ssh 192.168.1.200) it works, but if I try to do the same from another pc on the same network the connection times out.
Even worse than that, I cannot even ping its local address.
Any idea what could be happening?
Can you ping another machine in your local network? Perhaps the router denies local network access for the clients?
I have another Raspberry on the network, which is instead connected through Ethernet, that I can ssh to without any problems.
From what I’ve been reading and experimenting it does seem like Dropbear doesn’t even get any requests, as there’s nothing in its log, but I don’t know what could be preventing the connection to begin with: Dietpi doesn’t have iptables nor ntf installed by default, I just checked.
If the connection was blocked by the RPi, you would see some connection log.
Could you check:
systemctl
dmesg
The first to check if there are any system logs when you attempt to ping/connect.
The second to check if there are any kernel errors or such, wich might be related to failing connection.
But I am pretty sure that it is a network setup issue. Perhaps the WiFi network is separated from the Ethernet one. Are the IPs or the Pi Zero and the other Pi in the same IP range, e.g. 192.168.1.200 and 192.168.1.201?
I assume you meant journalctl? I checked systemctl for completeness sake, but nothing caught my eye there.
In journalctl I noticed that this section is repeated indefinitely:
Detected connection loss: wlan. Reconnecting
ifdown: unknown interface wlan
ifup: unknown interface wlan
Completed
Cannot find device “wlan”
Checking connection for: wlan via ping to
Usage: ping […]
Usage: ping […]
With […] being the man page for ping.
Nothing that I could find on dmesg.
Both the Raspberries, meaning the one connected through Ethernet and the one connected through Wifi, have an address that looks like 192.168.1.X
I also have made it so that the router gives them certain pre-defined addresses so that it’s easier to connect to them, but the problem exists both before and after that change.
riccardo
Ah jep, meant journalctl of course 
.
Okay this helped, the WiFi monitor service seems to check a wrong interface name.
Please do:
systemctl stop dietpi-wifi-monitor
ifup wlan0
In case the second command fails, e.g. you use an external WiFi device while the SBC has an internal one, try
ifup wlan1
The WiFi monitor service gets the interface name via: sed -n 2p /DietPi/dietpi/.network
Could you check the output of this?
If is no integer, most likely 0 or 1, please try:
/DietPi/dietpi/func/obtain_network_details
sed -n 2p /DietPi/dietpi/.network
And check whether now a valid integer is the output.
If this finally succeeded, you can re-enable the WiFi monitor:
systemctl start dietpi-wifi-monitor
I will add updating the network info and checking valid interface name to the script for v6.20.
MichaIng
I think there’s a syntax problem:
sed -n 2p /DietPi/dietpi/.network
says that it can’t find the file, but if I move to /Dietpi/dietpi and then input
sed -n 2p .network
it correctly outputs 0.
That being said, I have followed on your other idea and looked through my router’s configuration and solved my problem by disabling wireless user isolation, which apparently does just what it sounds like it does: prevent any communication between wireless clients.
Thanks for your help, and if you need me to try any other thing on the raspberry pi zero to find out what’s up with that internet interface bug ask away, I’d be glad to help!
Okay, great it works now. But wait:
The directory is called /Dietpi on your system instead of /DietPi (upper case P)?
Just checked, the syntax works well here, generally using the full path or cd to the dir and using file name only, has the same result.
Oh, that’s my bad, I just mistyped…
It works with the absolute path too!
Okay good.
To prevent WiFi monitor from continuously reconnecting, not because of WiFi connection loss, but because of wrong WiFi interface or unplugged WiFi adapters, I made some change to the code: https://github.com/Fourdee/DietPi/commit/72e7c8c37c180f826f32a47a5146e32bac88b02a
It updates now the network info first (check for network adapters and their connection state) and verifies that the found WiFi interface indeed exists, otherwise exits with error output to syslog.
Also when WiFi connection is lost, before attempting automatic reconnection (the intention of DietPi-WiFi-Monitor), it again verifies that the adapter is still plugged/present on the system, otherwise exits with error message to syslog.
But this means, whenever you plug off and on your WiFi adapter on running system, you need to re-enable the WiFi monitor through dietpi-config. But this makes perfectly sense.
Just to be clear, I was not using a plug-in interface, just the internal one.
Not sure if it’s useful info, but I thought it was better to clarify.
Thanks for the info.
I am not sure what caused the wrong /DietPi/dietpi/.network entry or at least WiFi monitor scraping the wrong network interface, but in every case v6.20 will prevent this, instead will throw an error and exit, if no correct interface was found.
RPI 3, inbuilt wifi (wlan0), DietPi v16.7
I just noticed all the wifi-monitor journal chatter too (repeated detected connection loss, down/up with incorrect interface). I disabled wifi-monitor service for now …
I saw the following during startup - Could dietpi-wifi-monitor.sh have something to do with getting wrong interface?
Jan 21 06:45:15 HomePiV3 bash[424]: /var/lib/dietpi/services/dietpi-wifi-monitor.sh: line 5: /DietPi/dietpi/func/dietpi-globals: No
such file or directory
Jan 21 06:45:15 HomePiV3 bash[424]: /var/lib/dietpi/services/dietpi-wifi-monitor.sh: line 7: G_CHECK_ROOT_USER: command not found
Jan 21 06:45:15 HomePiV3 bash[424]: /var/lib/dietpi/services/dietpi-wifi-monitor.sh: line 8: G_CHECK_ROOTFS_RW: command not found
Jan 21 06:45:15 HomePiV3 bash[424]: /var/lib/dietpi/services/dietpi-wifi-monitor.sh: line 9: G_INIT: command not found
Jan 21 06:45:15 HomePiV3 bash[424]: sed: can't read /DietPi/dietpi/.network: No such file or directory
Jan 21 06:45:15 HomePiV3 bash[424]: Cannot find device "wlan"
Jan 21 06:45:15 HomePiV3 bash[424]: Checking connnection for: wlan via ping to
sed -n 2p /DietPi/dietpi/.network returns 0 (zero)
Repeated chatter looks like this
Jan 21 06:46:41 HomePiV3 bash[424]: Cannot find device "wlan"
Jan 21 06:46:41 HomePiV3 bash[424]: Checking connnection for: wlan via ping to
Jan 21 06:46:41 HomePiV3 bash[424]: Usage: ping [-aAbBdDfhLnOqrRUvV64] [-c count] [-i interval] [-I interface]
Jan 21 06:46:41 HomePiV3 bash[424]: [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos]
Jan 21 06:46:41 HomePiV3 bash[424]: [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option]
Jan 21 06:46:41 HomePiV3 bash[424]: [-w deadline] [-W timeout] [hop1 ...] destination
Jan 21 06:46:41 HomePiV3 bash[424]: Usage: ping -6 [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface]
Jan 21 06:46:41 HomePiV3 bash[424]: [-l preload] [-m mark] [-M pmtudisc_option]
Jan 21 06:46:41 HomePiV3 bash[424]: [-N nodeinfo_option] [-p pattern] [-Q tclass] [-s packetsize]
Jan 21 06:46:41 HomePiV3 bash[424]: [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline]
Jan 21 06:46:41 HomePiV3 bash[424]: [-W timeout] destination
Jan 21 06:46:41 HomePiV3 bash[424]: Detected connection loss: wlan. Reconnecting
Jan 21 06:46:41 HomePiV3 bash[424]: ifdown: unknown interface wlan
Jan 21 06:46:42 HomePiV3 bash[424]: ifup: unknown interface wlan
Jan 21 06:46:42 HomePiV3 bash[424]: Completed
Jan 21 06:46:44 HomePiV3 dhclient[809]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 21 06:46:48 HomePiV3 dhclient[809]: No DHCPOFFERS received.
Jan 21 06:46:48 HomePiV3 dhclient[809]: No working leases in persistent database - sleeping.
Jan 21 06:46:52 HomePiV3 dhclient[809]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Jan 21 06:46:52 HomePiV3 bash[424]: Cannot find device "wlan"
Jan 21 06:46:52 HomePiV3 bash[424]: Checking connnection for: wlan via ping to
Jan 21 06:46:52 HomePiV3 bash[424]: Usage: ping [-aAbBdDfhLnOqrRUvV64] [-c count] [-i interval] [-I interface]
Jan 21 06:46:52 HomePiV3 bash[424]: [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos]
Jan 21 06:46:52 HomePiV3 bash[424]: [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option]
Jan 21 06:46:52 HomePiV3 bash[424]: [-w deadline] [-W timeout] [hop1 ...] destination
Jan 21 06:46:52 HomePiV3 bash[424]: Usage: ping -6 [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface]
Jan 21 06:46:52 HomePiV3 bash[424]: [-l preload] [-m mark] [-M pmtudisc_option]
Jan 21 06:46:52 HomePiV3 bash[424]: [-N nodeinfo_option] [-p pattern] [-Q tclass] [-s packetsize]
Jan 21 06:46:52 HomePiV3 bash[424]: [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline]
Jan 21 06:46:52 HomePiV3 bash[424]: [-W timeout] destination
Jan 21 06:46:52 HomePiV3 bash[424]: Detected connection loss: wlan. Reconnecting
Jan 21 06:46:52 HomePiV3 bash[424]: ifdown: unknown interface wlan
Jan 21 06:46:53 HomePiV3 bash[424]: ifup: unknown interface wlan
Jan 21 06:46:53 HomePiV3 bash[424]: Completed
Jan 21 06:46:55 HomePiV3 dhclient[809]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 21 06:46:59 HomePiV3 dhclient[809]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Happy to dig deeper and provide more info as needed
tped
Thanks for the info.
/var/lib/dietpi/services/dietpi-wifi-monitor.sh: line 5: /DietPi/dietpi/func/dietpi-globals: No
such file or directory
Hmm that is strange, since file definitely exists, especially since sed -n 2p /DietPi/dietpi/.network returns the correct value, so the RAMdisk is inplace. Failing on that, the other failures are expected.
To verify:
- You are on DietPi v6.19.7 right?
- You did enable the the WiFi monitor via dietpi-config, right?
- Does sudo /var/lib/dietpi/services/dietpi-wifi-monitor.sh throw the same errors?
This will start the process in foreground, exit by pressing: + - If the above works, check if manually starting the service works as well: systemctl start dietpi-wifi-monitor
- Check systemctl status dietpi-wifi-monitor for any errors after Starting DietPi-WiFi-Mintor…
- Run systemctl stop dietpi-wifi-monitor to stop is again.
- If this works as well, retry via dietpi-config
Sorry for being a bid too much in detail here, by this is help any other, possibly less experienced user to follow 
.
If some failure/error still happens, please try the current dev versions of the service:
Thanks for the detail - I 'll take all the help I can get!
It is Strange indeed … and yes, the /DietPi/dietpi/.network file DOES exist
You are on DietPi v6.19.7 right?
You did enable the the WiFi monitor via dietpi-config, right?
Does sudo /var/lib/dietpi/services/dietpi-wifi-monitor.sh throw the same errors?
This will start the process in foreground, exit by pressing: +
If the above works, check if manually starting the service works as well: systemctl start dietpi-wifi-monitor
Check systemctl status dietpi-wifi-monitor for any errors after Starting DietPi-WiFi-Mintor…
Run systemctl stop dietpi-wifi-monitor to stop is again.
If this works as well, retry via dietpi-config
My todo list:
- DietPi version is 16.19.7 (sorry type-o’ed that before)
- I DID NOT (intentionally) enable Wifi Monitor via DietPi-Config! (Where is that option?)
My WiFi options: Autoreconnect [off], Mode [DHCP], Country [US] - sudo /var/lib/dietpi/services/dietpi-wifi-monitor.sh DOES NOT throw same error - it seems to have correct connection (wlan0)
root@HomePiV3:~# sudo /var/lib/dietpi/services/dietpi-wifi-monitor.sh
[ OK ] DietPi-WiFi-Monitor | Root access verified.
[ OK ] DietPi-WiFi-Monitor | RootFS R/W access verified.
Checking connection for: wlan0 via ping to <my gateway address>
- systemctl start dietpi-wifi-monitor seems to start it fine … output looks same as running it in foreground, no errors
- Not sure how to ‘retry via dietpi-config’ BUT I started the service via “dietpi-services start dietpi-wifi-monitor” and it seems to be working fine! I checked the status using systemctl status dietpi-wifi-monitor
One more quick test …
I rebooted and checked … looks like it is not working
root@HomePiV3:~# systemctl status dietpi-wifi-monitor.service
● dietpi-wifi-monitor.service - Monitors loss of WiFi connection and automatically reconnects
Loaded: loaded (/etc/systemd/system/dietpi-wifi-monitor.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2019-01-21 15:42:38 CST; 2min 35s ago
Main PID: 420 (dietpi-wifi-mon)
CGroup: /system.slice/dietpi-wifi-monitor.service
├─ 420 /bin/bash /var/lib/dietpi/services/dietpi-wifi-monitor.sh
└─1805 sleep 10
Jan 21 15:45:11 HomePiV3 bash[420]: [-w deadline] [-W timeout] [hop1 ...] destination
Jan 21 15:45:11 HomePiV3 bash[420]: Usage: ping -6 [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface]
Jan 21 15:45:11 HomePiV3 bash[420]: [-l preload] [-m mark] [-M pmtudisc_option]
Jan 21 15:45:11 HomePiV3 bash[420]: [-N nodeinfo_option] [-p pattern] [-Q tclass] [-s packetsize]
Jan 21 15:45:11 HomePiV3 bash[420]: [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline]
Jan 21 15:45:11 HomePiV3 bash[420]: [-W timeout] destination
Jan 21 15:45:11 HomePiV3 bash[420]: Detected connection loss: wlan. Reconnecting
Jan 21 15:45:11 HomePiV3 bash[420]: ifdown: unknown interface wlan
Jan 21 15:45:12 HomePiV3 bash[420]: ifup: unknown interface wlan
Jan 21 15:45:12 HomePiV3 bash[420]: Completed
Manually ran sudo /var/lib/dietpi/services/dietpi-wifi-monitor.sh … Ran fine, pinging my gateway again!
Stopped and started the service using dietpi-services and it came up fine
Strange indeed. I wonder where/when/how does /DietPi/dietpi/.network get populated? Especially @ bootime. Could the service start before the file gets built?
I’ll check dev versions, but prob not until tomorrow. Feel free to shoot me more todo’s if you need more info
Hope it helps.
Ah okay, so it works fine now.
/DietPi/dietpi/.network is boot persistent, so as long as nothing changes about the WiFi adapter and gateway it connects to, this should be correct.
It is also generated on boot and whenever on touches network settings via dietpi-config.
And as above updates, the monitor service will now also update the file. /DietPi/dietpi/func/obtain_network_details is the responsible script that checks attached network devices, their connection state, IP, gateway and such, so scripts know which adapter to handle in which way.
It only works if I stop/start the service manually after each reboot
I disabled the service via dietpi-services for now … things are quiet
Where is the wifi-monitor option in dietpi-config?
Ah sorry, I was not reading carefully. Will run some other tests here. Perhaps the boot script, rewriting /DietPi/dietpi/.network and the monitor reading it somehow interfere, so we need to start the script at a later boot state be avoid this.
Usually you would enable/disable it via: dietpi-config > Network Options (Adapters) > WiFi > WiFi monitor
Not sure about the last two menu entry names, my WiFi test system currently not up, but by should be something like this by meaning 
.
I opened an issue on GitHub to collect some commits and info. I think that should solve it, but will run some tests with different boot orders to exclude other interferences: https://github.com/Fourdee/DietPi/issues/2434
tped
If you find time, would be great if you could test them as well, since every system/network adapter behaves a bid different:
wget https://raw.githubusercontent.com/Fourdee/DietPi/dev/rootfs/etc/systemd/system/dietpi-wifi-monitor.service -O /etc/systemd/system/dietpi-wifi-monitor.service
wget https://raw.githubusercontent.com/Fourdee/DietPi/dev/rootfs/var/lib/dietpi/services/dietpi-wifi-monitor.sh -O /var/lib/dietpi/services/dietpi-wifi-monitor.sh
chmod +x /var/lib/dietpi/services/dietpi-wifi-monitor.sh
systemctl daemon-reload
Probably worth mentioning - I don’t see the Wifi-monitor option in dietpi-config. I double/triple checked dietpi version, even did a dietpi-update to be safe, but no updates required - I am indeed on v6.19.7. dietpi-config wifi options look a little like this:
●─ Basic Options ───────────────────────●
Scan : Scan and configure SSID
Auto Reconnect : [On]
●─ DHCP/STATIC IP ──────────────────────●
Change Mode : [DHCP]
●─ Additional Options ──────────────────●
Country : [US]
●─ Toggle State ────────────────────────●
Disable : Disable WiFi adapter
●─ Apply ───────────────────────────────●
Apply : Save all changes and restart networking
I also downloaded and swapped in the new dietpi-wifi-service per yesterday’s instructions
it’s REALLY quiet now - here’s chatter since last reboot
root@HomePiV3:~# systemctl status dietpi-wifi-monitor.service
● dietpi-wifi-monitor.service - DietPi-WiFi-Monitor
Loaded: loaded (/etc/systemd/system/dietpi-wifi-monitor.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-01-23 06:20:34 CST; 34min ago
Process: 1022 ExecStartPre=/bin/bash -c [[ -e /sys/class/net/wlan$(sed -n 2p /DietPi/dietpi/.network) ]] (code=exited, status=0/SU
CCESS)
Process: 905 ExecStartPre=/DietPi/dietpi/func/obtain_network_details (code=exited, status=0/SUCCESS)
Main PID: 1027 (dietpi-wifi-mon)
CGroup: /system.slice/dietpi-wifi-monitor.service
├─1027 /bin/bash /var/lib/dietpi/services/dietpi-wifi-monitor.sh
└─5675 sleep 10
Jan 23 06:20:34 HomePiV3 systemd[1]: Starting DietPi-WiFi-Monitor...
Jan 23 06:20:34 HomePiV3 systemd[1]: Started DietPi-WiFi-Monitor.
Jan 23 06:20:34 HomePiV3 dietpi-wifi-monitor.sh[1027]: [56B blob data]
Jan 23 06:20:34 HomePiV3 dietpi-wifi-monitor.sh[1027]: [62B blob data]
Jan 23 06:20:53 HomePiV3 dietpi-wifi-monitor.sh[1027]: Checking connnection for: wlan0 via ping to default gateway every 10 seconds
tped
Its the Auto Reconnect : [On] option, so jep enabled and running.
So seems now it is really running (and starting on reboot) as intended 
. Jep it should be quiet until a connection loss is detected and reconnection attempted, so it does not spam journalctl/syslog every 10 seconds, if everything is actually fine.
If your device (or WiFi AP) is mobile, you could move one out of range, wait there for at least 10 seconds and move it in range again. The service should then automatically reconnect after another maximum of 10 seconds (tick rate).
More verbose output is done when passing G_DEBUG=1 as variable. Should be not required, besides for testing reasons. If you want to pass that variable to the systemd unit to see the script doing it’s connection check every 10 seconds:
Put Environment=G_DEBUG=1 to into it’s [Service] section, systemctl daemon-reload to reload the unit and systemctl restart dietpi-wifi-monitor.
Btw: Many thanks for all the testing and feedback !