Benutzer-Werkzeuge

Webseiten-Werkzeuge


birdnet

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
birdnet [2025/03/22 20:51] varnholtbirdnet [2026/03/07 23:29] (aktuell) varnholt
Zeile 41: Zeile 41:
 firstrun.sh (oha, die ist 72 Zeilen lang) - aber es sieht so aus, als würde doch nur wieder eine /etc/wpa_supplicant/wpa_supplicant.conf angelegt werden firstrun.sh (oha, die ist 72 Zeilen lang) - aber es sieht so aus, als würde doch nur wieder eine /etc/wpa_supplicant/wpa_supplicant.conf angelegt werden
  
-Jetzt gehts an die Micro Probleme. Momentan steckt ein Micro am 3.5mm Klinkeneingang und geht nicht.+Jetzt gehts an die Micro Probleme. Der Raspberry gibt über die 3.5mm Buchse nur Ton aus, man kann kein Mikro anschliessen! Nachdem in meiner Bastelkiste die USB Mikrofonkarten aufgetaucht sind, nehme ich jetzt das Konsolen eye, das sofort geht
 + 
 +Aber die Website geht nur mit ip und nicht (mehr) wie beim LAN mit dem Namen. Mal im Router den Namen eintragen und schauen, was passiertSollte vielleicht auch gehen (nach Neustart) 
  
  
Zeile 53: Zeile 56:
  
 Stand 2025-05 Stand 2025-05
 +
 +Immer mal wieder gab es keine Verbindung zum RaspberryPi, der hinter meinem macOS, der hinter meiner Fritz!Box hängt. Mit einem recht einfachen caddy auf dem raspberry und einem relativ einfachen forward im apache auf dem Mac. Nachdem es mal wieder NICHT ging, kamen Chat und ich darauf (nach längerem versuch, auf Daddy Seite nur ipv4 zuzulassen), dass es auch geht, am Mac retry und RequestHeader möglicherweise geholfen haben.
 +<code>
 +ProxyPass / http://192.168.178.72/ retry=0
 +ProxyPassReverse / http://192.168.178.72/
 +RequestHeader set Host "192.168.178.72"
 +</code>
 +
 +----
 +
 +
 +=== Ping Mac → Raspberry Pi funktioniert nicht ===
 +
 +## Symptom
 +- `ping 192.168.178.72` vom Mac → `Request timeout`
 +- Ping vom Pi zum Mac funktioniert aber
 +
 +## Ursache
 +Wenn der Mac zusätzlich per Ethernet angeschlossen war (beide Interfaces im gleichen Subnetz 192.168.178.x), verwirrt sich macOS beim Routing. Eine manuell hinzugefügte statische Route bleibt dabei als „Leiche" zurück, auch nachdem das Ethernet-Kabel wieder gezogen wurde.
 +
 +## Diagnose
 +```bash
 +netstat -rn | grep 192.168.178.72
 +```
 +Wenn dort so eine Zeile erscheint, ist die kaputte Route noch aktiv:
 +```
 +192.168.178.72/32  192.168.178.1      UGSc    en1
 +```
 +Die IP des Pi wird dann fälschlicherweise über den Router (Gateway) geleitet statt direkt.
 +
 +## Lösung
 +```bash
 +sudo route delete 192.168.178.72
 +```
 +Danach Ping erneut testen – sollte sofort funktionieren.
 +
 +## Wann tritt das auf?
 +Immer dann, wenn der Mac zwischenzeitlich **gleichzeitig per Ethernet und WLAN** im selben Subnetz angeschlossen war.
 +
 +=== Apache Mac → Raspberry Pi funktioniert nicht ===
 +
 +## Symptom
 +Der Aufruf thearkgarden.pikasso.eu.org geht nicht, aber aus dem terminal geht es, oder mit ip oder mit curl -vI http://prebird.fritz.box/ oder curl -v http://192.168.178.72/ -H 'Host: thearkgarden.pikasso.eu.org' IN /etc/hosts den Eintrag prüfen: 192.168.178.72 prebird.fritz.box
 +
 +
 +## Lösung
 +Nach mehreren Stunden 'Problemlösung' mit ChatGPT Pro hat Perplexity Pro geholfen. Es lag an einer falschen Konfigurationsdatei von brew httpd.
 +<code>
 +Homebrew‑Daemon frisch setzen:
 +sudo brew services stop httpd
 +sudo launchctl remove homebrew.mxcl.httpd 2>/dev/null || true
 +sudo brew services cleanup
 +sudo brew services start httpd    # mit oder ohne sudo, je nachdem ob systemweit oder userweit
 +
 +sudo launchctl bootout system/homebrew.mxcl.httpd 2>/dev/null || true
 +sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.httpd.plist
 +</code>
 +
birdnet.1742673109.txt.gz · Zuletzt geändert: 2025/03/22 20:51 von varnholt