Odroid C1+ running the latest kernel at the time of writing (head of the odroidc-3.10.y branch)
Laptop running a vanilla Ubuntu Linux 16.04 installation, kernel version: 4.4.0-38-generic #57-Ubuntu SMP
The USB OTG port of the Odroid C1+ is connected to a USB 2.0 port of the laptop. The ODroid presents itself as an RNDIS/Ethernet gadget (CDC ECM) towards the laptop.
Ethernet-over-USB networking set up on both sides and the connection works (verified using ping and ssh as well).
Initial symptom:
USB file transfer using scpfrom the ODroid to the laptop is extremely slow (~16 KB/sec). USB file transfer using scpto the ODroid from the laptop runs at acceptable speed (~4 MB/sec).
Further investigation (raw USB packet dumps on the laptop during the copy operation from the ODroid) shows that the URB bulk transfers conveying multiple Ethernet frames typically end up corrupted on the other side because the bulk transfer is aborted with an EOVERFLOW URB error code. This feature was introduced in commit dc9fa48e8; modifying the condition in line 646 of that commit to if (0 && length > MAX_BUFFER_SIZE) resolves the problem because each URB transfer then contains only a single Ethernet frame.
Test setup:
odroidc-3.10.y
branch)4.4.0-38-generic #57-Ubuntu SMP
ping
andssh
as well).Initial symptom:
USB file transfer using
scp
from the ODroid to the laptop is extremely slow (~16 KB/sec). USB file transfer usingscp
to the ODroid from the laptop runs at acceptable speed (~4 MB/sec).Further investigation (raw USB packet dumps on the laptop during the copy operation from the ODroid) shows that the URB bulk transfers conveying multiple Ethernet frames typically end up corrupted on the other side because the bulk transfer is aborted with an
EOVERFLOW
URB error code. This feature was introduced in commit dc9fa48e8; modifying the condition in line 646 of that commit toif (0 && length > MAX_BUFFER_SIZE)
resolves the problem because each URB transfer then contains only a single Ethernet frame.