Posts by rpi444

Quote from Freddie

Eine Einstellung für die maximale Anzahl von Clients habe ich auch in der manpage von dnsmasq nicht gefunden.

Doch, dort gibt es schon etwas. Es sind 1000 möglich:

Quote

-X, --dhcp-lease-max=<number>Limits dnsmasq to the specified maximum number of DHCP leases. The default is 1000. This limit is to prevent DoS attacks from hosts which create thousands of leases and use lots of memory in the dnsmasq process.

BTW: Zukünftig wird es auch für die Software (Stichwort "green coding") und für die Konfiguration der Dienste einen messbaren CO2-Fußabdruck geben (... und nicht nur für die benutzte Hardware). D. h. es wird immer wichtiger und "trendy", die Konfiguration zu "beherrschen" bzw. zu optimieren.

Quote from bax5000

Reicht es wlan0 durch tun0 zu ersetzen?

Was du noch brauchst ist:

net.ipv4.ip_forward = 1

in der /etc/sysctl.conf.

Wie ist jetzt die Ausgabe von:

sysctl net.ipv4.ip_forward

?

Quote from Reinhart

Hab ich bisher auf einem Raspi v1, zwei Raspi v2 und einem Raspi v3 bemerkt. Bei Lite- als auch bei Desktop-Versionen. Ketzt hab ich auch Bullseye installiert, da ist es auch so.

Ich denke, diese PIs (1 und 2) sind hardwaremäßig zu schwach auf der Brust, für buster und bullseye. Der PI3 wird grenzwertig sein. Teste mal auf deinem PI3 mit dem OS FreeBSD-13 (ohne X-Server, d. h. vergleichbar mit buster-lite).

Quote from Baumkante

Was meinst du mit dd ?

diskdump

Quote from Baumkante

Ich habe auch schon diverse Image Dateien probiert ob Raspbian oder die von Nextcloud aber keine will laufen. Habe die Image Datein mit Etcher und/oder mit dem Raspberry Pi Imager draufgespielt.

Versuch mal mit einer neuen 32GB-SD-Karte und dem aktuellen buster-legacy-lite-Image.

Hast Du evtl. die Möglichkeit, dd zum schreiben (draufspielen) des Images zu benutzen?

Quote from DirkN

echo "E-Mail Text" | mail -s "E-Mail Betreff:testtest" root

Ich dachte Du willst msmtp benutzen, und nicht mail.

Z. B.:

msmtp -a telekom <dst>@web.de < msg.txt

EDIT:

Meine anonymisierte "/home/$USER/.msmtprc"

defaults
tls on
tls_starttls on
tls_certcheck off
auth on
auto_from off
# domain <mydomain>
syslog off
timeout 15
#
# Telekom:
account telekom
host securesmtp.t-online.de
from <user>@t-online.de
user <user>@t-online.de
port 587
password <passwort>

Quote from DirkN

t-online Account angelegt und den mal da eingetragen.

Code

<-- 220 fwd77.t-online.de T-Online ESMTP receiver fmsad ready. / T-Online ESMTP receiver securesmtp.t-online.de ready.
--> EHLO t-online.de

Wie du siehst, ändert der Provider überhaupt nichts an dem Problem, dass die Empfängeradresse nicht von

Zeige mal den vollständigen Befehl den Du zum senden der email benutzt hast.

Quote from bax5000

Wichtig dabei ist eben das der zu erreichende PC ein Programm ausführen muß welches dann erst auf den Server zugreift.

Ich hoffe mein Plan ist verständlich ...

Was genau meinst Du mit "dann erst"? Welche Bedingung soll/muss in Erfüllung gehen, damit der PC das "Programm ausführt"?

Quote from Thor_Sten

Ich habe gestern mal die Karte komplett neu aufgesetzt, anschließend Node-Red installiert und Cronjob und Skripts eingerichtet.

Hast Du die lite-Version installiert oder brauchst Du die Voll-Version?

Ersichtlich sind auch pulseaudio bzw. bluetoothd, etc. auf deinem PI. Brauchst Du all diese (aktiven) Dienste?

EDIT:

BTW: Sniffe mal auf einem anderen Gerät in deinem (W)LAN, ob sich der betroffene PI, mit dem nicht angeforderten arp-reply regelmäßig (via cronjob) bemerkbar macht bzw. zu erkennen gibt:

sudo tcpdump -c 100 -vvveni <Interface> arp[7] = 2 and src host <IP-Adresse-PI>

(Interface bzw. IP-Adresse-PI anpassen und ohne spitze Klammern).

Quote from bax5000

... Buchhaltungsbüro einen vpn-Zugang zu einem PC erstellen. ...

1. Router hat funktionierendes DDNS und ich kann mich per OpenVPN zum Raspi verbinden der im Gäste-WLAN des Routers angemeldet ist.

Warum benutzt Du nicht folgende Konstellation:

- Buchhaltungsbüro ist VPN-Client

- PI ist VPN-Server

- PC ist VPN-Client

und konfigurierst das so, dass die VPN-Clients untereinander kommunizieren können?

Wenn möglich, kannst Du statt OpenVPN auch WireGuard benutzen (weil einfacher zu konfigurieren).

Quote from Bernd666

Da auch der ssh-agent weg ist, kann ja auch nix mehr gehen.

Das verstehe ich jetzt nicht, es geht um den sshd-server. Was soll der (auf dem Server) mit dem ssh-agent zu tun haben. Auf keinem meiner Server ist ein ssh-agent aktiv, aber sehr wohl auf den Desktops.

Quote from Grzegorz

Danke aber ich möchte es extern nutzen, ...

Was genau meinst Du mit extern nutzen?

Es geht nicht um einen PI, es geht darum wie und ob Du mit deinem Mac in der Lage bist, das ext4- bzw. das vfat-Dateisystem zu nutzen.

Quote from Grzegorz

Was mir aber aufgefallen ist nach dem herausholen der SD Karte aus dem Pi sind die ssh und supplicant Dateien weg, ist das normal?

Habe gehört das der Mac Terminal nicht unbedingt geeignet, so habe ich inzwischen iTerm benutzt, nichts ändert sich.

BTW: Du könntest dir für deinen Mac, auf einem USB-Stick ein OS installieren, das mit vfat und ext4 keine Probleme hat. Z. B.: NomadBSD 130R-20210508 (Mac x86-64)

Quote from DirkN

ist jetzt alles aktualisiert, funktioniert aber trotzdem nicht.

Ja, denn auch nach einer Aktualisierung hat msmtp noch immer keine:

ESMTP-Unterstützung

... und das ist das, was gmx haben/sehen will.

Mach dir z. B. nur zum testen einen email-account bei t-online.de und Du wirst sehen, dass es dort mit msmtp funktioniert (weil dort keine esmtp-Unterstützung erforderlich ist).

Quote from Thor_Sten

Da hast Du Recht, aber das wäre nur der Fall, wenn er wirklich abstürzt.

Wäre ein Restart des Netzwerkservice o.ä. nicht auch möglich? Weil die Frage ist doch weiterhin, stürzt der Pi wirklich ab oder ist er nur nicht erreichbar.

Du kannst das Script auch so modifizieren, dass der PI maximal z. B. 3mal rebootet (evtl. im cronjob den Zeitintervall auf z. B. 15 Minuten ändern) und wenn dann der Router noch immer nicht erreichbar ist, beim 4x runter fährt.

Den Netzwerkservice kannst Du auch restarten: Z. B. wenn Du dem PI statische IP-Adressen von außerhalb des DHCP-Pools, mit systemd-networkd zuweist und mit einem Script/cronjob prüfst, ob dem Interface noch eine IP-Adresse zugewiesen ist und wenn nicht, dann systemd-networkd restarten. Aber ich denke, da wird ein restart von systemd-networkd nicht bzw. nie erforderlich sein. Und systemd-networkd dann restarten, wenn das gateway per arp nicht erreichbar ist, wird m. E. nichts bringen.

BTW: Wenn der PI "richtig" abgestürzt ist, wird auch kein cronjob und kein Script mehr funktionieren. Dann kann evtl. nur noch der Hardwarewatchdog "helfen".

EDIT:

Wenn die Dienste die auf deinem PI irgendwann nicht mehr erreichbar sind, mit einer service-unit gestartet werden, kannst Du mit z. B.:

systemctl show <service-unit>

schauen, welcher Ressourcenverbrauch diesen Diensten ermöglicht wird bzw. gestattet ist. Evtl. kannst Du dbzgl. noch etwas optimieren.

Quote from Thor_Sten

Statt dem shutdown -P habe ich aber -r genommen, da ich lieber einen Reboot haben möchte.

BTW: Wenn Du nicht zuhause bist und dein Router (warum auch immer) ausfällt/abstürzt, wird dein PI ständig rebooten. M. E. keine gute Idee.

Quote from Thor_Sten

Arp hatte ich schon gemacht

Es geht um arping bzw. arp-scan:

apt-cache policy iputils-arping arp-scan

Beispiele:

*/3 *    * * *    root    /usr/bin/arping -q -c 2 -w 2 -b -f -I eth0 -s 192.168.178.13 192.168.178.1 > /dev/null 2>&1
*/9 *    * * *    root    /usr/bin/arping -q -c 1 -b -A -I eth0 192.168.178.13 > /dev/null 2>&1

# cat /usr/local/bin/maybe_shutdown
#!/bin/sh -e
#
if /usr/bin/arping -c 5 -I eth0 -f -q -w 5 -s 192.168.178.13 192.168.178.1; then
    exit 0
else
    /sbin/shutdown -P +1
#    
fi
exit 0

# cat /usr/local/bin/restart_sshd
#!/bin/bash -e
#
if /bin/ps -fC sshd > /dev/null 2>&1; then
    exit 0
else
    /bin/systemctl restart ssh
    exit 0
fi
exit 0

*/15 *    * * *    root    /usr/local/bin/maybe_shutdown > /dev/null 2>&1
36 5    * * *    root    /usr/local/bin/restart_sshd > /dev/null 2>&1

Quote from Thor_Sten

PowerOff ist in diesem Fall Stecker ziehen .. anders kriege ich ihn nicht neu gestartet

OK, wenn er komplett abgestürzt ist, ist das mit dem Steckerziehen ja auch nicht schlimm.

Aber da Du das ja nicht weißt, solltest Du Folgendes machen: Wenn möglich nur den Hardwarewatchdog aktivieren.

Wie sind die Ausgaben von:

ls -la /dev/watchdog*
cat /boot/config.txt | grep -i watchdog

... und was viel wichtiger ist, ein Script, dass alle 5 Minuten (per cronjob oder gleichwertig) prüft ob dein PI sein gateway (Router) noch per arping erreichen kann und wenn das nicht der Fall sein sollte, wird der PI ordnungsgemäß runtergefahren (mit shutdown oder gleichwertig), so dass Du dann durch Stromkabel ziehen und einstecken den PI wieder starten kannst. Ob das funktioniert, kannst Du dann testen bzw. reproduzieren in dem Du das Netzkabel ziehst oder das Wlan am Router deaktivierst (je nach dem über welches Interface (eth0 oder wlan0) der arping geht). Besser wäre schon via eth0, denn es ist einfacher das Netzkabel nur am besagten PI zu ziehen, als das Wlan am Router zu deaktivieren (da davon ja auch andere Geräte betroffen sein können).

EDIT:

BTW: Wenn der PI per icmp und tcp nicht mehr erreichbar ist, hast Du schon versucht den PI per arp (z. B. mit arping oder mit arp-scan) zu erreichen?

EDIT 2:

Setze mal auf deinem PI einen cronjob, der alle 2 Minuten einen nicht angeforderten arp-reply ins W/LAN (Subnetz vom Router), als broadcast sendet.

Quote from Thor_Sten

Der Pi hat durch den LAN Adapter ja nun zwei IP-Adressen. Wenn ich PowerOff mache, so wie gestern Abend, dann ist Node-Red über <IP>:1880 erreichbar.

Und irgendwann dann nicht erreichbar, weder per ssh, noch per Seitenaufruf.

Wenn der PI per ssh nicht erreichbar ist, funktioniert dann noch das:

nc -zv <IP-Adresse> 22

? Und das mit beiden IP-Adressen (von wlan0 und von eth0).

BTW: Wie machst Du PowerOff? Denn nach einem poweroff sollte dein PI nicht mehr erreichbar sein.

Quote from juliett-victor

Habe den Fehler gefunden.

Was war der Fehler?