FHEM hinter Proxy

[Engel]

Moin liebe FHEM-Community,

ich bin zwar neu hier im Forum, aber mit FHEM seit fast 2 Jahren vertraut.
Nun hat sich mir aber ein bislang unüberwindbares Problem aufgetan:

Wie konfiguriere ich FHEM, so dass das System auch hinter einem (Firmen-)Proxy läuft?
D.h. es soll das Update funktionieren und auch Module wie Weather oder HTTPMOD.
Ich habe schon viel im Forum gelesen und leider nur eine Info über Socket-Kommunikation (HTTPUtils) gefunden. Genau diese blockiert der Proxy.

Derzeit habe ich einen RasPi 3 mit Rasbian Jessi lite und FHEM aufgesetzt.
Zudem habe ich CNTLM aufgesetzt und Aptitude mit den nötigen Proxy-Einstellungen versorgt.

Damit funktionieren UPDATE, WEATHER und HTTPMOD leider nicht :-(

Arbeitet FHEM tatsächlich mit Socket-Kommunikation?
Wo kann ich in FHEM Proxy-Einstellungen vornehmen?

Vielen Dank und Gruß,
Engel

[rudolfkoenig]

Die meisten Module in FHEM verwenden das FHEM-Eigenen HttpUtils.pm, und der kennt sich (noch) mit Proxy nicht aus.

Ich bin bereit das zu aendern, allerdings bin nicht sicher, ob ich ein Proxy zwecks Testen aufstellen will, deswegen waeren mir Patches lieber. Da ich mich bisher mit Proxies nicht beschaeftigt habe: setzt man dabei einen "normalen" HTTP-Request ab, es geht bloss nicht an dem Adressaten, sondern an den Proxy? Muss man sonst was noch ins Header schreiben?

Arbeitet FHEM tatsächlich mit Socket-Kommunikation?

Ja. Was auch immer mit der Frage gemeint war

[justme1968]

was denn sonst ausser sockets? neben sockets und files gibt es nichts mehr das noch relevant ist oder?

auch http ist ein protokoll das über sockets geht. und sogar IPoAC kommt nicht ohne aus .

[CoolTux]

Was ist das denn für ein Proxy der http oder https blockiert?
Ist das ein reiner Mailproxy?
Ich betreibe selber ein Proxy vorm FHEM. Du gibst einfach im Betriebssystem (Linux) an das Du einen Proxy hast und schon werden die entsprechenden Protokolle über den Proxy geleitet.

[rudolfkoenig]

Du gibst einfach im Betriebssystem (Linux) an das Du einen Proxy hast und schon werden die entsprechenden Protokolle über den Proxy geleitet.

D.h. entweder connect(2) oder gethostbyname(3) "luegt"? Kommt mir komisch vor, ich haette eine Unterstuetzung vom Programm erwartet. Laeuft bei dir das FHEM-update uebers Proxy?

[CoolTux]

Ja, wobei ich da sagen muß, dadurch das das Update eine http Anfrage ist kommt die sowieso zum Proxy und damit durch. Ist ein transparenter Proxy. Nur https oder ftp müssen explizit im profile script mit angegeben werden.

[CoolTux]

Code: [Auswählen]

cat /etc/profile.d/system_proxy.sh


Code: [Auswählen]

export https_proxy=http://pi-proxy01:3128
export ftp_proxy=http://pi-proxy01:3128


[justme1968]

ganz so einfach ist das nicht

es gibt zwei arten von proxy:
- transparent die greifen auf netzwerk/firewall/... ebene ein und sind (mehr oder weniger) unsichtbar
- 'normale' proxies konfiguriert werden müssen und für die der client unterstützung explizit implementieren muss weil er aktiv
  die verbindung zum proxy statt zum eigentlichen ziel aufbauen muss.
  wie diese konfiguration genau passiert hängt vom client ab.

  im http rfc steht etwas zu proxies.

[Engel]

Vielen Dank für die Rückckmeldungen 

Es ist ein aktiver Proxy, der Zugriffe auf bestimmte Seiten sperrt wie z.B. private Mail oder auch indizierte Seiten.

Die Einstellungen, die CoolTux in die system_proxy.sh geschrieben hat, habe ich schon gesetzt.

Ohne diese Einstellungen funktioniert wget nur mit dem Zusatz "-e use_proxy=yes" und der Angabe des Proxy "-e http_proxy=127.0.0.1:3128".
Hinter "127.0.0.1:3128" verbirgt sich CNTLM. CNTLM "ergänzt" für den eigentlichen Proxy die Credentials (Username und Passwort)

Ein Update in FHEM funktioniert nicht 
Resultat: http://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: Bad hostname 'fhem.de:80'

Ein wget auf die Datei funktioniert.

[TL]

Moin!

Die meisten Module in FHEM verwenden das FHEM-Eigenen HttpUtils.pm, und der kennt sich (noch) mit Proxy nicht aus.

Ich bin bereit das zu aendern, allerdings bin nicht sicher, ob ich ein Proxy zwecks Testen aufstellen will, deswegen waeren mir Patches lieber. Da ich mich bisher mit Proxies nicht beschaeftigt habe: setzt man dabei einen "normalen" HTTP-Request ab, es geht bloss nicht an dem Adressaten, sondern an den Proxy? Muss man sonst was noch ins Header schreiben?

Ich habe auch das Problem, dass hinter meinem Proxy (Squid) leider im Bezug auf FHEM einiges nicht funktioniert. Daher wäre es wirklich toll, wenn sich das ändern würde!

Habe daher gerade mal mit dem Wireshark nachgeschaut - es ist genau, wie Du schreibst: Der Header ändert sich nicht, Du musst nur die Pakete an die Adresse und den Port schicken, die z.B. in den Environment-Variablen http_proxy / https_proxy / ftp_proxy hinterlegt sind. Das müsste eigentlich schon alles sein. Falls der proxy eine Authentifizierung mit Username/Passwort verlangt, wird wohl komplizierter, aber das habe ich zumindest nicht eingerichtet. Für die meisten würde das oben beschriebene vermutlich ausreichen.


Edit: Die Env-Variable "no_proxy" müsste wohl auch noch berücksichtigt werden.

Viele Grüße,
   Thomas

[Prof. Dr. Peter Henning]

Der bessere Weg ist, vom lokalen Rechner einen SSH-Tunnel auf die Firewall aufzumachen - damit ist der Proxy in der Regel auch umgangen. Mit diesem SSH-Tunnel können beliebige Ports externer Rechner auf den internen Rechner gemappt werden. Nicht nur zum Update von FHEM, sondern auch für andere Zwecke sehr hilfreich.

LG

pah

[TL]

Moin!

Der bessere Weg ist, vom lokalen Rechner einen SSH-Tunnel auf die Firewall aufzumachen - damit ist der Proxy in der Regel auch umgangen. Mit diesem SSH-Tunnel können beliebige Ports externer Rechner auf den internen Rechner gemappt werden. Nicht nur zum Update von FHEM, sondern auch für andere Zwecke sehr hilfreich.

Könntest Du das bitte für mich einmal genauer ausführen? Meine Netzwerkumgebung sieht grob ungefähr so aus:


   FHEM-
   Update- ______Internet_____Router_____Firewall_____Proxy_____Lokales FHEM
   Server

(Router, Firewall,Proxy und lokales FHEM sind jew. eigenständige Rechner. Mindestens der Proxy-Server macht kein IP-Forwarding von IP-Paketen.)

Wie sollte mir jetzt ein SSH-Tunnel dabei helfen, vom lokalen FHEM aus den FHEM-internen Update-Befehl durch den Proxy zu bringen? Wie müsste der ssh-Befehl dafür genau aussehen?

Viele Grüße,
   Thomas

[Engel]

Moin zusammen,

zunächst möchte ich allen FHEM-Entwicklern und -Usern ein frohes neues Jahr wünschen.

Nachdem ich die Arbeit letztes Jahr unterbrechen musste, habe ich mich nun weiter an die Analyse gemacht.

Zunächst habe ich exemplarisch ein wget auf query.yahooapis.com gemacht. Alles in Ordnung, da (wie im Browser auf einem anderen Rechner) HTTP 400 zurück geliefert werden. Ein wget auf fhem.de funktioniert auch ohne Probleme.

Dann habe ich via fhem eine Anfrage an query.yahooapis.com ausgelöst. Der Proxy antwortet auf eine DNS-Anfrage mit einer Antwort (A Record), die einen Authoritative Nameserver als SOA enthält. Ferner wird sofort versucht die Adresse durch Anhängen einer erweiteren Adresse aufzulösen.

Im Log von FHEM stehen die Einträge "gethostbyname query.yahooapis.com failed". Mir ist noch unklar, warum die Methode "gethostbyname" fehl schlägt ...

Leider fehlt mir ein wenig Handwerkszeug zum Debuggen der HttpUtils. Ich bin mit perldebug nicht vertraut und google hat auf die Schnelle nicht weiter helfen können.
Könnte mir jemand eine kurze Erläuterung geben, wie ich im Umfeld von FHEM einzelne Module oder speziell HttpUtils mit gethostbyname debuggen kann?

Vielen Dank für die Unterstützung
Engel

[rudolfkoenig]

Die einfachste Version ist "attr global verbose 5".
Etwas aufwendiger: an strategischen Stellen in HttpUtils.pm eine

Code: [Auswählen]

Log 1, "XXX: $XXX";Zeile einstreuen. Dabei kann man fuer komplexe Datenstrukturen auch

Code: [Auswählen]

Log 1, "XXX: ".Dumper($XXX);verwenden, muss man aber einmal oben

Code: [Auswählen]

use Data::Dumper; dazupacken.

Achtung: falls man die Variable "attr global dnsServer a.b.c.d" setzt, dann verwendet HttpUtils statt gethostbyname die eigene, nicht blockierende Implementierung.

[Engel]

So, nun habe ich mich ausführlich mit HttpUtils beschäftigt.
@Rudolf: Vielen Dank für den Support

Inzwischen habe ich eine Version erstellt, die mit und ohne Proxy eingesetzt werden kann. Unterstützt werden http- und https-Anfragen.
Der Proxy wird nur angesprochen, wenn er in der fhem.cfg eingerichtet ist. Zusätzlich wird CNTLM benötigt.

Probleme habe ich noch mit zwei neu eingeführten globalen Variablen (proxyHost & proxyPort): Wo müssen diese eingetragen werden, damit die Warnungen verschwinden?

Ich würde gern meine Weiterentwicklung zurück fließen lassen. Das es sich um eine wichtige Komponente handelt, natürlich nicht ohne Review. Testen konnte ich die Klasse nur eingeschränkt mit meinen Setups mit und ohne Proxy.
Muss ich meine Änderungen nun in ein git einstellen?

[CoolTux]

Du erstellst ein Patch und lässt ihn Rudi zukommen.

[TL]

Moin!

...

Ich würde gern meine Weiterentwicklung zurück fließen lassen. Das es sich um eine wichtige Komponente handelt, natürlich nicht ohne Review. Testen konnte ich die Klasse nur eingeschränkt mit meinen Setups mit und ohne Proxy.
Muss ich meine Änderungen nun in ein git einstellen?

Testen würde ich sehr gern - wenn ich helfen kann, sag' bitte Bescheid... 

Viele Grüße,
   Thomas

[Sebastian J]

Gibt es irgendwo diesen Patch zum Download ?
Oder ist er schon in der Aktuellen Version integriert ?
Wie müssen die Einträge in der fhem.cfg aussehen ?

Vielen Dank im Voraus.

[CoolTux]

Habe gerade mal geschaut. Im Code des aktuellen Modules gibt es keine Proxy Implementierung.
Schnelle Lösung wäre hier wohl ein transparenter Proxy

[Engel]

Meine Implementierung läuft nun seit geraumer Zeit ohne Fehler.

Wo finde ich im Forum eine Anleitung zu "Du erstellst ein Patch und lässt ihn Rudi zukommen"?

[CoolTux]

Wie man ein Patch erstellt findet man zahllos im Internet. Und dann entweder hier anhängen oder Rudi direkt senden. Natürlich sollte der Patch auf Codebasis des aktuellen HttpUtils Modul basieren.

[Benni]

Wo finde ich im Forum eine Anleitung zu "Du erstellst ein Patch und lässt ihn Rudi zukommen"?

Nicht im Forum, aber im Wiki: https://wiki.fhem.de/wiki/How_to_write_a_patch

[Engel]

So, hier mein erster Versuch eines Patches auf Basis der aktuellen Code-Basis.
Ich bin gespannt auf ein Feedback und hoffe, dass es auch anderen Nutzern weiter hilft.

Über eine Info, wie oder wo die zwei neu eingeführten globalen Variablen (proxyHost & proxyPort) eingetragen werden müssen, damit die Warnungen verschwinden, wäre ich dankbar.

[michiatlnx]

Hallo,

nach dem patchen der HttpUtils, habe ich bei mir noch die fhem.pl erweitert danach war bei mir die Fehlermeldungen weg und die proxyHost proxyPort sind in der global Attr List auswählbar:
/opt/fhem/fhem.pl
my @globalAttrList = qw(
  ...
+  proxyHost
+  proxyPort
  ...

Ein Update check ging aber nicht und bekomme die Meldung HTTP/1.0 400 Bad Request und X-Squid-Error: ERR_INVALID_REQ 0
Den fhem log Ausschnitt habe ich drangehängt.

[Prof. Dr. Peter Henning]

Eine Veränderung der fhem.pl  ist vollkommen unnötig.
Globale Attrribute kann jeder mit userAttr setzen, wenn er sie denn benötigt.

Also bitte erst einmal die Dokumentation lesen.

LG

pah

[Benni]

Eine Veränderung der fhem.pl  ist vollkommen unnötig.
Globale Attrribute kann jeder mit userAttr setzen, wenn er sie denn benötigt.

Also bitte erst einmal die Dokumentation lesen.

LG

pah

Wenn ich es richtig sehe, geht es hier aber um device-spezifische Attribute am global-Device, nicht um globale Attribute für alle Devices. Das gäbe in dem Kontext ja auch gar keinen Sinn.

[lulatsch66]

Um das Thema nochmal aufzugreifen: da ich ebenfalls jemanden habe, der nach extern über einen Proxy "muss"
und aktuell deswegen keine Updates machen kann, habe ich den Patch für die aktuelle HttpUtils.pm angepasst -
scheint bei mir lokal auch prinzipiell zu funktionieren, allerdings nur mit ipv4 getestet.

• FHEM/HttpUtils.pm gepatcht: cd FHEM ; patch < HttpUtils-14945-proxy.patch
• fhem.pl habe ich ebenfalls angepasst - das ist ja kein Device Attribut? - jedenfalls klappt es so
• attr global proxyHost 192.168.x.y
• attr global proxyPort 3128

... danach laufen alle http Abfragen über den Proxy. Hier fehlt also noch eine Ausschluss-Liste, sprich z.B. alles im lokalen Netz sollte wahrscheinlich nicht über den Proxy, sondern kann den direkten Weg nehmen. Jemand eine Idee, wie man das sauber lösen könnte?

Uns geht es in diesem Fall ja vor allem um's Fhem-Update - was die gepatchten Dateien natürlich wieder überschreibt, solange der Patch nicht integriert wurde ... 

Zum Testen hatte ich mir einen squid proxy so aufgesetzt:

• apt install squid
• in /etc/squid/squid.conf aktiviert:  acl localnet src 192.168.0.0/16   und   http_access allow localnet 

LG
Falko

PS: mir ist klar, wenn es nur um's Update ginge, könnte man einfach den svn checkout verwenden ...

[rudolfkoenig]

Meine Bemerkungen zum Patch:
- die DNS-Aufloesung in HttpUtils_gethostbyname ist nur fuer die blockierende Version implementiert, dafuer aber explizit nochmal. Wuerde eine Zeile wie

Code: [Auswählen]

  $host = AttrVal("global", "proxyHost", $host);am Anfang der Routine nicht auch reichen? Damit wuerde IPv6 usw auch funktionieren.
- soweit ich es sehe, funktioniert es nur mit einer IPv4-Adresse als proxyHost.
- falls proxyPort nicht gesetzt ist, wird proxyHost ignoriert.
- das Ergebnis von HttpUtils_gethostbyname wird beim gesetzten proxy-Attributen ignoriert, d.h. der Code in HttpUtils_gethostbyname ist ueberfluessig.
- $hash->{proxyhost} und $hash->{proxyport} werden in HttpUtils_Close nicht entfernt.
- ich faende es sinnvoller auf CONNECT zu verzichten: wenn schon Proxy, dann sollte der doch mitlesen duerfen. Bin aber kein Experte auf diesem Gebiet.

Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.

Uns geht es in diesem Fall ja vor allem um's Fhem-Update - was die gepatchten Dateien natürlich wieder überschreibt, solange der Patch nicht integriert wurde ...

attr global exclude_from_update ...

[CoolTux]

Da ich persönlich mit einem Proxy arbeite wäre Interesse vorhanden.

[krikan]

Da ich persönlich mit einem Proxy arbeite wäre Interesse vorhanden.

Schließe mich an. 

[CoolTux]

So, nun habe ich mich ausführlich mit HttpUtils beschäftigt.
@Rudolf: Vielen Dank für den Support

Inzwischen habe ich eine Version erstellt, die mit und ohne Proxy eingesetzt werden kann. Unterstützt werden http- und https-Anfragen.
Der Proxy wird nur angesprochen, wenn er in der fhem.cfg eingerichtet ist. Zusätzlich wird CNTLM benötigt.

Probleme habe ich noch mit zwei neu eingeführten globalen Variablen (proxyHost & proxyPort): Wo müssen diese eingetragen werden, damit die Warnungen verschwinden?

Ich würde gern meine Weiterentwicklung zurück fließen lassen. Das es sich um eine wichtige Komponente handelt, natürlich nicht ohne Review. Testen konnte ich die Klasse nur eingeschränkt mit meinen Setups mit und ohne Proxy.
Muss ich meine Änderungen nun in ein git einstellen?

Ich würde mal behaupten daß die beiden Attribute nur Sinn im Device global machen.
Es würde mich sehr freuen wenn wir nicht über fhem.cfg editieren reden. Sämtliche Einstellungen sollten vom User über das FHEMWEB getätigt werden.

[TL]

Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.

Moin!

Ich hätte sehr großes Interesse daran. Es wäre auch gut, wenn es eine Option wie "no_proxy" gäbe für das lokale Netz, so ähnlich wie z.B. im Browser (Firefox) auch.

Viele Grüße,
  TL

[rudolfkoenig]

Ich habe das proxy global Attribut eingefuehrt, muss als host:port spezifiziert werden.
Es gibt auch ein proxyExclude, was als Regexp geprueft wird.

Ich habe es mit squid3 getestet, ein FHEM update funktioniert sowohl ueber HTTP als auch ueber HTTPS.
Auch http://fhem.de/ oder https://fhem.de/ (inklusive redirects) scheint zu funktionieren, sowohl Blocking als auch NonBlocking.

Achtung: SSL Verbindungen koennen selbst beim Aufruf der Nonblocking-Routine blockieren, da ich zu faul war die CONNECT Phase mit dem Proxy nonblocking zu realisieren. Evtl. spaeter, wenn Bedarf da ist.

[amenomade]

Es fehlt nur noch die Möglichkeit, proxyUser und proxyPasswort zu setzen

[Per]

Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.

Zwar nicht das selbe Problem, aber vllt. fällt eine Lösung für das DSLite-Thema dabei mit ab...

[rudolfkoenig]

Zwar nicht das selbe Problem, aber vllt. fällt eine Lösung für das DSLite-Thema dabei mit ab...

Bin heute vielleicht schwer vom Begriff, aber:
- was ist das "DSLite-Thema"?
- und was hat das mit einem Proxy zu tun?

[CoolTux]

Möchte mich den Fragen gerne anschließen. Danke

[rudolfkoenig]

 

Es fehlt nur noch die Möglichkeit, proxyUser und proxyPasswort zu setzen

Habe proxyAuth hinzugefuegt, und kurz mit http/https getestet.
Auf squid3 war es mit
  auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/passwords
aktiviert. proxyAuth muss als Base64 von Benutzername:Passwort angegegen werden:

Code: [Auswählen]

% echo -n Benutzername:Passwort | base64
QmVudXR6ZXJuYW1lOlBhc3N3b3J0
fhem> attr global proxyAuth QmVudXR6ZXJuYW1lOlBhc3N3b3J0


[amenomade]

Geht!
Funktioniert hinter meinem Firmenproxy.

Danke dir

[koef2]

HAllo zusammen,

funktioniert das auch in der Version 5.8?

Ich habe mal gerade mittells svn aktualisiert auf Revision 15152.

Da steht unter den attr zu GLOBAL noch kein proxy.

Viele Grüße
Kai
Koef2 

[rudolfkoenig]

Version 5.8 ist "nur" ein Snapshot, nach einem update ist man auf den aktuellen Stand, egal von welchem man gestartet ist.
proxyAuth ist seit SVN Version 15033 aktiv.

[koef2]

Danke,

dann hat mein Update über SVN nicht funktioniert. In der CommandRef auf meinem Raspi taucht es nicht auf. Aber in der CommandRef auf fhem.de wohl. Dann gehe ich mal suchen, was ich falsch gemacht habe.

Viele Grüße
Kai
Koef2

[koef2]

Hallo zusammen,

muss leider nochmal nachfragen, da mein update wohl über svn nicht richtig funktioniert.

Code: [Auswählen]

svn co https://svn.fhem.de/fhem/trunk/fhem /opt/fhem
svn update

Da hat er rumgemeckert:

Konflikt in »trallalla« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei
         (s) alle Optionen anzeigen: p

Habe das mit MC bestätigt.
Allerdings hat das nichts geändert, in commandref steht bei mir nichts zu proxy oder proxyAuth und "attr global proxy 192.168.1.3:3128" kann ich nicht setzen. Er sagt "define proxy first".

Dann habe ich im neuen Verzeichnis Repository neu geholt und die Dateien in des /opt/fhem kopiert und Dateiowner auf fhem:dialout gesetzt.

Leider immer noch kein Erfolg, Commandref zeigt unter global kein attr proxy.

Wenn es hier flasch gepostet ist, bitte kurze Info, wo ich es besser posten soll.

Viele Grüße
Kai
Koef2

[amenomade]

Warum machst Du dein update über svn, und nicht über FHEM ?

[koef2]

Hallo Amenomade,

weil ich einen Proxy dazwischen habe und das update aus fhem dann nicht funktioniert. Und eine Lösung dann svn ist, weil bei svn kann ich den Proxy angeben.

Viele Grüße und schönen Sonntag
Kai
Koef2

[rudolfkoenig]

weil ich einen Proxy dazwischen habe und das update aus fhem dann nicht funktioniert.

Inzwischen sollte das kein Problem sein: https://fhem.de/commandref.html#proxy

[koef2]

Hallo zusammen,

Problem gelöst. Lösung aus dem Kopf

Ich hatte die svn Arbeitskopie auf dem Raspi zerschossen. Hatte nicht aufgepasst, wenn man lokal editiert, dass dann Konflikte entstehen und die in svn aufgelöst werden müssen.

service fhem stop

Eintrag zu fhem aus /var/lib/dpkg/status Einträge zu fhem löschen

Dazu alles neu installiert gemäß fhem.de mittels Einträgen in /etc/apt/sourceslist, apt-get update, apt-get install fhem

Dann über svn eingespielt und update (siehe fhem.de).

Rechte user gesetzt auf fhem:dialout

attr global proxy gesetzt

update check ging

Update funktioniert auch.

Viele Grüße
Kai
Koef

[koef2]

Guten MOrgen,

Nachtrag: wenn ein Proxy eingetragen ist unter "global" und "fhem2fhem" genutzt wird und diese im gleichen LAN vorhandenen Rechner aber keinen Proxy erfordern, bitte auf dem Rechner, auf dem fhem2fhem konfiguriert wird, den Remote-Rechner in "proxyExclude" angeben. Sonst versucht fhem wohl, auch dafür den angegeben Proxy zu nutzen. Ich habe es bei beiden Rechnern angegeben.

FHEM ist eine tolle Software und danke für die Integration der Proxyfunktion.

Viele Grüße
Kai
Koef2

[TL]

Moin!

Ich wollte mich gern bei allen Beteiligten, allen voran natürlich Rudi, für die Implementierung des Proxys bedanken! Endlich geht bei mir Update und Pushover und mal sehen, was mir noch einfällt. Was lange währt... 

Eine Frage habe ich aber noch: wie ist die genaue Syntax für das ProxyExclude-Attribut? In der Beschreibung steht "Regexp", aber es gibt leider keine Beispiele. Ich habe z.B. "..., 192.168.1.0, ..." und "..., *.test.intranet, ..." ausprobiert, aber das scheint nicht zu funktionieren. Mit IP-Adressen und Full-Qulified-Hostnames funktioniert es wunderbar, aber die Liste kann beliebig lang werden und muß vor allem eben auch gepflegt werden. Ich würde gern das ganze lokale Class-C Netz komplett vom Proxy ausnehmen. Hat jemand einen Tip für mich, wie der entsprechende Eintrag aussehen müsste?

Viele Grüße,
  TL

[rudolfkoenig]

Ich würde gern das ganze lokale Class-C Netz komplett vom Proxy ausnehmen. Hat jemand einen Tip für mich, wie der entsprechende Eintrag aussehen müsste?

Die Pruefung gegen proxyExclude passiert vor der Namensaufloesung, d.h. der Regexp wird gegen den String geprueft, was man HttpUtils als host uebergeben hat. Falls man sich auf IP-Adressen beschraenkt, dann waere fuer den 192.168.1.255-er C-Netz

Code: [Auswählen]

attr global proxyExclude ^192.168.*
einzusetzen (ja, etwas ungenau, sollte aber tun). Ein Regexp fuer alle "Intranet" Adressen (auch IPv6) findet man bei der Pruefung von allowedFrom:

Code: [Auswählen]

^(::ffff:)?(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|^(f[cde]|::1)Wenn man in FHEM Hostnamen in Klartext verwendet, dann muessen diese zusaetzlich spezifiziert werden.

[TL]

Moin!

Die Pruefung gegen proxyExclude passiert vor der Namensaufloesung, d.h. der Regexp wird gegen den String geprueft, was man HttpUtils als host uebergeben hat. Falls man sich auf IP-Adressen beschraenkt, dann waere fuer den 192.168.1.255-er C-Netz

Code: [Auswählen]

attr global proxyExclude ^192.168.*
einzusetzen (ja, etwas ungenau, sollte aber tun).
...

Ich glaube, der .* am Ende ist nicht gut...

Ich habe jetzt folgenden String bei mir drin, das funktioniert bei mir anscheinend:

Code: [Auswählen]

attr global proxyExclude ^192\.168\.1\.*|.*\.test\.intranet$
Viele Grüße
  Thomas

[rudolfkoenig]

Ich glaube, der .* am Ende ist nicht gut...

Wie geschrieben, etwas ungenau, weil es auch 192.16890.1.1 matcht, aber das sollte selten ein Problem sein.