On Tue, Mar 23, 2021 at 08:24:56PM +1000, David Gwynne wrote:
>
> 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?
You're right, ure(4) should strip the FCS.
ok kevlo@
> 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"));
>
