Cc'ing libSLiRP.
On 2/8/21 7:41 AM, Bin Meng wrote:
> As of today both slirp and tap networking do not pad short frames
> (e.g.: an ARP packet) to the minimum frame size of 60 bytes.
>
> If eTSEC is programmed to reject short frames, ARP requests will be
> dropped, preventing the guest from becoming visible on the network.
>
> The same issue was reported on e1000 and vmxenet3 before, see:
>
> commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
> commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size (60 bytes)")
>
> Ideally this should be fixed on the slirp/tap networking side to
> pad short frames to the minimum frame length, but I am not sure
> whether that's doable.
>
> This commit changes to codes to ignore the RCTRL_RSF setting and
> still allow receiving the short frame. The log message is updated
> to mention the reject short frames functionality is unimplemented.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/net/fsl_etsec/rings.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/hw/net/fsl_etsec/rings.c b/hw/net/fsl_etsec/rings.c
> index 121415a..503b4d3 100644
> --- a/hw/net/fsl_etsec/rings.c
> +++ b/hw/net/fsl_etsec/rings.c
> @@ -502,10 +502,17 @@ ssize_t etsec_rx_ring_write(eTSEC *etsec, const uint8_t *buf, size_t size)
> return -1;
> }
>
> + /*
> + * Both slirp and tap networking do not pad short frames
> + * (e.g.: an ARP packet) to the minimum frame size of 60 bytes.
> + *
> + * If eTSEC is programmed to reject short frames, ARP requests
> + * will be dropped, preventing the guest from becoming visible
> + * on the network.
> + */
> if ((etsec->regs[RCTRL].value & RCTRL_RSF) && (size < 60)) {
> /* CRC is not in the packet yet, so short frame is below 60 bytes */
> - RING_DEBUG("%s: Drop short frame\n", __func__);
> - return -1;
> + RING_DEBUG("%s: Drop short frame not implemented\n", __func__);
> }
>
> rx_init_frame(etsec, buf, size);
>