Ethernet Master Extension: DHCP Problem

[Martin]

Hallo,

 

ein Wetterstation-Starterkit mit einem Master Brick 2.0, (FW Version 2.1.2) wurde durch eine

Ethernet Master Extension (mit PoE) erweitert. Mit einer "Static IP" Connection funktioniert das problemlos.

Beim Wechsel zu "DHCP" wird hier nun aber anscheinend keine IP Adresse zugewiesen.

Der DHCP Server (eines Routers) zeigt leider keine Log-Einträge.

 

wireshark erfasst für die eingestellte MAC Adresse sich wiederholende

DHCP NAK Pakete von Source 0.0.0.0 nach Destination 255.255.255.255 mit dem Bootstrap Protocol:

 

Message type: Boot Request (1)

Hardware type: Ethernet

Hardware address length: 6

Hops: 0

Transaction ID: 0x12345678

Seconds elapsed: 0

Bootp flags: 0x8000 (Broadcast)

Client IP address: 0.0.0.0 (0.0.0.0)

Your (client) IP address: 0.0.0.0 (0.0.0.0)

Next server IP address: 0.0.0.0 (0.0.0.0)

Relay agent IP address: 0.0.0.0 (0.0.0.0)

Client MAC address: XX:XX:XX:XX:XX:XX (XX:XX:XX:XX:XX:XX)

Client hardware address padding: 00000000000000000000

Server host name not given

Boot file name not given

Magic cookie: DHCP

Option: (t=53,l=1) DHCP Message Type = DHCP Discover

Option: (t=61,l=7) Client identifier

Option: (t=12,l=32) Host Name = "TinkerforgeXXXXXX"

Option: (t=53,l=55) DHCP Message Type length isn't 1

Padding (205 bytes)

[Expert Info (Error/Protocol): End option missing]

 

Laut https://www.ietf.org/rfc/rfc2132 Abschnitt 3.2 ist die "End option" eine "Vendor Extension"

mit einem Oktett Länge und Wert 255 und findet sich wirklich nicht in den Paketen.

Die Fehlermeldung könnte natürlich auch irreführend sein. Ein DHCP NAK (DHCP-Not Acknowledged),

also eine Ablehnung einer DHCPREQUEST-Anforderung durch den DHCP-Server erwartet man z.B.,

falls ein Client eine Adresse anfordert, die es im lokalen Subnetz (hier 192.168.0.0/24) nicht gibt oder

die anderweitig vergeben ist. Das kann ich hier aber gerade nicht nachvollziehen.

 

Ist jemand schon einmal auf ein ähnliches DHCP-Problem gestossen und hat evtl. sogar einen Tipp für eine Lösung?

(Wie bekommt die Tinkerforge Ethernet Master Extension doch noch seine IP-Adresse?)

 

Danke,

Martin

 

[borg]

Puh, schwer zu sagen. Welchen Router verwendest du? Wir haben hier bisher mit einem Linksys, unterschiedlichen Fritz Boxen und einen Billigrouter von Arcor getestet und wir haben viele Kunden die unterschiedliche Cisco Router verwenden wo DHCP problemlos funktioniert.

 

Es ist aber nicht sowas einfaches wie eine Whitelist von MAC Adressen für DHCP oder sowas?

[gagahhag]

Hallo

ich bin auch wieder mal da ;-)

 

Zur Zeit habe ich das selbe Problem mit meiner Ethernet-Extension (ohne PoE). Ich habe diese auch auf DHCP konfiguriert, bekomme zwar eine IP, aber der Stack ist nicht über den Namen ansprechbar (DNS), nur über IP. Ich habe im Router nun diesen Name fest der IP zugewiesen und so hats dann funktionierts.

 

Einige Router haben einen definierten Range für IPs. Kann es sein, dass alle schon vergeben sind? Ich denke zwar nicht, dass das das Problem ist, aber mal schauen schadet nicht....

 

Gruss, Andreas

[Gast Robin]

Ich hatte das Problem bis gerade eben auch. Ich habe bisher immer eine statische IP gesetzt, um das Problem mit der Hostnamenauflösung zu umgehen. Ich habe mir allerdings gerade noch mal die Konfiguration angesehen. Bei Gateway war aus irgendwelchen Gründen 192.168.178.112 eingetragen. Ich habe das da bestimmt nicht eingetragen. Nachdem ich den Gateway richtig gesetzt habe lief auch die Hostame auflösung und ich konnte sogar wieder auf DHCP umschalten. Die Hostame Auflösung funktioniert immer noch. Macht die Ethernet Extension vielleicht irgendeinen Mist beim speichern?

[borg]

Du meinst das die Konfiguration irgendwie überschrieben wird? Sollte eigentlich nicht passieren.

 

Ich hab mal gerade an einer Ethernet Extension mit den Konfigurationen herumgespielt, ich konnte auch keine Probleme feststellen.

 

Sowas kann höchstens passieren wenn man die Master Birck Firmware aktualisiert und es kommen neue Einstellungen hinzu, diese sind dann mehr oder weniger zufällig gesetzt.

[Gast Robin]

Aktualisiert habe ich den Master nicht, seitdem ich die Ethernet Externsion im Einsatz habe. Ich hatte aber eine Zeit lang ein ziemliches billig Netzteil da dran (Stromversorgung wurde mit der Zeit immer weniger...). Könnte es vielleicht sein, dass dadurch irgendwie der Speicher korrupt? geworden ist?

[Martin]

Hallo nochmals,

 

zunächst einmal möchte ich anmerken, dass der DCHP Broadcast aus meiner ersten Email direkt vom

Masterbrick bzw. der Ethernet Extension gesendet wurde, der DHCP Server noch nicht in Aktion war

und somit keine Rolle spielt!

 

Betrachtet man nochmals das Paket (592 Byte Länge) so sieht das Bootstrap Protocol anfangs noch gut aus.

Es fällt auf, dass beim Hostname

Option: (t=12,l=32) Host Name = "TinkerforgeXXXXXX"

die Länge mit 32 (statt 17) übermittelt wird! Die restlichen 15 Byte sind mit 0 aufgefüllt.

Nach https://www.ietf.org/rfc/rfc1533 Abschnitt 3.14 gelten Restriktionen für die Zeichenwahl

laut https://www.ietf.org/rfc/rfc1035 für den Hostname.

Insofern stellt sich schon einmal die Frage, ob das so überhaupt standardkonform ist?

 

 

Betrachten wir doch einfach einmal den Sourcecode,

der ja glücklicherweise online zu finden ist.

 

 

Zunächst einmal findet sich die Länge des Hostnames im

 

brickv

======

https://github.com/Tinkerforge/brickv/archive/v2.0.9.zip

 

brickv-2.0.9/src/brickv/plugin_system/plugins/master/ui/ethernet.ui:

47            <item>

48            <widget class="QLineEdit" name="ethernet_hostname">

49              <property name="sizePolicy">

50              <sizepolicy hsizetype="Minimum" vsizetype="Fixed">

51                <horstretch>0</horstretch>

52                <verstretch>0</verstretch>

53              </sizepolicy>

54              </property>

55              <property name="toolTip">

56              <string>Up to 15 chars, leave empty for default</string>

57              </property>

58              <property name="maxLength">

59              <number>32</number>

60              </property>

61            </widget>

62            </item>

wobei der Tooltip (Zeile 56) zwar angibt, dass max. 15 Zeichen für den Hostname

zur Verfügung stehen, in Zeile 59 werden aber 32 Zeichen zugelassen.

(Die 32 Zeichen stammen vermutlich nicht aus der RFC1533, sind eine Beschränkung mit der man sicher leben kann.)

 

Im

 

master-brick

============

https://github.com/Tinkerforge/master-brick/archive/v2.1.2.zip

 

master-brick-2.1.2/software/src/extensions/ethernet/ethernet.h

40 typedef struct {

41        uint8_t mac_address[6];

42        uint8_t ip[4];

43        uint8_t subnet_mask[4];

44        uint8_t gateway[4];

45        uint32_t rx_count;

46        uint32_t tx_count;

47        char hostname[32];

48 } __attribute__((__packed__)) EthernetStatus;

 

scheint der hostname nun ohne die in C übliche Kennung des Endes einer Zeichenkette (0) gespeichert zu werden,

denn sonst würde man eine Länge von 33 Zeichen erwarten. Die 32 Zeichen Länge werden übrigens nochmals unter

ethernet_config.h:33: #define ETHERNET_HOSTNAME_LENGTH 32

definiert.

 

Initialisiert wird der hostname zunächst einmal mit "TBD"

ethernet.h:29:

#define ETHERNET_STATUS_DEFAULT        {{0x40, 0xD8, 0x55, 0x02, 0xA0, 0x00}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, 0, 0, "TBD"}

ethernet.c:48:EthernetStatus ethernet_status = ETHERNET_STATUS_DEFAULT;

und wird in ethernet_low_level_init() dann gesetzt:

ethernet_low_level.c:76: memcpy(ethernet_status.hostname, ec.hostname, ETHERNET_HOSTNAME_LENGTH);

Ob eine Zeichenkette <32 Zeichen nun mit einer 0 endet kann ich gerade auf die Schnelle nicht nachvollziehen.

(In ethernet_low_level_get_default_hostname sehe ich das z.B. nicht.)

 

 

Interessant ist nun die folgende Stelle:

 

master-brick-2.1.2/software/src/extensions/ethernet/ethernet_dhcp.c:

143        // Host name

144        dhcp_message.OPT[i++] = hostName;

145        uint8_t hostname_length = ETHERNET_HOSTNAME_LENGTH;

146        if(ethernet_status.hostname[ETHERNET_HOSTNAME_LENGTH-1] != '\0') {

147                hostname_length = strlen(ethernet_status.hostname);

148        }

149        dhcp_message.OPT[i++] = hostname_length;

150        memcpy((char*)&(dhcp_message.OPT), ethernet_status.hostname, hostname_length);

151

152        i += hostname_length;

153

154        dhcp_message.OPT[i++] = int_to_char(ethernet_status.mac_address[5] % 16);

155

156        dhcp_message.OPT[i++] = dhcpParamRequest;

 

In der dhcp_send_discover Funktion (von dhcp_get_ip() und dhcp_check_timeout() aufgerufen)

wird ab Zeile 145 die Länge des Hostnames bestimmt, wobei diese zunächst auf 32 gesetzt wird.

Die Zeile 146 scheint mir unsinnig! Steht am Ende eine 0 wird das auch durch den strlen-Befehl

detektiert, falls nicht schon vorher eine 0 zu finden ist. Bei einer Zeichenkette mit Länge <32

sollte doch vermutlich eine 0 im Speicher stehen, oder?

 

Das sollte wohl eher "==" statt "!=" heissen!

Falls alle 32 Zeichen verwendet werden und kein Platz mehr für eine 0 ist, so ist die Länge 32.

Mit einem "==" könnte man das folgendermaßen beschreiben:

Nur falls man am Ende noch eine 0 findet, wird die Länge der Zeichenkette ermittelt.

(Man sollte übrigens auch Zeile 240 überprüfen.)

 

 

Und was macht Zeilt 154? Hier sollte ein neuer Optionscode kommen

und dann dieser seltsame aus der MAC Adresse generierte Wert "5"...

 

Option: (t=53,l=55) DHCP Message Type length isn't 1

Padding (205 bytes)

 

"5"=53 steht nun für "DHCP Message Type" und erwartet eine 1 als nächsten

Wert, da es nur einen Parameter gibt. Es folgt aber 55 für den

dhcpParamRequest Optionscode und alles ist "verschoben"...

 

Das war das eigentliche Problem in den DHCP discovery Paketen hier.

Und deshalb würde ich die 154 zumindest einmal auskommentieren...

 

 

Auch wenn der eine oder andere DHCP Server trotzdem antwortet, so sind diese Pakete hier nicht standardkonform.

Das scheint mir ein bug zu sein!

 

 

Eigentlich wollte ich fragen, ob das bei anderen wirklich funktioniert,

aber anscheinend gibt es ja nicht nur bei mir Probleme.

Ich bin am überlegen, ob ich versuche das zu fixen und einen Patch zu erstellen.

Aber evtl. wird das ja sowieso gerade gemacht...

 

 

Martin

 

[borg]

Danke für die ausführliche Recherche.

 

In Zeile 146 muss in der Tat ein == verwendet werden. Strings die über unser Protokoll gehen (das gilt für alle Strings, nicht nur den Hostnamen) haben eine maximale Länge und sie werden mit '\0' aufgefüllt. Wenn der letzte char !='\0' ist, hat der String die maximale Länge (32 beim Hostnamen).

 

Die Zeile dort ist allerdings nicht unnötig (wenn sie gefixt ist). Dadurch wird sicher gestellt dass strlen nicht über das Array hinauslaufen kann.

 

Soweit ich den Standard verstehe sind 0-terminierte Strings aber sogar OK beim hostnamen, das ist also unproblematisch.

 

Zeile 154 auf der anderen Seite ist ein offensichtlicher copy&paste Fehler. Ich hab das hinzufügen der Mac Adresse zum default Hostnamen irgendwann von dort nach ethernet_low_level.c Zeile 57ff verschoben.

 

Werde ich morgen fixen.

 

Zu deiner allgemeinen Frage: Ich hab vor diesem Thread noch nie von Problem mit DHCP gehört, zu den Tests die wir mit der Ethernet Extension vorm verschicken machen gehört sogar eine Verbindung über DHCP per Hostname. Grundsätzlich scheint es also mit den meisten Routern zu funktionieren (was natürlich nicht heißt das keine Bugs in meiner selbstgeschriebenen DHCP Implementierung sind ).

 

Danke nochmal für die Hilfe!

[Martin]

Mir ist klar, dass die Abfrage nach dem Sonderfall "alle Zeichen sind belegt" benötigt wird.

Bei einem System, welches etwas mehr Speicher besitzt würde man aber vermutlich einfach

ETHERNET_HOSTNAME_LENGTH+1 statt 32 in ethernet.h:47 verwenden und

im letzte Byte einfach immer eine Null speichern. Man verschwendet so ein Byte,

entledigt sich aber dieses Sonderfalls. Bei einem Brick ist das natürlich etwas anderes!

 

Es ist aber schon seltsam, wie fehlerresistent die getesteten DHCP Server sind.

Da schickt man denen ein Paket, welches sie am Ende vermutlich nicht mehr lesen können

(dhcpParamRequest und folgende) und mit den schon geparsten Daten wird einfach eine Adresse vergeben...

 

Jedenfalls schon einmal im Voraus Danke für das zu erwartende Update!

(Aber jeder Fix birgt auch die Gefahr einen neuen Fehler einzubauen...)

 

Gute Nacht,

Martin

[borg]

Hat ein bisschen Länger gedauert, aber im Anhang findest du eine Version mit gefixter DHCP Implementierung.

 

Compiliert ist der aktuelle HEAD aus dem git: https://github.com/Tinkerforge/master-brick.

 

Über Feedback ob es dein Problem löst würde ich mich freuen!

firmware_brick_master_2_2_0_beta1.bin

[Martin]

Hallo,

 

leider habe ich nun ein Problem, das Firmware Update zu installieren.

Wie in http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing

angegeben, habe ich versucht den Master-Brick in den Bootloader Modus zu versetzen,

indem ich den Erase- und anschließend den Reset-Knopf gedückt habe.

(Wo sich diese Knöpfe befinden ist unter

http://www.tinkerforge.com/de/doc/Hardware/Bricks/Master_Brick.html#anschlussmoglichkeit abgebildet.)

 

Im brickv wird nun unter Updates/Flashing|Brick auch nach einem "Refresh" keinen

"Serial Port" angezeigt. ("No Brick in Bootloader found")

Anscheinend gibt es nun Probleme mit dem USB (obwohl ich vorher keine Probleme hatte).

Das zeigt sich mit dmesg bei mehreren Rechnern:

 

OpenSUSE 13.1:

[30007.682714] usb 1-1.5.5: new full-speed USB device number 18 using ehci-pci

[30022.751541] usb 1-1.5.5: device descriptor read/64, error -110

[30037.921395] usb 1-1.5.5: device descriptor read/64, error -110

[30038.084486] usb 1-1.5.5: new full-speed USB device number 19 using ehci-pci

[30053.153476] usb 1-1.5.5: device descriptor read/64, error -110

[30068.323368] usb 1-1.5.5: device descriptor read/64, error -110

[30068.486595] usb 1-1.5.5: new full-speed USB device number 20 using ehci-pci

[30078.893114] usb 1-1.5.5: device not accepting address 20, error -110

[30078.955169] usb 1-1.5.5: new full-speed USB device number 21 using ehci-pci

[30089.361898] usb 1-1.5.5: device not accepting address 21, error -110

[30089.362059] hub 1-1.5:1.0: unable to enumerate USB device on port 5

 

Ubuntu 12.04.4 LTS:

[ 9006.015191] usb 5-1: new full-speed USB device number 2 using xhci_hcd

[ 9006.059482] usb 5-1: Device not responding to set address.

[ 9006.266562] usb 5-1: Device not responding to set address.

[ 9006.467229] usb 5-1: device not accepting address 2, error -71

[ 9006.635300] usb 5-1: new full-speed USB device number 3 using xhci_hcd

[ 9006.655751] usb 5-1: Device not responding to set address.

[ 9006.862830] usb 5-1: Device not responding to set address.

[ 9007.063310] usb 5-1: device not accepting address 3, error -71

[ 9007.231364] usb 5-1: new full-speed USB device number 4 using xhci_hcd

[ 9007.251939] usb 5-1: Device not responding to set address.

[ 9007.459032] usb 5-1: Device not responding to set address.

[ 9007.663402] usb 5-1: device not accepting address 4, error -71

[ 9007.831453] usb 5-1: new full-speed USB device number 5 using xhci_hcd

[ 9007.846136] usb 5-1: Device not responding to set address.

[ 9008.051226] usb 5-1: Device not responding to set address.

[ 9008.255521] usb 5-1: device not accepting address 5, error -71

[ 9008.255591] hub 5-0:1.0: unable to enumerate USB device on port 1

 

Raspbian (Debian 7.4):

[ 2835.402012] usb 1-1.3: new full-speed USB device number 9 using dwc_otg

[ 2850.482436] usb 1-1.3: device descriptor read/64, error -110

[ 2865.672883] usb 1-1.3: device descriptor read/64, error -110

[ 2865.862914] usb 1-1.3: new full-speed USB device number 10 using dwc_otg

[ 2880.943493] usb 1-1.3: device descriptor read/64, error -110

[ 2896.134035] usb 1-1.3: device descriptor read/64, error -110

[ 2896.323956] usb 1-1.3: new full-speed USB device number 11 using dwc_otg

[ 2906.744050] usb 1-1.3: device not accepting address 11, error -110

[ 2906.824229] usb 1-1.3: new full-speed USB device number 12 using dwc_otg

[ 2917.244408] usb 1-1.3: device not accepting address 12, error -110

[ 2917.244641] hub 1-1:1.0: unable to enumerate USB device on port 3

 

Das ist jetzt zwar etwas "off topic", aber kann mir jemand einen Tipp geben, wie man so ein Firmware Update durchführt?

Jetzt funktioniert gar nichts mehr :-(

 

Danke,

Martin

[borg]

Probier nochmal den Brick in den Bootloader zu versetzen. Du kannst auch einfach während du den USB Stecker reinsteckst den Erase Knopf gedrückt halten, das ist manchmal einfacher.

[kreaktiv]

Ich habe nun auch das gleiche Problem.

Ethetnet (mit POE) steckt auf dem Master.

USB am Master. -> keine Reaktion, kein Led.

Ethernet mit Stromversorgung. -> grüne Led blinkt ca. 1s Takt. MaterLed brennt nicht.

Master lässt sich nicht mehr ansprechen.

[borg]

@kreativ: Der Master ist im Bootloader? Im Bootloader kann er nicht über die Ethernet Extension angesprochen werden, es ist nur möglich über USB eine neue Firmware draufzuspielen.

[kreaktiv]

Zunächst; Glück gehabt. Er läuft wieder.

 

Was es genau war kann ich nicht sagen.

Ich habe den EtherNet auf dem Master gehabt. Sonnst nichts dran.

Über USB am Mac angeschlossen. Dan hab ich versucht die neue Firmware (beta1) zu laden. Dabei muss wohl etwas schief gegangen sein. Auf jedenfall war der Master nun tot. Keine Reaktion, kein Led und kein Kontakt zum BrickViewer.

Was ich gemacht habe:

Alles ausgeschaltet, den Master von EthernetBrick befreit, ein Holzscheit draussen geholt und in den Ofen gelegt. Den Mac gestartet und den Master über USB angesteckt. BrickViwer gestartet und zuerst die alte Firmware auf den Master gespielt. Funktioniert, der Master arbeitet wieder. Danach konnte ich nun auch die neue Firmware aufspielen.

Keine Ahnung war da los war. Einziger Unterschied vorher war der EthernetBrick auf dem Master, und jetzt nur noch der Master alleine.

[Loetkolben]

Raeusper.

 

Darf ich noch einen Hinweis aus den FAQ zitieren:

 

 

Master Brick 2.0 im Stack mit Master Extension:

Master Brick Hardware Version 2.0 hat eine Änderung im Leiterplattenlayout die den Bootloader Modus stört wenn eine Master Extension wie WIFI, RS485 oder Ethernet im Stack vorhanden ist. In diesem Fall muss die Master Extension aus dem Stack entfernt werden, damit der Bootloader Modus richtig funktioniert.

 

Der Loetkolben

[Martin]

Ja, die Master Extension sollte entfernt werden und das könnte man unter

http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing

eigentlich nochmals erwähnen. Das allein hat bei mir aber zunächst noch nichts gebracht.

Erst als ich auf dem Ubuntu Notebook den USB3 Port verwendet habe, bei dem statt

xhci_hcd nun das ohci-pci Kernelmodul verwendet wird, hat es funktioniert:

 

[  758.680573] usb 5-1: new full-speed USB device number 27 using xhci_hcd

[  758.703808] usb 5-1: unable to read config index 0 descriptor/all

[  758.703827] usb 5-1: can't read configurations, error -71

[  758.872597] usb 5-1: new full-speed USB device number 28 using xhci_hcd

[  758.916698] usb 5-1: Device not responding to set address.

[  759.123602] usb 5-1: Device not responding to set address.

[  759.324642] usb 5-1: device not accepting address 28, error -71

[  759.492524] usb 5-1: new full-speed USB device number 29 using xhci_hcd

[  759.518893] usb 5-1: Device not responding to set address.

[  759.723968] usb 5-1: Device not responding to set address.

[  759.924727] usb 5-1: device not accepting address 29, error -71

[  760.092611] usb 5-1: new full-speed USB device number 30 using xhci_hcd

[  760.167091] usb 5-1: Device not responding to set address.

[  760.372159] usb 5-1: Device not responding to set address.

[  760.572619] usb 5-1: device not accepting address 30, error -71

[  760.572689] hub 5-0:1.0: unable to enumerate USB device on port 1

 

[  812.956592] usb 3-1: new full-speed USB device number 3 using ohci-pci

[  813.117263] usb 3-1: New USB device found, idVendor=03eb, idProduct=6124

[  813.117279] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[  813.120355] cdc_acm 3-1:1.0: This device cannot do calls on its own. It is not a modem.

[  813.120485] cdc_acm 3-1:1.0: ttyACM0: USB ACM device

 

und ich konnte die firmware_brick_master_2_2_0_beta1.bin auf den Masterbrick flashen.

Leider habe ich nun ein neues Problem. Die blauen LED leuchten beim Anschliessen per USB

zwar wieder wie gewohnt, der brickv bzw. brickd bekommt aber keine Verbindung hin.

USB2- oder USB3-Anschluss spielt hier keine Rolle:

 

[ 4396.861862] usb 5-1: new full-speed USB device number 8 using xhci_hcd

[ 4396.884649] usb 5-1: New USB device found, idVendor=16d0, idProduct=063d

[ 4396.884665] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 4396.884674] usb 5-1: Product: Master Brick

[ 4396.884682] usb 5-1: Manufacturer: Tinkerforge GmbH

[ 4396.884690] usb 5-1: SerialNumber: XXXXXX

 

$ sudo brickd --debug --libusb-debug

2014-03-22 23:56:50.068939 <I> <other|main_linux.c:394> Brick Daemon 2.0.10 started

2014-03-22 23:56:50.069131 <D> <event|event.c:56> Initializing event subsystem

2014-03-22 23:56:50.069193 <D> <event|event.c:139> Added generic event source (handle: 4, events: 1) at index 0

2014-03-22 23:56:50.069258 <D> <hardware|hardware.c:37> Initializing hardware subsystem

2014-03-22 23:56:50.069299 <D> <usb|usb.c:191> Initializing USB subsystem

2014-03-22 23:56:50.069363 <D> <usb|usb_posix.c:151> Successfully loaded brickd (for libusb symbols)

2014-03-22 23:56:50.069637 <D> <event|event.c:139> Added USB event source (handle: 6, events: 1) at index 1

2014-03-22 23:56:50.069684 <D> <event|event.c:139> Added USB event source (handle: 8, events: 1) at index 2

2014-03-22 23:56:50.069725 <D> <usb|usb.c:217> libusb can handle timeouts on its own

2014-03-22 23:56:50.069762 <D> <usb|usb.c:240> libusb does not support hotplug

2014-03-22 23:56:50.071425 <D> <usb|usb.c:119> Found new USB device (bus: 5, device:

2014-03-22 23:56:50.071496 <D> <usb|usb_stack.c:199> Acquiring USB device (bus: 5, device:

2014-03-22 23:56:50.071656 <D> <event|event.c:139> Added USB event source (handle: 9, events: 1) at index 3

2014-03-22 23:56:50.071700 <D> <event|event.c:139> Added USB event source (handle: 11, events: 1) at index 4

2014-03-22 23:56:50.073204 <D> <usb|usb.c:174> Got told to add libusb pollfd (handle: 12, events: 4)

2014-03-22 23:56:50.073266 <D> <event|event.c:139> Added USB event source (handle: 12, events: 4) at index 5

2014-03-22 23:56:50.266779 <D> <usb|usb.c:183> Got told to remove libusb pollfd (handle: 12)

2014-03-22 23:56:50.266882 <D> <event|event.c:165> Marked USB event source (handle: 12, events: 4) as removed at index 5

2014-03-22 23:56:50.266931 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 5, device: : LIBUSB_ERROR_NO_DEVICE (-4)

2014-03-22 23:56:50.270689 <D> <event|event.c:165> Marked USB event source (handle: 9, events: 1) as removed at index 3

2014-03-22 23:56:50.270759 <D> <event|event.c:165> Marked USB event source (handle: 11, events: 1) as removed at index 4

2014-03-22 23:56:50.270834 <W> <usb|usb.c:134> Ignoring USB device (bus: 5, device: due to an error

2014-03-22 23:56:50.271172 <D> <hotplug|udev.c:273> Initializing udev subsystem

2014-03-22 23:56:50.271205 <D> <hotplug|udev.c:167> Trying to load libudev.so.1

2014-03-22 23:56:50.271569 <D> <hotplug|udev.c:172> Could not load libudev.so.1: libudev.so.1: cannot open shared object file: No such file or directory

2014-03-22 23:56:50.271606 <D> <hotplug|udev.c:173> Trying to load libudev.so.0 instead

2014-03-22 23:56:50.272067 <D> <hotplug|udev.c:189> Successfully loaded libudev.so.0

2014-03-22 23:56:50.272360 <D> <event|event.c:139> Added generic event source (handle: 9, events: 1) at index 6

2014-03-22 23:56:50.272402 <D> <network|network.c:120> Initializing network subsystem

2014-03-22 23:56:50.272514 <D> <network|network.c:205> Started listening to '0.0.0.0' (IPv4) on port 4223

2014-03-22 23:56:50.272551 <D> <event|event.c:139> Added generic event source (handle: 10, events: 1) at index 7

2014-03-22 23:56:50.272583 <D> <event|event.c:213> Starting the event loop

2014-03-22 23:56:50.272609 <D> <event|event.c:189> Removed USB event source (handle: 12, events: 4) at index 5

2014-03-22 23:56:50.272639 <D> <event|event.c:189> Removed USB event source (handle: 11, events: 1) at index 4

2014-03-22 23:56:50.272667 <D> <event|event.c:189> Removed USB event source (handle: 9, events: 1) at index 3

2014-03-22 23:56:50.272694 <D> <event|event_posix.c:207> Starting to poll on 5 event source(s)

2014-03-22 23:56:50.294261 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-22 23:56:50.294360 <D> <event|event_posix.c:253> Handling generic event source (handle: 9, received events: 1) at index 3

2014-03-22 23:56:50.294593 <D> <hotplug|udev.c:257> Received udev event (action: remove, dev node: /dev/bus/usb/005/008, sys name: 5-1)

2014-03-22 23:56:50.297523 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-22 23:56:50.297573 <D> <event|event_posix.c:207> Starting to poll on 5 event source(s)

 

Der "Could not get product string descriptor"-Fehler führt zu einem "Ignoring USB device"

und der brickv zeigt bei einem "Connect" deshalb nur:

"Please check host, check port and check if the Brick Daemon is running"

 

Vielleicht sollte ich nochmals eine (andere) Masterbrick-Firmware flashen...

(Eigentlich besteht aber doch kein Zusammenhang zwischen einem USB product string descriptor und DHCP, oder?)

 

Gute Nacht,

Martin

 

[borg]

@Martin: Das ist Ubuntu 12.04? Vielleicht hat libusb dort noch keinen richtigen Support für XHCI? Kannst du das (geflashte) Brick nochmal an einem USB 2 Port testen?

 

Also Grundsätzlich sollte sowohl die normale Brick-Firmware als auch der Bootloader mit USB 2 und 3 funktionieren. Ältere libusb und brickd Versionen hatten da Probleme unter Windows, die sollten aber mittlerweile behoben sein. Unter Linux sind mir keine Probleme bekannt.

[Martin]

Ja, es ist wie bereits erwähnt ein Ubuntu 12.04.4 LTS Netbook, mit dem der brickv/brickd bereits erfolgreich liefen.

 

Wie ich bereits geschrieben habe, hat es auch mit USB 2 nicht funktioniert. (Ich hatte nur USB2 und USB3 verwechselt.)

Am USB2 Port meldet sich der Masterbrick laut dmesg zunächst ebenfalls problemlos an und der brickd zeigt keine Fehlermeldungen,

aber brickv findet leider ebenfalls nichts...

 

$ dmesg | tail -n 6

[ 4380.955183] usb 3-1: new full-speed USB device number 7 using ohci-pci

[ 4381.129497] usb 3-1: New USB device found, idVendor=16d0, idProduct=063d

[ 4381.129513] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 4381.129522] usb 3-1: Product: Master Brick

[ 4381.129530] usb 3-1: Manufacturer: Tinkerforge GmbH

[ 4381.129537] usb 3-1: SerialNumber: XXXXXX

 

$ sudo brickd --debug --libusb-debug

2014-03-23 21:17:36.321319 <I> <other|main_linux.c:394> Brick Daemon 2.0.10 started

2014-03-23 21:17:36.321791 <D> <event|event.c:56> Initializing event subsystem

2014-03-23 21:17:36.322035 <D> <event|event.c:139> Added generic event source (handle: 4, events: 1) at index 0

2014-03-23 21:17:36.322257 <D> <hardware|hardware.c:37> Initializing hardware subsystem

2014-03-23 21:17:36.322469 <D> <usb|usb.c:191> Initializing USB subsystem

2014-03-23 21:17:36.322709 <D> <usb|usb_posix.c:151> Successfully loaded brickd (for libusb symbols)

2014-03-23 21:17:36.323187 <D> <event|event.c:139> Added USB event source (handle: 6, events: 1) at index 1

2014-03-23 21:17:36.323422 <D> <event|event.c:139> Added USB event source (handle: 8, events: 1) at index 2

2014-03-23 21:17:36.323635 <D> <usb|usb.c:217> libusb can handle timeouts on its own

2014-03-23 21:17:36.323877 <D> <usb|usb.c:240> libusb does not support hotplug

2014-03-23 21:17:36.325740 <D> <usb|usb.c:119> Found new USB device (bus: 3, device: 7)

2014-03-23 21:17:36.326008 <D> <usb|usb_stack.c:199> Acquiring USB device (bus: 3, device: 7)

2014-03-23 21:17:36.326357 <D> <event|event.c:139> Added USB event source (handle: 9, events: 1) at index 3

2014-03-23 21:17:36.326574 <D> <event|event.c:139> Added USB event source (handle: 11, events: 1) at index 4

2014-03-23 21:17:36.328330 <D> <usb|usb.c:174> Got told to add libusb pollfd (handle: 12, events: 4)

2014-03-23 21:17:36.328594 <D> <event|event.c:139> Added USB event source (handle: 12, events: 4) at index 5

2014-03-23 21:17:36.636910 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1b50 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.636995 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1bc8 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.637037 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1c40 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.637078 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1cb8 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.637117 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1d30 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.637154 <I> <usb|usb.c:144> Added USB device (bus: 3, device: 7) at index 0: Master Brick [XXXXXX]

2014-03-23 21:17:36.637486 <D> <hotplug|udev.c:273> Initializing udev subsystem

2014-03-23 21:17:36.637518 <D> <hotplug|udev.c:167> Trying to load libudev.so.1

2014-03-23 21:17:36.637876 <D> <hotplug|udev.c:172> Could not load libudev.so.1: libudev.so.1: cannot open shared object file: No such file or directory

2014-03-23 21:17:36.637912 <D> <hotplug|udev.c:173> Trying to load libudev.so.0 instead

2014-03-23 21:17:36.638376 <D> <hotplug|udev.c:189> Successfully loaded libudev.so.0

2014-03-23 21:17:36.638652 <D> <event|event.c:139> Added generic event source (handle: 13, events: 1) at index 6

2014-03-23 21:17:36.638719 <D> <network|network.c:120> Initializing network subsystem

2014-03-23 21:17:36.638843 <D> <network|network.c:205> Started listening to '0.0.0.0' (IPv4) on port 4223

2014-03-23 21:17:36.638881 <D> <event|event.c:139> Added generic event source (handle: 14, events: 1) at index 7

2014-03-23 21:17:36.638913 <D> <event|event.c:213> Starting the event loop

2014-03-23 21:17:36.638941 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

2014-03-23 21:17:36.687884 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-23 21:17:36.687949 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5

2014-03-23 21:17:36.687998 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1b50 returned successfully from Master Brick [XXXXXX]

2014-03-23 21:17:36.688020 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: XXXXXX, L: 34, F: 253) from Master Brick [XXXXXX]

2014-03-23 21:17:36.688080 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: XXXXXX, L: 34, F: 253)

2014-03-23 21:17:36.688118 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1b50 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.688137 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-23 21:17:36.688151 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

2014-03-23 21:17:36.688838 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-23 21:17:36.688866 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5

2014-03-23 21:17:36.688892 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1bc8 returned successfully from Master Brick [XXXXXX]

2014-03-23 21:17:36.688909 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jkY, L: 34, F: 253) from Master Brick [XXXXXX]

2014-03-23 21:17:36.688925 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jkY, L: 34, F: 253)

2014-03-23 21:17:36.688949 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1bc8 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.688966 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-23 21:17:36.688979 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

2014-03-23 21:17:36.689846 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-23 21:17:36.689884 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5

2014-03-23 21:17:36.689913 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1c40 returned successfully from Master Brick [XXXXXX]

2014-03-23 21:17:36.689931 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jqv, L: 34, F: 253) from Master Brick [XXXXXX]

2014-03-23 21:17:36.689948 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jqv, L: 34, F: 253)

2014-03-23 21:17:36.689974 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1c40 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.689991 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-23 21:17:36.690004 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

2014-03-23 21:17:36.690855 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-23 21:17:36.690895 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5

2014-03-23 21:17:36.690927 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1cb8 returned successfully from Master Brick [XXXXXX]

2014-03-23 21:17:36.690945 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: hUa, L: 34, F: 253) from Master Brick [XXXXXX]

2014-03-23 21:17:36.690962 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: hUa, L: 34, F: 253)

2014-03-23 21:17:36.690991 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1cb8 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.691008 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-23 21:17:36.691022 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

2014-03-23 21:17:36.691844 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready

2014-03-23 21:17:36.691878 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5

2014-03-23 21:17:36.691906 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1d30 returned successfully from Master Brick [XXXXXX]

2014-03-23 21:17:36.691924 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jny, L: 34, F: 253) from Master Brick [XXXXXX]

2014-03-23 21:17:36.691940 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jny, L: 34, F: 253)

2014-03-23 21:17:36.691965 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1d30 for 80 bytes to Master Brick [XXXXXX]

2014-03-23 21:17:36.691981 <D> <event|event_posix.c:268> Handled all ready event sources

2014-03-23 21:17:36.691995 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s)

 

Aber anscheinend scheint da etwas mit dem Rechner nicht in Ordnung zu sein, denn mit dem RPi klappt es.

Ich hatte dieses Wochenende nur etwas wenig Zeit - ich hätte das gleich alles testen sollen.

Mitte April bekommt das Netbook dann Ubuntu 14.04 LTS und hoffentlich klappt es dann wieder...

 

Die gute Nachricht ist, dass DHCP nun mit der 2.2.0beta Masterbrick Firmware funktioniert!

Ich habe mir mit wireshark die Pakete angesehen und die sehen nun OK aus.

 

Und nun zurück an die Arbeit...

Martin

 

 

[borg]

Die gute Nachricht ist, dass DHCP nun mit der 2.2.0beta Masterbrick Firmware funktioniert!

Oh, das ist sehr gut! Da hatte ich jetzt um ehrlich zu sein gar nicht mit gerechnet. Ich hatte befürchtet das es da ein grundsätzlicheres Problem gibt .