如何在 usb-vhci 中启动 USB 批量传输

【问题标题】：How to initiate USB bulk transfers in usb-vhci如何在 usb-vhci 中启动 USB 批量传输
【发布时间】：2016-11-07 09:55:04
【问题描述】：

编辑：重新制定这个问题，因为我已经设法让基础知识发挥作用，但仍然遇到问题。

我正在尝试使用 usb-vhci 模拟 USB 设备（条形码扫描仪）以进行测试，但遇到了一些问题。

给出一些上下文：该设备是一个 CDC 抽象调制解调器，客户端 - 一个 java 程序 - 使用 AT 命令通过串行线路与其通信。

基本上，我的设备已启动并运行，它可以正确注册自己，并且我能够接收来自客户端的命令并做出响应。

主要问题似乎是，一旦设备启动或从主机接收批量传输，它就会触发正在进行的批量传输流和中断 IN 传输（大量，我的 usbmon 日志在几秒钟内增长到 100 MB秒）。

首先在启动时，它不断喷出（主要是）批量 IN 传输，直到我收到 SET_CONTROL_LINE_STATE 请求，然后它们停止。然后，当客户端发送命令（通过串行设备的 AT 命令）时，它会再次启动。

我猜这是因为我没有正确响应某些传输，但我不知道它是什么。

我一直在将我的设备的 usbmon 输出与真实设备的输出进行比较，但到目前为止，我还没有发现任何差异来解释为什么我的模拟设备表现得像这样，而真实设备却没有。 t.

我基本上从 libusb_vhci/examples/virtual_device2.c 中的示例代码开始，并对其进行了修改以模拟实际设备。首先是设备描述符：

const uint8_t dev_desc[] = {
/* Device Descriptor */
0x12,       //bLength           18
0x01,       //bDescriptorType       1
0x00, 0x02, //bcdUSB            2.00
0x02,       //bDeviceClass          2 Communications
0x00,       //bDeviceSubClass       0
0x00,       //bDeviceProtocol       0
0x40,       //bMaxPacketSize0       64
0x5a, 0x06, //idVendor          065a
0x02, 0xa0, //idProduct         a002
0x00, 0x01, //bcdDevice         1.00
0x00,       //iManufacturer         0
0x01,       //iProduct          1
0x00,       //iSerial           0
0x01        //bNumConfigurations        1
};

const uint8_t conf_desc[] = {
/* Configuration Descriptor */
0x09,       //bLength           9
0x02,       //bDescriptorType       2
0x43, 0x00, //wTotalLength          67 ??
0x02,       //bNumInterfaces        2
0x01,       //bConfigurationValue       1
0x00,       //iConfiguration        0
0x80,       //bmAttributes (Bus Powered)    0x80
250,        //MaxPower          500mA

/* Interface Descriptor 0 */
0x09,       //bLength           9
0x04,       //bDescriptorType       4
0x00,       //bInterfaceNumber      0
0x00,       //bAlternateSetting     0
0x01,       //bNumEndpoints         1
0x02,       //bInterfaceClass       2 Communications
0x02,       //bInterfaceSubClass        2 Abstract (modem)
0x00,       //bInterfaceProtocol        0 None
0x00,       //iInterface            0
/* CDC Header */
0x05,       //bLength           7
0x24,       //bDescriptorType       5
0x00,       //bEndpointAddress      0x01 EP 1 OUT
0x10,       //bcdCDC            1.10
0x01,       //"
/* CDC Call Management */
0x05,       //bLength           3
0x24,       //CDC_CS_INTERFACE
0x01,       //CDC_CALL_MANAGEMENT
0x01,       //bmCapabilities        0x01
0x00,       //bDataInterface        0
    /* CDC ACM */
0x04,       //bLength           2
0x24,       //CDC_CS_INTERFACE
0x02,       //CDC_ABSTRACT_CONTROL_MANAGEMENT
0x02,       //bmCapabilities        0x02
/* CDC Union */
0x05,       //bLength           3
0x24,       //CDC_CS_INTERFACE
0x06,       //CDC_UNION
0x00,       //bMasterInterface      0
0x01,       //bSlaveInterface       1
/* Endpoint Descriptor */
0x07,       //bLength           7
0x05,       //bDescriptorType       5
0x83,       //bEndpointAddress      0x83 EP 3 IN
0x03,       //bmAttributes          3
0x40, 0x00, //wMaxPacketSize        0x0040 1x 64 bytes
0x0a,       //bInterval         10      
/* Interface Descriptor 1 */
0x09,       //bLength           9
0x04,       //bDescriptorType       4
0x01,       //bInterfaceNumber      1
0x00,       //bAlternateSetting     0
0x02,       //bNumEndpoints         2
0x0a,       //bInterfaceClass       10 CDC Data
0x00,       //bInterfaceSubClass        0
0x00,       //bInterfaceProtocol        0
0x00,       //iInterface            0
/* Endpoint Descriptor */
0x07,       //bLength           7
0x05,       //bDescriptorType       5
0x01,       //bEndpointAddress      0x01 EP 1 OUT
0x02,       //bmAttributes          2
0x40, 0x00, //wMaxPacketSize        0x0040 1x 64 bytes
0x00,       //bInterval         0
/* Endpoint Descriptor */
0x07,       //bLength           7
0x05,       //bDescriptorType       5
0x82,       //bEndpointAddress      0x82 EP 2 IN
0x02,       //bmAttributes          2
0x40,0x00,  //wMaxPacketSize        0x0040 1x 64 bytes
0x00        //bInterval         0
};

const uint8_t str0_desc[] = {
0x04,       //bLength           4
0x03,       //bDescriptorType       3
0x09, 0x04  //bLanguage             0409 US
};

const uint8_t *str1_desc = 
(uint8_t *)"\x36\x03O\0p\0t\0i\0c\0o\0n\0 \0U\0S\0B\00\0B\0a\0r\0c\0o\0d\0e\0 \0R\0e\0a\0d\0e\0r";

main 函数与示例中的相同，但主要更改了 process_urb() 函数。控制部分基本完好，但我为一些额外的设置数据包添加了处理：

uint8_t rt = urb->bmRequestType;
uint8_t r = urb->bRequest;
if(rt == 0x00 && r == URB_RQ_SET_CONFIGURATION)
{
    devlog("URB_RQ_SET_CONFIGURATION\n");
    urb->status = USB_VHCI_STATUS_SUCCESS;
}
else if(rt == 0x00 && r == URB_RQ_SET_INTERFACE)
{
    devlog("URB_RQ_SET_INTERFACE\n");
    urb->status = USB_VHCI_STATUS_SUCCESS;
}
else if (rt == 0x21 && r == 0x20)
{
    devlog("URB_CDC_SET_LINE_CODING\n");
    urb->status = USB_VHCI_STATUS_SUCCESS;
}
else if (rt == 0x21 && r == 0x22)
{
    devlog("URB_CDC_SET_CONTROL_LINE_STATE\n");
    urb->status = USB_VHCI_STATUS_SUCCESS;
}
else if(rt == 0x80 && r == URB_RQ_GET_DESCRIPTOR)
{
    int l = urb->wLength;
    uint8_t *buffer = urb->buffer;
    devlog("GET_DESCRIPTOR ");
    switch(urb->wValue >> 8)
    {
    case 0:
        puts("WTF_DESCRIPTOR");
        urb->status = USB_VHCI_STATUS_SUCCESS;
        break;
    case 1:
        puts("DEV_DESC");
        if(dev_desc[0] < l) l = dev_desc[0];
        memcpy(buffer, dev_desc, l);
        urb->buffer_actual = l;
        urb->status = USB_VHCI_STATUS_SUCCESS;
        break;
    case 2:
        puts("CONF_DESC");
        if(conf_desc[2] < l) l = conf_desc[2];
        memcpy(buffer, conf_desc, l);
        urb->buffer_actual = l;
        urb->status = USB_VHCI_STATUS_SUCCESS;
        break;
    case 3:
        devlog(" Reading string %d\n", urb->wValue & 0xff);
        switch(urb->wValue & 0xff)
        {
        case 0:
            if(str0_desc[0] < l) l = str0_desc[0];
            memcpy(buffer, str0_desc, l);
            urb->buffer_actual = l;
            urb->status = USB_VHCI_STATUS_SUCCESS;
            break;
        case 1:
            if(str1_desc[0] < l) l = str1_desc[0];
            memcpy(buffer, str1_desc, l);
            urb->buffer_actual = l;
            urb->status = USB_VHCI_STATUS_SUCCESS;
            break;
        default:
            devlog(" Trying to read unknown string: %d\n",urb->wValue & 0xff);
            urb->status = USB_VHCI_STATUS_STALL;
            break;
        }
        break;
    default:
        devlog(" UNKNOWN: wValue=%d (%d)\n",urb->wValue, urb->wValue >> 8);
        urb->status = USB_VHCI_STATUS_STALL;
        break;
    }
}
else
{
    devlog("OTHER bmRequestType %x bRequest %x\n", rt, r);
    urb->status = USB_VHCI_STATUS_STALL;
}

主要问题在于处理非控制传输。这是我当前的实现：

/* handle non-control sequences */
if(!usb_vhci_is_control(urb->type)) {
    /* if we have a BULK OUT transfer */
    if (usb_vhci_is_bulk(urb->type) && usb_vhci_is_out(urb->epadr)) {
        /* we have a bulk out transfer, i.e. a command from client */
        int cmd = get_at_command(urb->buffer, urb->buffer_actual);
        if (cmd == COMMAND_Z1) {
            /* we have request for version, need to wait for the BULK IN transfer */
            last_command = cmd;
        }
        urb->status = USB_VHCI_STATUS_SUCCESS;
        return;
    }

    /* if we have a BULK IN transfer */
    if (usb_vhci_is_bulk(urb->type) && usb_vhci_is_in(urb->epadr)) {
        /* we have a BULK IN transfer, use it to respond to any buffered commands */
        if (last_command) {
            /* send version */
            memcpy(urb->buffer, VERSION_STR, strlen(VERSION_STR));
            urb->buffer_actual = strlen(VERSION_STR);
            last_command = 0;
            urb->status = USB_VHCI_STATUS_SUCCESS;
            return;
        }
    }

    urb->status = USB_VHCI_STATUS_SUCCESS;
    return;
}

这是我在设备启动时得到的 usbmon 日志的 sn-p：

ffff880510727900 266671312 S Bi:5:002:2 -115 128 <
ffff880510727f00 266671315 C Bi:5:002:2 0 0
ffff880510727f00 266671316 S Bi:5:002:2 -115 128 <
ffff880510727cc0 266671319 C Ii:5:002:3 0:8 0
ffff880510727cc0 266671321 S Ii:5:002:3 -115:8 64 <
ffff880514d80900 266671323 S Co:5:002:0 s 21 22 0000 0000 0000 0
ffff880510727780 266671324 C Bi:5:002:2 0 0
ffff880510727780 266671325 S Bi:5:002:2 -115 128 <
ffff8805101096c0 266671329 C Bi:5:002:2 0 0
ffff8805101096c0 266671333 S Bi:5:002:2 -115 128 <
ffff8805107273c0 266671339 C Bi:5:002:2 0 0
ffff8805107273c0 266671344 S Bi:5:002:2 -115 128 <
ffff880510109b40 266671348 C Bi:5:002:2 0 0
ffff880510109b40 266671350 S Bi:5:002:2 -115 128 <
ffff880510109000 266671354 C Bi:5:002:2 0 0
ffff880510109000 266671357 S Bi:5:002:2 -115 128 <
ffff880510727d80 266671360 C Bi:5:002:2 0 0
ffff880510727d80 266671361 S Bi:5:002:2 -115 128 <
ffff880510109a80 266671363 C Bi:5:002:2 0 0
ffff880510109c00 266671370 C Bi:5:002:2 0 0
...

所以，这基本上是我卡住的地方。我有一个几乎可以正常工作的设备，但是大量的传输基本上会阻塞我的系统，使其无用。任何帮助或信息将不胜感激！

【问题讨论】：

    标签： linux usb libusb


    【解决方案1】：

    看来我现在已经能够解决我的大部分问题了，问题确实是我没有正确响应事件。

    在对真实设备的 usbmon 输出进行更详细的分析后，我注意到它使用 -ENOENT 响应了多余的中断传输，而我响应的是 0（即成功）。对 usb-vhci 代码的更多挖掘表明，此错误代码对应于 USB_VHCI_STATUS_CANCELED，一旦我开始对此做出响应，我的设备中的行为与真实设备中的行为相同。本质上，我将此添加到我的 process_urb 的非控制部分：

    /* if we have a INTERRUPT transfer */
if (usb_vhci_is_int(urb->type)) {
    urb->status = USB_VHCI_STATUS_CANCELED;
    return;
}

    不过，我还没有完全摆脱困境。我注意到同样的事情似乎也适用于批量 IN 转账；我在启动过程中得到了很多（一旦设置完成就会停止），这 - 再次 - 似乎不是真实设备的情况，而真实设备 - 再次 - 响应这些（多余的）传输与 -ENOENT。我试过这样做，它似乎工作正常。额外的传输确实停止了，它的行为就像真实设备一样，但不幸的是，它也导致我的设备无法将数据发送回客户端。我修改了我的批量 IN 处理代码如下：

    /* if we have a BULK IN transfer */
if (usb_vhci_is_bulk(urb->type) && usb_vhci_is_in(urb->epadr)) {
    if (last_command) {
        // send version
        memcpy(urb->buffer, VERSION_STR, strlen(VERSION_STR));
        urb->buffer_actual = strlen(VERSION_STR);
        last_command = 0;
        urb->status = USB_VHCI_STATUS_SUCCESS;
    } else {
        urb->status = USB_VHCI_STATUS_CANCELED;
    }
    return;
}

    我认为这应该工作，即如果我在之前的批量 OUT 传输中收到命令，我应该能够使用 IN 传输来响应（正如我一直在做的那样）并且如果没有命令，我只用 -ENOENT 响应。出于某种原因，这不起作用，我不确定为什么。

    关于来自真实设备的跟踪，我注意到的另一件事：虽然它确实使用 -ENOENT 响应这些批量传输，但它们在收到请求后超过 10 秒（！）发送响应！不知道这是怎么回事，但如果有人有想法，我将不胜感激。

    【讨论】：

    • 感谢您的帖子。我刚刚开始研究与此类似的东西，但必须将 VHCI 代码移植到内核 4.15，并处理来自主机的所有 USB 请求，并在内核空间而不是用户空间模拟虚拟设备。您是否能够使用 libusb_vhci 代码处理所有 USB 请求？想知道我的计划是否可行。
    • @luke：我已经有一段时间没有使用它了，但据我所知，我可以处理所有请求。
    猜你喜欢
    • 2017-02-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-29
    • 1970-01-01
    • 2014-02-13
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode