nicht angemeldet
Hardware-Hack
0 0 
Der Martin
0
Hardware-Hack
Schönen guten Abend.
Ich hacke hier gerade an einem Gerät herum (ich beschreib es mal ganz unspezifisch als "Gamepad") und habe es hinbekommen, dieses Teil in einen seltsamen Modus zu versetzen. Nun wüßte ich gerne, was das für ein Modus ist und ob sich was Tolles damit anfangen läßt. :-)
Meine Fragen richten sich also hauptsächlich an die erfahrenen Hard- und Softwarebastler in diesem Forum. Ich denke da beispielsweise an Martin und Alexander. ;-)
Ich kann das Gerät über USB mit meinem Rechner verbinden und kriege in besagtem Modus unter anderem diese Informationen von lsusb:
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Offenbar gibt es 2 Interfaces, nämlich ACM (Abstract Control Model) und CDC Data. Wenn ich dmesg befrage, was sich mit dem Umschalten in diesen seltsamen Modus getan hat, kriege ich das hier als Antwort:
[ 8298.229790] usb 6-2: USB disconnect, address 23
[ 8298.860035] usb 6-2: new full speed USB device using ohci_hcd and address 24
[ 8299.033656] usb 6-2: configuration #1 chosen from 1 choice
[ 8299.034803] cdc_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem.
[ 8299.034840] cdc_acm 6-2:1.0: ttyACM0: USB ACM device
Mit cat /dev/ttyACM0 bekomme ich dann tatsächlich kontinuierlich kleine Datenpakete hingeworfen. Immer nur irgendwelcher Binärmüll, etwa alle 250 ms, immer zwei Bytes auf einmal (was ich verwirrend finde, weil ja die maximale Paketgröße laut Interface-Deskriptor 8 Bit beträgt): FF 40 FF 40 FF 40 FF 29 FF 40 FF 40 FF 40 FF 40 FF 53 FF 40 FF 29 ... Kein erkennbares Muster außer eben eine Hälfte der 16-Bit-Happen immer FF.
Das Gerät hat ein paar Knöpfe. Die zu drücken scheint keinen Einfluß auf diesen Output zu haben. Nun hab ich versucht, mit dem Gerät in diesem Modus irgendwie Kontakt aufzunehmen, etwas an ttyACM0 zu schreiben (V.25-Kommandos beispielsweise). Aber das brachte keine bemerkbare Veränderung im Output.
Ehrlich gesagt, weiß ich nicht so recht, was ich hier eigentlich vor mir habe. Ein Gerät, das in diesem Modus so ein bißchen wie Modem tut aber keins ist. Die Daten scheinen ja über den Interrupt-Endpoint auf meinem Rechner anzukommen. Kann jemand (vielleicht im V.25-Kontext) etwas in diese Daten hineininterpretieren? Und krieg ich irgendwie auch Kommunikation in die andere Richtung hin? Dieses CDC-Interface scheint ja Enpoints für beide Richtungen zur Verfügung zu stellen ... So richtig durchschaut habe ich diese seltsamen Interfaces allerdings noch nicht.
Frage über Fragen. Bin gespannt, ob jemand helfen kann.
Beste Grüße
Alex
-
Moin Moin!
Ich hacke hier gerade an einem Gerät herum (ich beschreib es mal ganz unspezifisch als "Gamepad") und habe es hinbekommen, dieses Teil in einen seltsamen Modus zu versetzen. Nun wüßte ich gerne, was das für ein Modus ist und ob sich was Tolles damit anfangen läßt. :-)
Meine Fragen richten sich also hauptsächlich an die erfahrenen Hard- und Softwarebastler in diesem Forum. Ich denke da beispielsweise an Martin und Alexander. ;-)
Na wenn Du so fragst ...
Ich kann das Gerät über USB mit meinem Rechner verbinden und kriege in besagtem Modus unter anderem diese Informationen von
lsusb:Configuration Descriptor:
[...]
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)[...]
Gratuliere, Du hast Dein Gamepad zu einem Modem umfunktioniert. ;-) > > Offenbar gibt es 2 Interfaces, nämlich ACM (Abstract Control Model) und CDC Data. Wenn ich dmesg befrage, was sich mit dem Umschalten in diesen seltsamen Modus getan hat, kriege ich das hier als Antwort: > > [ 8298.229790] usb 6-2: USB disconnect, address 23 > [ 8298.860035] usb 6-2: new full speed USB device using ohci\_hcd and address 24 > [ 8299.033656] usb 6-2: configuration #1 chosen from 1 choice > [ 8299.034803] cdc\_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem. ^-- Die Meldung würde ich mal im Kernel-Source suchen. Mich würde echt interessieren, wie Linux auf diese Idee kommt. > [ 8299.034840] cdc\_acm 6-2:1.0: ttyACM0: USB ACM device > Ehrlich gesagt, weiß ich nicht so recht, was ich hier eigentlich vor mir habe. Ein Gerät, das in diesem Modus so ein bißchen wie Modem tut aber keins ist. Die Daten scheinen ja über den Interrupt-Endpoint auf meinem Rechner anzukommen. Kann jemand (vielleicht im V.25-Kontext) etwas in diese Daten hineininterpretieren? Und krieg ich irgendwie auch Kommunikation in die andere Richtung hin? Dieses CDC-Interface scheint ja Enpoints für beide Richtungen zur Verfügung zu stellen ... So richtig durchschaut habe ich diese seltsamen Interfaces allerdings noch nicht. Ich hab so den Verdacht, dass das ein Interface zu einem Firmware-Updater ist. Oder vielleicht auch nur ein gut versteckters Debugger-Interface, was nur dem Entwickler der Software auf dem Microcontroller hilft. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Ich kann das Gerät über USB mit meinem Rechner verbinden und kriege in besagtem Modus unter anderem diese Informationen von
lsusb:Configuration Descriptor:
[...]
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
[...]> > Gratuliere, Du hast Dein Gamepad zu einem Modem umfunktioniert. ;-) Hehe, genau. Nur momentan ein ziemlich nutzloser, weil er nicht mit mir reden will. Oder nicht zuhört. Ich weiß noch nicht so genau. > > Offenbar gibt es 2 Interfaces, nämlich ACM (Abstract Control Model) und CDC Data. Wenn ich dmesg befrage, was sich mit dem Umschalten in diesen seltsamen Modus getan hat, kriege ich das hier als Antwort: > > > > [ 8298.229790] usb 6-2: USB disconnect, address 23 > > [ 8298.860035] usb 6-2: new full speed USB device using ohci\_hcd and address 24 > > [ 8299.033656] usb 6-2: configuration #1 chosen from 1 choice > > [ 8299.034803] cdc\_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem. > > ^-- Die Meldung würde ich mal im Kernel-Source suchen. Mich würde echt interessieren, wie Linux auf diese Idee kommt. Die letzte Zeile meinst Du? Findest Du in [cdc-acm.c](https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c), wenn Dir das was sagt. Ich habe das so interpretiert, daß es eben nicht als \*echter\* Modem gehandelt wird, weil das Gerät ja (wegen der grundlegenden Funktionsweise von USB) selber keine Kommunikation starten kann, sondern immer nur auf Polling vom Host reagiert. Das sollte aber prinzipiell kein Grund sein, nicht zu funktionieren, falls Du auf sowas hinaus wolltest. > Ich hab so den Verdacht, dass das ein Interface zu einem Firmware-Updater ist. Oder vielleicht auch nur ein gut versteckters Debugger-Interface, was nur dem Entwickler der Software auf dem Microcontroller hilft. Das ist auch meine Vermutung. Oder eher: meine Hoffnung. ;-) Umso schöner wäre es, tatsächlich mit diesem "Modem" kommunizieren zu können. Hast Du irgendwelche Erfahrungen mit USB CDC/ACM? Ich bin ziemlich erschlagen von den Informationen, die ich zu diesem Schlagwort im Netz finde. Das allermeiste scheint davon auszugehen, daß dem Leser schon völlig klar ist, wie alles im Detail funktioniert und er nur gerne irgendwelche speziellen Probleme in Treibern o. ä. lösen möchte. Ansonsten bin ich immer noch dabei, den entsprechenden, hundertzwanzigseitigen Teil des USB-Standards durchzuackern, in der Hoffnung, daraus zumindest mal die grundlegende Funktionsweise rekonstruieren zu können. Was mich z. B. irritiert, ist der Umstand, daß das Control Interface vom Gerät zum Host geht (ein USB Interrupt IN-Endpoint) und nicht in die andere Richtung ... Beste Grüße Alex-
Moin Moin!
Gratuliere, Du hast Dein Gamepad zu einem Modem umfunktioniert. ;-)
Hehe, genau. Nur momentan ein ziemlich nutzloser, weil er nicht mit mir reden will. Oder nicht zuhört. Ich weiß noch nicht so genau.
Ich geh mal davon aus, dass Du die Standard-Prozeduren "Stecker raus Stecker rein" und "Reboot tut immer gut" schon erfolglos durchprobiert hast.
Offenbar gibt es 2 Interfaces, nämlich ACM (Abstract Control Model) und CDC Data. Wenn ich dmesg befrage, was sich mit dem Umschalten in diesen seltsamen Modus getan hat, kriege ich das hier als Antwort:
[ 8298.229790] usb 6-2: USB disconnect, address 23
[ 8298.860035] usb 6-2: new full speed USB device using ohci_hcd and address 24
[ 8299.033656] usb 6-2: configuration #1 chosen from 1 choice
[ 8299.034803] cdc_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem.^-- Die Meldung würde ich mal im Kernel-Source suchen. Mich würde echt interessieren, wie Linux auf diese Idee kommt.
Die letzte Zeile meinst Du? Findest Du in cdc-acm.c, wenn Dir das was sagt.
Das ist mir schon klar.
switch (buffer[2]) { // ... case USB_CDC_CALL_MANAGEMENT_TYPE: call_management_function = buffer[3]; call_interface_num = buffer[4]; if ((quirks & NOT_A_MODEM) == 0 && (call_management_function & 3) != 3) dev_err(&intf->dev, "This device cannot do calls on its own. It is not a modem.\n"); break;Was ich meine ist, warum rennt Linux in den Fehler rein? Warum ist das NOT_A_MODEM-Flag in quirks nicht gesetzt und warum sind in call_management_function die beiden niedrigsten Bits nicht gesetzt?
Etwas weiter unten wird in quirks via driver_info das Flag gesetzt, aber nur für ein Lego-USB-Device:
/* Support Lego NXT using pbLua firmware */ { USB_DEVICE(0x0694, 0xff00), .driver_info = NOT_A_MODEM, },Ich habe das so interpretiert, daß es eben nicht als *echter* Modem gehandelt wird, weil das Gerät ja (wegen der grundlegenden Funktionsweise von USB) selber keine Kommunikation starten kann, sondern immer nur auf Polling vom Host reagiert. Das sollte aber prinzipiell kein Grund sein, nicht zu funktionieren, falls Du auf sowas hinaus wolltest.
Linux mag das Ding nicht, weil es sich wie ein Modem meldet, aber offenbar nicht die notwendigen Call-Management-Funktionen (was auch immer das sein soll) implementiert UND niemand Linux erzählt hat, das das normal ist (siehe Lego).
Ich hab so den Verdacht, dass das ein Interface zu einem Firmware-Updater ist. Oder vielleicht auch nur ein gut versteckters Debugger-Interface, was nur dem Entwickler der Software auf dem Microcontroller hilft.
Das ist auch meine Vermutung. Oder eher: meine Hoffnung. ;-) Umso schöner wäre es, tatsächlich mit diesem "Modem" kommunizieren zu können.
Hast Du irgendwelche Erfahrungen mit USB CDC/ACM?
Nö, leider nicht.
Ich bin ziemlich erschlagen von den Informationen, die ich zu diesem Schlagwort im Netz finde. Das allermeiste scheint davon auszugehen, daß dem Leser schon völlig klar ist, wie alles im Detail funktioniert und er nur gerne irgendwelche speziellen Probleme in Treibern o. ä. lösen möchte. Ansonsten bin ich immer noch dabei, den entsprechenden, hundertzwanzigseitigen Teil des USB-Standards durchzuackern, in der Hoffnung, daraus zumindest mal die grundlegende Funktionsweise rekonstruieren zu können.
USB ist ein riesiger Haufen Spezifikationen, und ich blicke da auch noch nicht so richtig durch.
Was mich z. B. irritiert, ist der Umstand, daß das Control Interface vom Gerät zum Host geht (ein USB Interrupt IN-Endpoint) und nicht in die andere Richtung ...
USB ist kein Bus. Das "Bus" ist Marketing-Speak, keine technische Angabe. USB ist ein Set von Punpt-zu-Punkt-Verbindungen, die eine Baumstruktur bilden. Gleichberechtigung gibt es auch nicht, alle Macht geht vom USB-Host aus. Der USB-Host entscheidet, wer wann was macht. Entsprechend sind auch Richtungsangaben nahezu immer vom Host ausgehend. Auch die Kommunikation läuft nur unter der Kontrolle des Hosts. Und wie auch z.B. bei HTTP (über TCP über IP über Ethernet über Kupferkabel) stapelt USB diverse Protkolle übereinander, teilweise in Hardware, teilweise in Software. Was USB noch schwieriger macht ist, dass immer mehr angeflanscht wurde.
Vielleicht solltest Du mal verraten, über welches Gerät wir hier reden.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-
Hallo,
Meine Fragen richten sich also hauptsächlich an die erfahrenen Hard- und Softwarebastler in diesem Forum. Ich denke da beispielsweise an Martin und Alexander. ;-)
vielen Dank für die Blumen. Ich fühlte mich auch tatsächlich herausgefordert und habe im Lauf des Tages ein paarmal darüber nachgedacht. Aber erstens habe ich keinen Schimmer, was du da wirklich für ein Gerät hast, und zweitens kenne ich das USB-Protokoll (bzw. die diversen Eigenheiten der Geräteklassen) auch nicht so genau.
Offenbar gibt es 2 Interfaces, nämlich ACM (Abstract Control Model) und CDC Data.
CDC steht für Communication Device Class, also eine tty-Schnittstelle oder ein Modem. Aber das war ja schon klar.
Mit
cat /dev/ttyACM0bekomme ich dann tatsächlich kontinuierlich kleine Datenpakete hingeworfen. Immer nur irgendwelcher Binärmüll, etwa alle 250 ms, immer zwei Bytes auf einmal (was ich verwirrend finde, weil ja die maximale Paketgröße laut Interface-Deskriptor 8 Bit beträgt):FF 40 FF 40 FF 40 FF 29 FF 40 FF 40 FF 40 FF 40 FF 53 FF 40 FF 29 ...Kein erkennbares Muster außer eben eine Hälfte der 16-Bit-Happen immer FF.Vermutlich immer ein negativer 16bit-Integerwert.
Frage über Fragen. Bin gespannt, ob jemand helfen kann.
Tut mir leid, da muss ich passen.
Ciao,
Martin--
Dieser Satz wurde in mühsamer Kleinstarbeit aus einzelnen Wörtern zusammengesetzt.
(Hopsel)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
Moin Moin!
Ich streiche mal ein paar Zeilen:
Configuration Descriptor:
Interface Descriptor:
bInterfaceNumber 0
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
Endpoint Descriptor:
bEndpointAddress 0x82 EP 2 IN
wMaxPacketSize 0x0008 1x 8 bytes
Interface Descriptor:
bInterfaceNumber 1
bInterfaceClass 10 CDC Data
Endpoint Descriptor:
bEndpointAddress 0x03 EP 3 OUT
wMaxPacketSize 0x0040 1x 64 bytes
Endpoint Descriptor:
bEndpointAddress 0x81 EP 1 IN
wMaxPacketSize 0x0040 1x 64 bytes> Mit `cat /dev/ttyACM0` bekomme ich dann tatsächlich kontinuierlich kleine Datenpakete hingeworfen. Immer nur irgendwelcher Binärmüll, etwa alle 250 ms, immer zwei Bytes auf einmal (was ich verwirrend finde, weil ja die maximale Paketgröße laut Interface-Deskriptor 8 Bit beträgt): Wie kommst Du auf 8 Bit? lsusb sagt, dass der Endpoint 2 (IN) vom Interface 0 maximal 8 Bytes (64 Bits) verträgt, die beiden Endpoints vom Interface 1 jeweils maximal 64 Bytes (512 Bits). Interface 1 entspricht in etwa den RxD- und TxD-Leitungen einer RS232-Schnittstelle, entsprechend wird cat /dev/ttyACM0 dessen Endpoint 1 (IN) ansprechen. Das Interface 0 entspricht den Handshake-Leitungen, das erreichst Du nur per ioctl (z.B. mit setserial). Hast Du schon usb\_modeswitch probiert? Wenn im Gerät ein AVR-Controller (ATmega, ATtiny) steckt, mach Dich mal auf die Suche nach USB-Bootloadern für AVR-Controller. Die verhalten sich gerne wie ein AVR-Programmer, bis man sie mit einer "magischen" Sequenz ausschaltet. Manche Bootloader werden auch nur dann als USB-Gerät aktiv, wenn sie von der Hardware per Jumper o.ä. dazu gebracht werden. (Bei einem Gamepad wäre ein sinnvoller Weg, beim Anschließen eine nicht versehentlich drückbare Kombination von Buttons zu drücken - oder auch nur einen der vielen Buttons.) Und nicht zuletzt dient der Bootloader auch als Panik-Funktion für das Hauptprogramm. Wenn das Hauptprogramm gar nicht mehr starten will, schlägt irgendwann ein Hardware-Watchdog zu und übergibt die Kontrolle wieder an den Bootloader, so dass man ein beschädigtes Hauptprogramm ohne Hardware-Programmer neu flashen kann. Für Microchips PIC-Controller gilt sinngemäß das selbe. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Ich streiche mal ein paar Zeilen:
Configuration Descriptor:
Interface Descriptor:
bInterfaceNumber 0
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
Endpoint Descriptor:
bEndpointAddress 0x82 EP 2 IN
wMaxPacketSize 0x0008 1x 8 bytes
Interface Descriptor:
bInterfaceNumber 1
bInterfaceClass 10 CDC Data
Endpoint Descriptor:
bEndpointAddress 0x03 EP 3 OUT
wMaxPacketSize 0x0040 1x 64 bytes
Endpoint Descriptor:
bEndpointAddress 0x81 EP 1 IN
wMaxPacketSize 0x0040 1x 64 bytes> > Mit `cat /dev/ttyACM0` bekomme ich dann tatsächlich kontinuierlich kleine Datenpakete hingeworfen. Immer nur irgendwelcher Binärmüll, etwa alle 250 ms, immer zwei Bytes auf einmal (was ich verwirrend finde, weil ja die maximale Paketgröße laut Interface-Deskriptor 8 Bit beträgt): > > Wie kommst Du auf 8 Bit? lsusb sagt, dass der Endpoint 2 (IN) vom Interface 0 maximal 8 Bytes (64 Bits) verträgt, die beiden Endpoints vom Interface 1 jeweils maximal 64 Bytes (512 Bits). Argh, richtig. Bytes, nichts Bits. Ich war nach der ganzen Lektüre an dem Abend wohl schon etwas weich in der Birne. ;-) > Interface 1 entspricht in etwa den RxD- und TxD-Leitungen einer RS232-Schnittstelle, entsprechend wird cat /dev/ttyACM0 dessen Endpoint 1 (IN) ansprechen. Soweit ich verstanden habe, sollte der OUT-Endpoint bei Geräten, die USB CDC/ACM implementieren, aber genauso über `echo <irgendein AT-Kommando> > /dev/ttyACM0` mit Daten bestückt werden können. Nur passiert in diesem Fall bei mir gar nichts. > Hast Du schon usb\_modeswitch probiert? Nein, das kannte ich gar nicht. Sieht zwar auf den ersten Blick nicht so aus, als hätte das mit meinem Problem zu tun (ich will ja gar nicht mit einem anderen Interface des Geräts kommunizieren, sondern nur über den OUT-Endpoint des momentanen), aber ich probiere das vorsichtshalber trotzdem mal aus.-
Hier muß ich mich korrigieren:
Hast Du schon usb_modeswitch probiert?
Nein, das kannte ich gar nicht. Sieht zwar auf den ersten Blick nicht so aus, als hätte das mit meinem Problem zu tun (ich will ja gar nicht mit einem anderen Interface des Geräts kommunizieren, sondern nur über den OUT-Endpoint des momentanen), aber ich probiere das vorsichtshalber trotzdem mal aus.
Das war vermutlich Quatsch, denn die einzige Kommunikation, die gerade stattfindet, scheint ja über das Interface 0 und dessen Interrupt-IN-Endpoint zu laufen. Zumindest würde zu dem beschriebenen Output passen, den ich empfange.
-
Moin Moin!
Hier muß ich mich korrigieren:
Hast Du schon usb_modeswitch probiert?
Nein, das kannte ich gar nicht. Sieht zwar auf den ersten Blick nicht so aus, als hätte das mit meinem Problem zu tun (ich will ja gar nicht mit einem anderen Interface des Geräts kommunizieren, sondern nur über den OUT-Endpoint des momentanen), aber ich probiere das vorsichtshalber trotzdem mal aus.
Das war vermutlich Quatsch, denn die einzige Kommunikation, die gerade stattfindet, scheint ja über das Interface 0 und dessen Interrupt-IN-Endpoint zu laufen. Zumindest würde zu dem beschriebenen Output passen, den ich empfange.
Nö, Interface 0 ist Handshake, Interface 1 liefert Daten für cat und nimmt Daten von echo entgegen. So verstehe ich jedenfalls die Ausgabe von lsusb.
usb_modeswitch ist hauptsächlich für UMTS-Sticks und ähnliches Gerümpel gedacht, dass sich meistens erst einmal als USB Storage Device oder USB CDROM meldet, um Treiber und Software in ein Windoof-System zu implantieren. Erst mit etwas "Magie" aus der just installierten Software oder eben usb_modeswitch wird die eigentliche Gerätefunktion freigeschaltet und das Storage-Device verschwindet.
Es wäre übrigens viel leichter, wenn Du uns verraten würdest, mit welchem Gerät (USB-Vendor-ID, USB-Product-ID) Du arbeitest.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-