On Sun, Mar 21, 2021 at 04:24:24PM +0100, Jurjen Oskam wrote:
> Hi,
>
> When trying out veb(4), I ran into a situation where TCP sessions across a
> veb(4) bridge stalled while the exact same config using bridge(4) worked fine.
>
> After some investigation, it seems that veb(4) adds an FCS to the outgoing
> frame, while bridge(4) doesn't. When this causes the outgoing frame to exceed
> 1514 bytes, the destination doesn't receive it.
>
> I must note that I was using USB NICs, one of them being quite old.
>
> Am I doing something wrong, or is the problem in (one of) the NIC(s)?
it looks like ure(4) hardware doesn't strip the fcs before pushing it to
the host over usb, but the ure(4) driver doesn't strip it.
this usually isn't a huge deal because layers like ip just ignore
the extra bytes. bridge(4) was ok with this because it actually
parses ip packets and removes the extra bytes. veb(4) does a lot less
(by design) so it just lets the fcs on the end of ure packets go out to
other nics.
from what i can tell, ure should remove the fcs. that's what this diff
does. can you try it?
cheers,
dlg
Index: if_ure.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.21
diff -u -p -r1.21 if_ure.c
--- if_ure.c 14 Oct 2020 23:47:55 -0000 1.21
+++ if_ure.c 23 Mar 2021 10:18:54 -0000
@@ -1896,10 +1896,17 @@ ure_rxeof(struct usbd_xfer *xfer, void *
ifp->if_ierrors++;
goto done;
}
+ if (pktlen < ETHER_MIN_LEN) {
+ DPRINTF(("ethernet frame is too short\n"));
+ ifp->if_ierrors++;
+ goto done;
+ }
total_len -= roundup(pktlen, URE_RX_BUF_ALIGN);
buf += sizeof(rxhdr);
+ /* trim fcs */
+ pktlen -= ETHER_CRC_LEN;
m = m_devget(buf, pktlen, ETHER_ALIGN);
if (m == NULL) {
DPRINTF(("unable to allocate mbuf for next packet\n"));
