Jump to content

Reaktion der Firmware auf unbekannte Nachrichten


AuronX

Recommended Posts

Wahrscheinlich gehört das hier ins Github, aber ich weiß nicht in welches Projekt ^^

 

Der ArcaneDraconum hatte ja das Problem, dass er versehentlich eine Nachricht an seine Bricks verschickt hat die sie nicht verstanden haben.

 

Mich würde interessieren: Warum führt das zum Aufhängen? Sollte es nicht leicht möglich sein so eine Nachricht wenigstens leise zu ignorieren? Ich denke dagegen sollte die Firmware resistent sein. Insofern würde es mich interessieren sobald ihr herausfindet warum das zum Absturz geführt hat :D

 

Auf der anderen Seite (und hier spreche ich von einer zusätzlichen Maßnahme, könnten die Bindings ja durchaus für alle Methoden eine minimumRequiredFirmwareVersion kennen. Da die Bindings wissen welche Firmware auf dem Brick läuft, könnten sie dann eine hilfreiche Exception werfen bevor sie die Hardware mit Unsinn bombardieren.

 

Waiting for your feedback ;)

Jan

Link zu diesem Kommentar
Share on other sites

Was mich persönlich etwas irritiert: Ich habe in einem RS485-Verbund einen Slave mit einem unbekannten Befehl beschossen und der RS485-Master ist auch abgestürtzt. Der komplette Stack war nicht mehr ansprechbar. Der BrickDaemon kann es aber nicht gewesen sein, denn an einem zweiten USB-Port hängt nochmals ein Stack und der ließ sich noch ansprechen.

Also wenn nur der Slave verschwunden wäre, wäre es verständlicher.

Link zu diesem Kommentar
Share on other sites

Ach ihr seit ja herrlich.  :)

 

Schoen das wir das alte Thema nochmals aufwaermen. Bei meinem Versuchen per TCP auf die Bricks zuzugreifen sind sie mir reihenweise haengengeblieben, bzw. sie haben nur teilweise reagiert. Ueber eine Loesung inkl. LAN/WLAN Pin waere ich dankbar.

 

@AuronX

Es handelt sich um "Zufaelle" in der Firmware laut TF.  ;) Die Idee mit der robusteren Firmware steht aber auch auf der ToDo Liste.  :)

 

Wer moechte kann es in diesen Beitraegen nochmals nachlesen. Insbesondere die Erlaeuterungen der Admins sind wichtig!

 

[TCP/IP] 20x4 LCD - Stringlaenge im Paket ?

 

[geloest] [TCP] Master Brick "Resolve UID" behindert Bricklet "Resolve UID".

 

Sanitycheck und Passwort fuer Bricks beim Zugriff "von aussen"

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites

Auf der anderen Seite (und hier spreche ich von einer zusätzlichen Maßnahme, könnten die Bindings ja durchaus für alle Methoden eine minimumRequiredFirmwareVersion kennen. Da die Bindings wissen welche Firmware auf dem Brick läuft, könnten sie dann eine hilfreiche Exception werfen bevor sie die Hardware mit Unsinn bombardieren.

 

Das ist eine sinnvolle Idee. Ich habe dazu gerade den ersten Schritt getan und alle Funktionen in den Configs mit ihrer "minimumRequiredFirmwareVersion" versehen. Als nächsten kommen, dann Checks dafür in den Bindings.

Link zu diesem Kommentar
Share on other sites

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...