Kingsun KS-959 USB IrDA dongle protocol - help needed with control urb for reception

A few days ago I received help from Domen Puncer, who cracked the 
remaining obfuscation protocols used by the Kingsun KS-959 USB IrDA 
dongle. Over the weekend, I then tried to write the driver for it 
(current state is in tarball attached). However, I have stumbled into a 
roadblock on the control urb for reception, and I need your advice on 
how to proceed.

The attached driver is *not yet functional* because of this problem.

As indicated in my post at:

http://sourceforge.net/mailarchive/forum.php?thread_name=4651EDD0.4060504%40ceibo.fiec.espol.edu.ec&forum_name=irda-users

this dongle is a very weird one. Long story short, it uses control 
packets (not interrupt or bulk) for data transfers, and also performs 
obfuscation (in the form of XOR with variable single-byte keys) on the 
traffic, which consists of wrapped SIR frames. There are full details on 
the protocol (as gleaned from SnoopyPro logs) at the start of the source 
file ks-959.c in the tarball.

The problem is that I am getting a delayed -EPIPE (-32) on the 
submission callback of the control urb on reception. This -EPIPE is 
visible in the output of usbmon inside the tarball.

This urb is prepared as follows:

    /* Start first reception */
    kingsun->rx_setuprequest->bRequestType = USB_DIR_OUT | 
USB_TYPE_STANDARD | USB_RECIP_DEVICE;
    kingsun->rx_setuprequest->bRequest = KINGSUN_REQ_RECV;
    kingsun->rx_setuprequest->wValue = cpu_to_le16(0x0200);
    kingsun->rx_setuprequest->wIndex = cpu_to_le16(0x0000);
    kingsun->rx_setuprequest->wLength = cpu_to_le16(0);
    usb_fill_control_urb(kingsun->rx_urb, kingsun->usbdev,
            usb_rcvctrlpipe(kingsun->usbdev, 0),
            (unsigned char *)kingsun->rx_setuprequest,
            kingsun->rx_buf, KINGSUN_FIFO_SIZE,
            ks959_rcv_irq, kingsun);   
    kingsun->rx_urb->status = 0;
    err = usb_submit_urb(kingsun->rx_urb, GFP_KERNEL);
    if (err) {
        err("ks-959: first urb-submit failed: %d", err);
        goto close_irlap;
    }

This tries to mimic as closely as possible what I am seeing in the 
SnoopyPro logs. According to the logs, the driver sends a control urb 
with 0x00 as bRequestType (USB_DIR_OUT | USB_TYPE_STANDARD | 
USB_RECIP_DEVICE), 0x01 as bRequest, 0x0200 for wValue, 0x0000 for 
wIndex, 0x0000 for wLength, and expects the device to answer with a data 
payload that contains the received data. The actual sequence for the 
setup packet in the logs is [00 01 00 02 00 00 00 00].

The constant KINGSUN_REQ_RECV is defined as 0x01 earlier in the code. I 
can see from the USB headers (linux/usb/ch9.h), that this value is the 
same as USB_REQ_CLEAR_FEATURE. So my first guess is that the setup 
packet is invalid. In particular, I am suspicious of the use of 
USB_DIR_OUT with a request that is supposed to return data. Also, 
USB_REQ_CLEAR_FEATURE is supposed to have an answer without any data 
payload. So I have a couple of questions:

Is this control URB valid?
Will the kernel actually send such a control URB over the wire, when 
requested by the driver?
Can the kernel handle a data payload for this particular kind of request 
(USB_REQ_CLEAR_FEATURE)?
If this control URB is not valid, who is responsible for answering 
-EPIPE? The device (as a response), or the USB stack (because it rejects 
the urb without sending it over the wire)?
Is it possible that the SnoopyPro log is not showing correct data? How 
can I be sure?

Any comments on this are welcome.

Alex Villacís Lasso

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
irda-users mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/irda-users