Jump to content

Recommended Posts

Geschrieben

Hallo,

 

nachdem ich nun den Red-Brick habe, wollte ich das Programm meiner Wetterstation auf den RED überspielen. Es ist das vb.net Skript hier aus den Beispielen der wetterstation.

Die erstellte .exe funktioniert vom PC aus mit dem Master und den Bricklets, das Überspielen auf den Red klappt auch, und laufen tut das Programm auch. Jedoch bekomme ich im Log des Red´s immer nur die Meldung Connection Error: Network is unreachable.

Woran kann das liegen? Im Quellcode ist als Host "localhost" eingestellt und das Image des Red ist ein Jungfräuliches Full.Image 1.1Hoffe mir kann jemand helfen.

 

Danke und Gruß

Patrick

 

Geschrieben

Ein unter Windows für Windows compiliertes Programm funtionert auf einem Linux Rechner nicht. Es sei denn man hat Wine installiert.

Du wirst das Programm entweder direkt aud dem Red compilieren müssen oder für Linux mit einem entsprechenden Compiler.

Geschrieben

Hallo FlyingDoc,

 

das verstehe ich gerade nicht ??? Ich habe eine .Exe Kompiliert und im Red doch die Möglichkeit einzustellen das es ein vb.net Programm, also eine .exe ist. Das Programm als solches läuft ja auch. Wie ich es verstanden habe ist auf dem Linux des Red ja Mono installiert und Mono hatte ich auch damals auf meinem RPI mit dem gleichem Programm und es lief ohne Probleme.

Wenn das Programm gar nicht erst laufen würde, würde mir dich eigentlich die Statusanzeige des Red sagen, dass das Programm nicht ausgeüfhrt werden kann.

 

Ich hatte es aber auch vorgestern mit dem Beispielprogramm aus der Red Doku (Also das Programm mit dem Temperatur-auslesen) als Python Skript- und auch hier hatte ich das gleiche Phänomen das mir immer gesagt wurde Network unreachable.

 

Ich vermute irgendetwas habe ich vergessen im Red einzustellen, aber ich finde halt nicht was.

 

Geschrieben

Hallo,

Hattest du mal versucht, das Skript in der Console zu starten? Befindet sich nach dem Upload im Ordner /home/TF/projekts/Name des Projekts

Ausführen sollte mit mono Name.exe gehen.

 

Ich habe das csharp Programm mit Visual csharp unter Windows Compilieren (CPU any) und hochgeladen. Im Beispiel wird das Programm ja mit Tastendruck beendet, was zu Fehlern fûhren kann...

 

Gruß

Markus

Geschrieben

Hallo Markus,

 

danke für den Lösungsansatz. habe es eben mal versucht, aber auch hier bekomme ich als Consolenausgabe dann nur ein "Connection Error: Network is unreachable"

 

Also das gleiche wie in der Log Datei

Gruß

Patrick

Geschrieben

Hallo Patrick,

Sind Master und bricklets im brickviewer sichtbar?

Könntest du ggfs. Deine exe mal per Email senden um das Problem auf Hardware oder Software Konfiguration eingrenzen zu können?

 

Mein kollege hat zwar das 1.0 Image Full - würde es aber testen können...

 

Die üblichen Verdächtigen hast du schon ausgeschlossen? Bricks eingerastet und nicht mit Gewalt festgeschraubt? RED-Brick befindet sich unter dem Master?

 

Wenn du am red brick den Port nicht geändert hast sollte das eigentlich keine einstellungs Geschichte sein.

 

Gruß markus

Geschrieben

Hallo Markus,

 

ja, alle Bricklets und der Master werden angezeigt. Führe ich die Exe am PC aus, sehe ich in einer sich öffnenden Konsole die Daten des Lichtsensors, Luftdruck und Feuchtigkeit sowie Temperatur und im Display werden die WErte auch angezeigt.

Klar, die Exe kann ich dir senden, ist nix besonderes drin auser das Beispielt der Wetterstatino von TF. Hast du eine Mail-adresse für mich?

 

Der Red ist an unterster Stelle, Port im BD im Red auf 4223 eingestellt sowie auch in der Exe- also alles auf Standart.

Danke für deine Hilfe und das Angebot alles zu testen.

 

Gruß

Patrick

Geschrieben

Hallo Zusammen,

 

mal ein kleiner Stand der Dinge.

Markus hat mein Programm getestet und bei Ihm läuft es, umgekehrt konnte ich eines seiner Programme testen und bei mir tritt der gleiche Fehler bei seinem Programm auf, wie vorher bei meinem: Network is unreachable.

 

:(

 

Hat niemand sonst eine Idee was das sein könnte oder was wo eingestellt werden muss/kann?

Firmwares sind alle auf dem neusten Stand

 

Gruß

Patrick

Geschrieben

Hallo P4trick,

 

möglicherweise habe ich eine Idee, was es sein könnte (trat bei mir auch auf!):

 

Test1:

Melde Dich auf der Konsole an (z. B. über BrickV) oder über ssh:

In der Konsole gebe folgendes Kommando:

 

sudo ping localhost

 

wenn Du auch hier ein "network unreachable oder eine vergleichbare Fehlermeldung bekommst, dann versuche mal ein

 

sudo ifconfig lo

 

danach sollte das ping von oben funktionieren.

 

ein weiterer einfacher Test ist, einfach die angeschlossenen bricks und bricklets in der shell zu enumerieren:

 

tinkerforge enumerate

 

danach sollte eine Liste der Objekte auf der konsole erscheinen...

 

viel Erfolg!

Martin

Geschrieben

Sorry, dass ich so rüde mittendrin einsteige. Ich hatte ein ähnliches Problem:

 

Mein Aufbau:

  • RED-Brick (Fast Image 1.1)
  • Master-Brick
  • Ethernet-Extension
  • + 2 Bricklets auf dem Master-Brick

 

Ich habe ein C#-Projekt (.NET 2.0). Die Exe-Datei lässt sich auf Windows ohne Probleme ausführen. Auf den RED-Brick hochgeladen, fehlte jegliche Funktionalität der EXE. Im Log fand ich:

 

Unhandled Exception:
System.Net.Sockets.SocketException: Connection timed out

 

Dann habe ich eine Verbindung per Putty aufgebaut und mit:

sudo ifconfig lo up

das Interface aktiviert.

Ping auf localhost funktionierte anschließend. Auch mein Programm auf dem RED-Brick lief auf einmal! Danke für den Hinweis!

 

Ich meine mich erinnern zu können, dass das Programm auf dem Fast Image 1.0 ohne Probleme aus dem Stand lief. Ist es ggf. ein Bug in 1.1?

Geschrieben

Hmmm,

 

mit scheint das ein Mischung aus Netzwerk-Setup für einen Desktop(Client), gemitscht mit Konfiguration via brickV und Serversetup .... (sorry für die harten Worte - ich weiss dass es nicht leicht ist, genau das einfach für Nicht-Server-Profis zu lösen):

 

Ok - hier erst mal der Workaround, der bei mir geholfen hat: Ich habe mir angeschaut, wie das Netzwerk hochgefahren wird. Leider wird auch in dem fastImage (headless system) nicht die bei Servern einfache Variante der Config über die /etc/network/interfaces gewählt. Die scheint nutzlos zu sein, sondern es geht über wicd.

 

Um nur minimal einzugreifen - ev. verstehe ich hier auch nicht alles - habe in die /etc/rc.local eine Zeile eingefügt: "ifconfig lo up". die rc.local wird bei einem normalen boot als vorletzte Aktion im runlevel 2 ausgeführt. Also wenn der Rest des Netzwerkes hoffentlich (wireless oder wired) schon läuft. Meine rc.local sieht danach so aus:

 

tf@red-brick:~$ cat /etc/rc.local

#!/bin/sh -e

#

# rc.local

#

# This script is executed at the end of each multiuser runlevel.

# Make sure that the script will "exit 0" on success or any other

# value on error.

#

# In order to enable or disable this script just change the execution

# bits.

#

# By default this script does nothing.

 

 

ifconfig lo up

 

 

exit 0

 

 

 

hth

martin

Geschrieben

Das heißt bei euch ist im Fast Image reproduzierbar nach dem Boot das Loopback-Interface nicht vorhanden? WTF? :)

 

Ich kann das nicht reproduzieren und wir haben diesbezüglich auch eigentlich keine Änderungen gemacht.

Geschrieben

Hallo Borg,

 

ja - bei mir ist beim FastImage reproduzierbar das loppback device nach einem (re)boot nicht mehr aktiv.

Da das Paket ifupdown fehlt, wird die /network/interfaces auch nicht ausgewertet

 

gruß

Martin

Geschrieben

Hallo

Wollte mal nur zur Info schreiben das mein C# Programm auf dem 1.0 FullImage lief (zwar nicht zo wie Ich dachte aber es lief) und auf dem 1.1 FullImage bekomme Ich auch ein

Unhandled Exception:

System.Net.Sockets.SocketException: Network is unreachable.

Geschrieben

Hallo,

 

Lösung bei mir (erst mal FastImage 1.1), da FullImage broken:

Verwendung von /etc/init.d/network und als Config Basis /etc/network/interfaces:

dazu: Debian Paket ifupdown installieren:

 

apt-get install ifupdown

 

und /etc/network/interfaces korrekt einstellen:

 

root@red-brick:/home/tf# cat /etc/network/interfaces 
# /etc/network/interfaces

# interfaces(5) file used by ifup( and ifdown(
auto lo
iface lo inet loopback

auto tf0
iface tf0 inet dhcp

 

das geht auch für wlan - muss ich nur wieder heraussuchen.

wicd habe ich dann deinstalliert. Für einen headless server ok, denke ich.

Aber ACHTUNG: Config über brickv ist dann für das Netzwerk nur noch über die brickv Console möglich!

 

Damit ist dann auch der workaround für loopback über die rc.local überflüssig: Da /etc/network/interfaces ausgelesen wird, können da auch alle Interfaces für wlan / lan / loopback eingetragen werden.

Weiter ist dann auch die Config von VLANs und IP-Aliases etc. alles kein Problem ... eben wie bei einem richtigen (Debian-)Server.

 

btw: RED läuft stabil via POE über Ethernet-Master-Extension mit einem Master und vier Bricks (seit etwa 24h).

 

NTP hält die Zeit und die Bricks antworten brav.

 

gruß

Martin

Geschrieben

Hallo,

 

fastImage installiert - bestätige erst mal, dass die sudo-Rechte hier immer noch ok sind ;-) und das loopback-interface nun automatisch (ohne workaround) hoch kommt.

 

Aktuell kämpfe ich aber noch mit DNS - resolv.conf fehlt? DNS geht nicht - zumindest in dem zum vorherigen Image unveränderten Stack mit ethernet-poe-master-ext.

 

gruß

Martin

Geschrieben

Aktuell kämpfe ich aber noch mit DNS - resolv.conf fehlt? DNS geht nicht -

 

DNS-Schwierigkeiten kann ich bestätigen. Habe heute mit FastImage 1.2 getestet.

Die resolv.conf musste ich manuell anlegen und füllen. Danach ging auch die Namensauflösung (und auch die Zeit-Sync per ntp).

Geschrieben

ARG, Gottverdammt!

 

Jetzt hab ich für Version 1.2 mehr als 6 Stunden lang jeden möglichen Anwendungszweck durchgetestet, in jeder Programmiersprache ein Beispiel hochgeladen usw. Ich bin aber nicht auf die Idee gekommen mal eine Webseite zu Pingen oder zu gucken ob NTP geht. :)

 

Ich hab es inklusive Fix zu den bekannten Problemen in der RED Brick Doku hinzugefügt: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#bekannte-probleme

 

 

Wir haben uns das eingefangen weil schon ein Teil der hostapd Implementierung (um den RED Brick als WIFI Access Point nutzen zu können) mit im Image gelandet ist. Dadurch haben wir uns ausversehen die Namensauflösung kaputt gemacht.

 

 

 

Was meint ihr, soll ich morgen früh ein schnelles 1.3 Release machen? Ich könnte als "Quickfix" einfach das Image mounten, die Versionsnummer inkrementieren, die resolv.conf hinzufügen und das als 1.3 Release hochladen.

 

Alternativ ist ca. Ende nächster Woche ein neues Feature Release mit WIFI Access Point Unterstützung und noch ein paar anderen neuen Konfigurationsmöglichkeiten geplant.

Geschrieben

Hmm,

 

ich fürchte der Support ist einfacher, wenn Du ein 1.3-Image baust...

 

Wer sich mit linux gut auskennt (me ;-)) kann sich selber helfen, aber der Rest wird Support brauchen -  das ist wahrscheinlich lästiger als ein 1.3er Fix zu machen ;-)

 

gruß

Martin

Geschrieben

Hallo zusammen,

sorry das länger nix von mir kam, ich war offline für einige Tage.

 

Also wie hier auch andere bemerkten lag es wohl am 1.1er Image. Ich habe schlussendlich das 1.0 Full genommen und damit lief es dann. Ich bekam nach den Versuchen den Loopback zu Pinker per Sudo seltsame meldungen die auf ein Problem mit dem Sudo des Linux- Image deuteten. Da kam mir die Idee einfach das 1.0er zu patchen da Sturmvogel(Markus) auch dieses eingesetzt hat und es damit ging.

Danke für eure Unterstützung.

Guten Rutsch und frohes neues Jahr

Patrick

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...