Ein kleines Problem habe ich noch.
Ich habe an meinem Router eingestellt das, wenn ich meine Internetseite anmelde (mit einem Port z.B. 81) ich nicht auf der Webcam lande, sondern wieder auf dem Webserver des RPI.
Schließe ich die Kamera am Router an, Klappt alles.
Eine Art Bridge?!
-
Bizkit83 -
19. März 2013 um 19:53 -
Geschlossen -
Erledigt
-
-
Eine Art Bridge?!? Schau mal ob du hier fündig wirst!
-
Sorry, aber ich verstehe nicht was Dein Problem ist. Vielleicht kannst Du es etwas ausfuehrlicher erklaeren.
-
Wenn ich meine Webseite Aufrufe:
xyz.no-ip.org
komme ich auf den webserver des rpi.mit
xyz.no-ip.org:91
Komme ich auf die webcam.aber seit ich die bridge nutze komme ich immer auf dem webserver aus. Schließe ich die cam am Router an klappt es, dann komme ich mit :91 auf die cam.
-
Jetzt ist mir Dein Problem klar. Folgende Fragen:
1) Du hast den Port 91 am Router freigegeben für die IP Deiner WebCam (192.168.0.cam)
2) Wenn Du mit einem Client aus Deinem Netz versuchst auf 192.168.0.cam:91 zuzugreifen - funktioniert es dann und Du landest bei der Webcam?
3) Wenn Du mit einem Client aus Deinem Netz versuchst auf 192.168.0.pi zuzugreifen - landest Du dann bei der Pi?
4) Hast Du mal bei Deinem Router nachgesehen ob der die 192.168.0.cam an eine Mac gebunden hat, die icht die mac der webcam ist?
5) Was ergibt von einem Client im Netz -
Ich denke mal der Router hat da irgendwas verwechselt.
Hab mal den Webserver/Weboberfläche der Kamera auf Port 88 gelegt.
Nun klappt es wohl.
Morgen mal von außerhalb testen. -
Zitat von Bizkit83 pid=8861 dateline=1364401888
Ich denke mal der Router hat da irgendwas verwechselt....Mich würde trotzdem die Antworten zu meinen Fragen interessieren
-
1) ist jetzt Port 88, aber habe ich
2) Ja das klappt3) Ja das klappt
4) Die MAC ist Richtig übernommen
5)Code
Alles anzeigenpi@raspberrypi ~ $ ping 192.168.2.61; ping 192.168.2.106; sudo arp PING 192.168.2.61 (192.168.2.61) 56(84) bytes of data. 64 bytes from 192.168.2.61: icmp_req=1 ttl=64 time=2.06 ms 64 bytes from 192.168.2.61: icmp_req=2 ttl=64 time=0.910 ms 64 bytes from 192.168.2.61: icmp_req=3 ttl=64 time=0.949 ms 64 bytes from 192.168.2.61: icmp_req=4 ttl=64 time=0.894 ms 64 bytes from 192.168.2.61: icmp_req=5 ttl=64 time=0.971 ms 64 bytes from 192.168.2.61: icmp_req=6 ttl=64 time=0.798 ms ^C --- 192.168.2.61 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 0.798/1.098/2.068/0.437 ms PING 192.168.2.106 (192.168.2.106) 56(84) bytes of data. 64 bytes from 192.168.2.106: icmp_req=1 ttl=64 time=0.274 ms 64 bytes from 192.168.2.106: icmp_req=2 ttl=64 time=0.160 ms 64 bytes from 192.168.2.106: icmp_req=3 ttl=64 time=0.187 ms 64 bytes from 192.168.2.106: icmp_req=4 ttl=64 time=0.159 ms ^C --- 192.168.2.106 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 0.159/0.195/0.274/0.046 ms Address HWtype HWaddress Flags Mask Iface axis-00408c6a8972.local ether 00:40:8c:6a:89:72 C br0 pc383.local ether 64:31:50:71:7b:5b C br0 speedport.ip ether 00:1a:2a:47:14:18 C br0 pi@raspberrypi ~ $
Das sind meine Antworten
-
Zitat von Bizkit83 pid=8884 dateline=1364412464
Das sind meine AntwortenDanke (Der Ping sowie arp sollte eigentlich von irgendeinem anderen Rechner im Netz gemacht werden und nicht Deiner Pi ...). Jetzt gäbe es noch mehr Fragen von mir - aber es funktioniert ja bei Dir lokal. Das kann ich mir ja ersparen wenn Dein externer Test erfolgreich ist
-
Komisch!
Zuerst ging es heute morgen. Nun wollte ich nochmal gucken und dann bekomme ich keine Verbindung mehr.
Code
Alles anzeigenpi@raspberrypi ~ $ ping 192.168.2.61; ping 192.168.2.106; sudo arp PING 192.168.2.61 (192.168.2.61) 56(84) bytes of data. 64 bytes from 192.168.2.61: icmp_req=1 ttl=64 time=2.52 ms 64 bytes from 192.168.2.61: icmp_req=2 ttl=64 time=0.992 ms 64 bytes from 192.168.2.61: icmp_req=3 ttl=64 time=0.794 ms 64 bytes from 192.168.2.61: icmp_req=4 ttl=64 time=0.825 ms 64 bytes from 192.168.2.61: icmp_req=5 ttl=64 time=0.823 ms ^C --- 192.168.2.61 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 0.794/1.191/2.525/0.671 ms PING 192.168.2.106 (192.168.2.106) 56(84) bytes of data. 64 bytes from 192.168.2.106: icmp_req=1 ttl=64 time=0.206 ms 64 bytes from 192.168.2.106: icmp_req=2 ttl=64 time=0.159 ms 64 bytes from 192.168.2.106: icmp_req=3 ttl=64 time=0.151 ms 64 bytes from 192.168.2.106: icmp_req=4 ttl=64 time=0.160 ms 64 bytes from 192.168.2.106: icmp_req=5 ttl=64 time=0.154 ms ^C --- 192.168.2.106 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.151/0.166/0.206/0.020 ms Address HWtype HWaddress Flags Mask Iface axis-00408c6a8972.local ether 00:40:8c:6a:89:72 C br0 speedport.ip ether 00:1a:2a:47:14:18 C br0 pi@raspberrypi ~ $
-
So wie ich das sehe gibt es mac Probleme wenn Du Deine Kamera in Deinem Netz von der Pi an Deinen Router und zurueck steckst. Der Wechsel des Ports fiel nur in die Zeit wo der Cache expired ist.
Mache mal folgendes:
1) Auf der Pi:
a) Ausfuehren bis nix mehr geloescht wird.
b) Ausgabe von2) Auf einen Client im Netz
a) Ausfuehren bis nix mehr geloescht wird.
b) Ausgabe von
Falls Du keinen Linuxclient im Netz hast musst Du den Rechner restarten m dem arp cache zu loeschen. Ich habe keine keine Ahnung wie man den arp Cache bei Windows loescht.3) Auf dem Client von mal zur Pi und Cam versuchen zuzugreifen.
-
Cool,
nun habe ich gerade das Phänomen, das mal die Cam geht und mal der RPI
Also teste das gerade von außerhalb...ArpCache in Windows:
Cache-Einträge zu löschen:
arp -d IP-Adresse
ARP-Cache zu leeren:
netsh interface ip delete arpcacheCode
Alles anzeigenpi@raspberrypi ~ $ sudo ip -s -s neigh flush all 192.168.2.1 dev br0 lladdr 00:1a:2a:47:14:18 ref 1 used 1/0/1 probes 4 REACHABLE *** Round 1, deleting 1 entries *** 192.168.2.1 dev br0 ref 1 used 0/0/0 probes 4 INCOMPLETE *** Round 2, deleting 1 entries *** *** Flush is complete after 2 rounds *** pi@raspberrypi ~ $ sudo ip -s -s neigh flush all 192.168.2.1 dev br0 lladdr 00:1a:2a:47:14:18 ref 1 used 5/0/1 probes 4 REACHABLE *** Round 1, deleting 1 entries *** 192.168.2.1 dev br0 ref 1 used 0/0/0 probes 4 INCOMPLETE *** Round 2, deleting 1 entries *** *** Flush is complete after 2 rounds *** pi@raspberrypi ~ $ ifconfig | egrep "^[^ ]|ask" br0 Link encap:Ethernet HWaddr 80:1f:02:82:b0:6f inet addr:192.168.2.106 Bcast:192.168.2.255 Mask:255.255.255.0 eth0 Link encap:Ethernet HWaddr b8:27:eb:ae:83:e1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 wlan0 Link encap:Ethernet HWaddr 80:1f:02:82:b0:6f pi@raspberrypi ~ $
-
Dieses intermittierende Verhalten hat ziemlich sicher mit dem arp Cache zu tun. Auch damit, dass Du die Cam auch ins Netz von anderen Stellen nimmst und sie dann ueber andere Wege ereichbar wird. Die Ausgaben vom Client hast Du wohl vergessen
Ich habe jetzt keine WLAN/eth Bridge mehr bei mir und kann nicht testen. Was ich aber festgestellt habe damals ist, dass es eine gewisse Zeit dauert, bis die Pi den arp Cache richtig gefuellt hat. Keine Ahnung warum das so lange dauert (ein paar Minuten bei mir).
Ich wuerde noch mal den arp Cache der Pi loeschen - und dann mal ein wenig warten, dann auf dem Client den cache loeschen und dann auf die Pi und Cam zugreifen. Falls es nicht funktioniert nach einer gewissen Zeit noch mal versuchen.
-
Die Ausgabe vom Client kann ich noch nicht geben, weil ich auf der Arbeit bin und halt nicht zu hause im internen Netz.
Ich frage mich nur was der Client (anderer PC) damit zu tun hat. Damit möchte ich ja nicht auf die Cam zugreifen.
Intern mit IP-Adressen klappt auch alles. Nur von außerhalb macht das ding immer Probleme.Hauptsächlich möchte ich den das VideoBild auf meiner Webseite anzeigen/aufrufbar machen. Der Webserver hierzu läuft auf dem RPI.
Gruß Simon
-
Zitat von Bizkit83 pid=8927 dateline=1364468525
...Intern mit IP-Adressen klappt auch alles. Nur von außerhalb macht das ding immer Probleme....Das war mir nicht klar. Ich dachte Du haettest das intermittierende Problem auch zu Hause. Deshalb habe ich immer so auf den Client verwiesen. Da war ich wohl - wie man Neudeutsch so sagt - wohl auf dem Woodway :s
Wenn zu Hause alles deterministisch funktioniert und von extern intermittierend dann ist des wohl Dein Router bzw dessen arp Cache. Normale Router erlauben das Loeschen des arp Caches nicht - ausser durch einen Restart.
-
Habe gerade noch was interessantes festgestellt.
öffne ich eine zeit lang nicht die Webseite (tippe mal so auf 15-30 Min) dann komme ich auch die Kamera.
Aber nicht auf den Webserver.
Warte ich dann wieder... Komme ich auf den Webserver, aber nicht auf die Kamera.Quasi, wer zuerst aufgerufen wird geht und der andere hat Pause
-
Sehr merkwuerdig. Bist Du sicher dass die Portforwardings fuer Web und Camera die richtigen IPs und Ports haben? Loesche mal den arp Cache von dem Router durch einen Restart.
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!