USB: Failures when nothing plugged into the ethernet port (RPi3), works if plugged in.

[speachy]

The short version is that I'm trying to use a Mitsubishi CP-D80DW printer with an RPi. Then transferring the bulk image data to the printer, the transfer breaks fairly early on (eg in the first 128K or so of ~16MB).

I'm personally using FedBerry (Fedora remix), but this has been reported to me on official Raspbian images too. Interestingly, this problem does not appear to happen on the RPi2 (w/ same kernel rev).

Kernel: 4.9.24-rpi1 (ie Fedora 25 kernel plus all upstream RPi patches)
Firmware: 20170304-1.509beaaa

(This was originally reported to me by a raspbian user, using an official 4.4.38-v7+ RPi kernel, unknown firmware rev. So it's not due to anything special about my setup)

The only thing plugged into the USB ports is the printer itself. (I'm logging in via ssh over the device's wifi adapter)

Bus 001 Device 021: ID 06d3:3b36 Mitsubishi Electric Corp. 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Here's the kicker: If I plug an cable into the ethernet port, I am able to print successfully every time. Note, it's just the physical link that matters, and it doesn't matter if the ethernet interface is "down" or "up" (ie "ifconfig eth0 down") or not, or if there's anything else plugged into the switch (eg a DHCP server or something) -- just whether or not a cable is plugged in.

I have access to a USB protocol analyzer. A quick sniff with the ethernet cable plugged in showed everything working okay, but when the cable was unplugged, the sniff log was overflowing with PING/NAK messages. Over the next couple of days I'll see if I can get a minimal sniff that still demonstrates what's going on, but I can only interpose it between external devices (ie the printer), not the SoC and the RPi hub+ethernet controller.

Incidently, I also have many reports of the Mitsubishi CP-D70DW failing spectacularly on RPI1, 2, and 3 boards. However, using an RPi0 and a generic USB hub, the printer reportedly works.

So there's something funky going on with the SMSC9514 ethernet/hub controller and/or its driver. A physical ethernet link shouldn't cause ripple effects on the rest of the system!

[speachy]

I can provide a great deal of other information on this setup (and the sniffs I mentioned). Just let me know what would be useful.

[P33M]

Is the software for analyzing the USB trace dumps freely available?

If you can just capture the first burst of traffic until everything goes splat, that's usually enough to start looking for a cause of the issue.

Edit: And upload the capture to dropbox or similar, of course.

[speachy]

Yes, the (Windows) software to look at the dumps can be freely downloaded. It works under WINE too, albeit rather slowly.

[P33M]

...and what's it called?

Also, can you provide a sudo lsusb -v listing for the printer device?

[speachy]

It's an ITIC 1480A analyzer, and I'll provide download links when I have sniffs ready. Won't be until after I get back from $dayjob tonight. :)

Bus 001 Device 024: ID 06d3:3b36 Mitsubishi Electric Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x06d3 Mitsubishi Electric Corp.
  idProduct          0x3b36 
  bcdDevice            1.00
  iManufacturer           1 Mitsubishi
  iProduct                2 USB PRINTER
  iSerial                 3 CPD80D078835
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      2 Bidirectional
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

The actual code driving the printer is based on libusb [1], and it detaches the printer from the kernel usblp driver.

Like most dyesub printers I've seen, it claims to be USB Printer Class compliant, but really isn't. The size of the libusb bulk transfer request doesn't appear to matter. Linux's 'usbmon' sniffs show that the posted URB "times out". (I should be able to simultaneously generate one of those to go with the hardware analyser dump..)

[1] http://git.shaftnet.org/cgit/selphy_print.git/

[speachy]

Oh, one other thing I should mention -- the printer has two OUT endpoints; the first can be used for data+commands, but the second can only be use for issuing commands. My code exclusively uses the first one. (This is a common thing for Mitsubishi printers, and the second endpoint can be disabled completely via a configuration command)

[speachy]

Okay, here are two sniffs, compressed with xz:

http://www.shaftnet.org/~pizza/d80-bad.usb.xz
http://www.shaftnet.org/~pizza/d80-good.usb.xz

The software can be downloaded from here:

http://www.internationaltestinstruments.com/topic/6-1480a-usb-protocol-analyzer-software-downloads.aspx

When opening the files, have a bit of patience as the software takes a while to load/parse things. It's not the most efficient thing out there.. Similarly, I didn't spend much time trying to limit the sniff to what is important.

The 'good' one made it all the way through to the end of the print job (with the ethernet cable plugged in), while the 'bad' one died less than 256K into the transfer. The point where things go awry is the 84th 'DATA1' packet [*], where the printer seems to reply with a NYET, at which point the controller starts its PING polling.. and the printer never responds affirmatively.

[*] to jump there, on the lower right pane, hit the 'data packets' item, then 'DATA1 Packets', click on the 'current' field, and type in '84'.

If you look at the previous few DATA1 packets you'll see some were NYETted too, entering the PING/NAK cycle (roughly one every 1.3us) until the printer responded with ACK some time later. However, once things go south, the PING/NAK cycles hit roughly once every 350-500ns, which is nearly 3x the rate of when things worked. Coincidence?

See: http://www.usbmadesimple.co.uk/ums_7.htm#ping

With the good sniff, there's still DATA1 with NYETs, followed by PING/NAK -> PING/ACK cycles, but there's a large pile of incomplete 'IN' transactions to a different device (3, vs the printer's 27) recorded in between each PING cycle. Look at/around DATA1 packet 92 for a representative example.

I'm not as familiar with the low-level USB PHY level as I'd like, but I'll keep poking into these sniffs (with the USB spec pulled up in another window) and add more comments if I gain any additional insights.

[speachy]

It looks like the onboard ethernet adapter puts a considerable amount of traffic on the bus as soon as the ethernet cable is plugged in, drowning out (and thus considerably slowing down) the PING cycles to the printer.

I don't know if the SMSC9514 has any tuning knobs or not, but this printer (and its siblings) aren't the only USB devices that malfunction in some way on RPi boards..

[P33M]

As a differential analysis, what happens if you plug in a USB pendrive and start reading from it? cat /dev/sda > /dev/null for example - it would be interesting to see if the printer starts working with any other bulk traffic on the bus.

Edit: Do you have a comparable USB trace where the printer is being used with an EHCI host (i.e. PC)?

[speachy]

That's an easy enough thing to try out, but I might not be able to get to this until next week (two back-to-back trips..)

[speachy]

Okay, (finally) an update. I plugged in a generic USB2 flash drive, and kicked off a dd to /dev/null -- and the print succeeded. As soon as I stopped the dd, printing failed again.

Oh, I'll capture a sniff with a PC doing the same thing.

[speachy]

I did a run connected to a PC (xHCI), and here it is:

http://www.shaftnet.org/~pizza/d80-pc.usb.xz

[speachy]

The PC's controller has a wide swath of PING/NAK timings -- They start up under 350ns, but the controller appears to incrementally back off PING timing until it settles around 4us. Meanwhile the RPi3 does the opposite, starting slower, and ending faster, which honestly seems a bit backwards.

So it appears as too-short PING timimgs (<1us) effectively cause a denial-of-service problem with this printer famiily. I'm not sure if that's technically a violation of the USB spec or not.

I don't know if there's any way to tune the BC283x's USB controller's PING timing.