Yes, I am having exactly the same problem that Shteryana described. I also got messages about wrong ip length when I started dhclient for ue0. If I plug my device into a usb 2.0 port and enable flow control, I get networking speeds that are around 250 Mbit/sec. If flow control is disabled and the device is still connected to the usb 2.0 port, then I get speeds around 200 Mbit/sec. When the device is attached to a usb 3.0 port and the flow control is enabled, I get speeds that are around 128 Mbit/sec. The speeds drop to something like 40 Mbit/sec when the flow control is disabled and the device is still attached to the usb 3.0 port. But I enabled flow control only on one machine. It was the machine to which the device was attached to. I didn't enable flow control on the other machine on the network, but I am sure my speeds won't get much improvement even if it's enabled on both machines. Since I just joined the list, let me copy and paste Shteryana's email message that she wrote a while back:
Hi all, I've experienced a similar problem but didn't get to analyzing it deeper (or reporting) unfortunately ; the device is ugen0.8: <ASIX Elec. Corp. AX88179> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x00ff <Vendor specific> bDeviceSubClass = 0x00ff bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x0b95 idProduct = 0x1790 bcdDevice = 0x0100 iManufacturer = 0x0001 <ASIX Elec. Corp.> iProduct = 0x0002 <AX88179> iSerialNumber = 0x0003 <000000000000C> bNumConfigurations = 0x0001 what I've noticed so far - dhclient complains about wrong ip length - % sudo dhclient ue1 DHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 7 ifconDHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 15 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPOFFER from 192.168.10.1 DHCPREQUEST on ue1 to 255.255.255.255 port 67 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPACK from 192.168.10.1 bound to 192.168.10.7 -- renewal in 3600 seconds. Running iperf3 & watching netstat -i at the same time on the interface in question shows increasing InErrors on the interface - Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ... ue1 1500 <Link#4> 00:0e:c6:c6:db:ea 66333 354 0 35939 0 0 ue1 - 192.168.10.0/24 192.168.10.7 66323 - - 35927 - - Iperf reports ~37.1 Mbits/sec on the interface. If I attach the device on a USB2 port (or force USB2 speed on the port) I was able to get ~ 150-200Mbits on the same system with the same device. This particular system has an Intel Lynx Point USB 3.0 controller pciconf -lv | grep -A 4 xhcixhci0 at pci0 <https://lists.freebsd.org/mailman/listinfo/freebsd-net>:0:20:0: class=0x0c0330 card=0x8179103c chip=0x8c318086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family USB xHCI' class = serial bus subclass = USB ,is running FreeBSD 12.0-CURRENT #19 r315483M (M stands for a patch similar to https://people.freebsd.org/~syrinx/freebsd_xhci-20170318-01.diff needed to trick the controller on that particular system to actually use USB3.0 speeds). The same ASIX AX88179 device worked just fine reaching over 500 Mbits/sec on another system running 11.0-RELEASE-p7 with a different USB 3 controller (will double check and report back at first opportunity). Hope this helps. cheers, Shteryana _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
