Re: veb(4) exceeds 1514 byte frame size while bridge(4) doesn't?
On Tue, Mar 23, 2021 at 08:24:56PM +1000, David Gwynne wrote:
> 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?
This fixed the problem without introducing any noticeable other effects,
thanks!
> 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 - 1.21
> +++ if_ure.c 23 Mar 2021 10:18:54 -
> @@ -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"));
>
--
Jurjen Oskam
Re: veb(4) exceeds 1514 byte frame size while bridge(4) doesn't?
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 - 1.21
> +++ if_ure.c 23 Mar 2021 10:18:54 -
> @@ -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"));
>
Re: veb(4) exceeds 1514 byte frame size while bridge(4) doesn't?
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.c14 Oct 2020 23:47:55 - 1.21
+++ if_ure.c23 Mar 2021 10:18:54 -
@@ -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"));
