diff mbox series

[v2,03/13] net: slirp: Pad short frames to minimum size before send

Message ID 20210315075718.5402-4-bmeng.cn@gmail.com (mailing list archive)
State New, archived
Headers show
Series net: Pad short frames for network backends | expand

Commit Message

Bin Meng March 15, 2021, 7:57 a.m. UTC
The minimum Ethernet frame length is 60 bytes. For short frames with
smaller length like ARP packets (only 42 bytes), on a real world NIC
it can choose either padding its length to the minimum required 60
bytes, or sending it out directly to the wire. Such behavior can be
hardcoded or controled by a register bit. Similarly on the receive
path, NICs can choose either dropping such short frames directly or
handing them over to software to handle.

On the other hand, for the network backends like SLiRP/TAP, they
don't expose a way to control the short frame behavior. As of today
they just send/receive data from/to the other end connected to them,
which means any sized packet is acceptable. So they can send and
receive short frames without any problem. It is observed that ARP
packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send
these ARP packets to the other end which might be a NIC model that
does not allow short frames to pass through.

To provide better compatibility, for packets sent from QEMU network
backends, we change to pad short frames before sending it out to the
other end. This ensures a backend as an Ethernet sender does not
violate the spec. But with this change, the behavior of dropping
short frames in the NIC model cannot be emulated because it always
receives a packet that is spec complaint. The capability of sending
short frames from NIC models cannot be supported as well.

This commit should be able to fix the issue as reported with some
NIC models before, that ARP requests get dropped, preventing the
guest from becoming visible on the network. It was workarounded in
these NIC models on the receive path, that when a short frame is
received, it is padded up to 60 bytes.

The following 2 commits seem to be the one to workaround this issue
in e1000 and vmxenet3 before, and should probably be reverted.

  commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
  commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size (60 bytes)")

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 net/slirp.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Jason Wang March 16, 2021, 2:25 a.m. UTC | #1
在 2021/3/15 下午3:57, Bin Meng 写道:
> The minimum Ethernet frame length is 60 bytes. For short frames with
> smaller length like ARP packets (only 42 bytes), on a real world NIC
> it can choose either padding its length to the minimum required 60
> bytes, or sending it out directly to the wire. Such behavior can be
> hardcoded or controled by a register bit. Similarly on the receive
> path, NICs can choose either dropping such short frames directly or
> handing them over to software to handle.
>
> On the other hand, for the network backends like SLiRP/TAP, they
> don't expose a way to control the short frame behavior. As of today
> they just send/receive data from/to the other end connected to them,
> which means any sized packet is acceptable. So they can send and
> receive short frames without any problem. It is observed that ARP
> packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send
> these ARP packets to the other end which might be a NIC model that
> does not allow short frames to pass through.
>
> To provide better compatibility, for packets sent from QEMU network
> backends, we change to pad short frames before sending it out to the
> other end. This ensures a backend as an Ethernet sender does not
> violate the spec. But with this change, the behavior of dropping
> short frames in the NIC model cannot be emulated because it always
> receives a packet that is spec complaint. The capability of sending
> short frames from NIC models cannot be supported as well.
>
> This commit should be able to fix the issue as reported with some
> NIC models before, that ARP requests get dropped, preventing the
> guest from becoming visible on the network. It was workarounded in
> these NIC models on the receive path, that when a short frame is
> received, it is padded up to 60 bytes.
>
> The following 2 commits seem to be the one to workaround this issue
> in e1000 and vmxenet3 before, and should probably be reverted.
>
>    commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
>    commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size (60 bytes)")
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>   net/slirp.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/net/slirp.c b/net/slirp.c
> index be914c0be0..ad2db03182 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -31,6 +31,7 @@
>   #include <pwd.h>
>   #include <sys/wait.h>
>   #endif
> +#include "net/eth.h"
>   #include "net/net.h"
>   #include "clients.h"
>   #include "hub.h"
> @@ -115,6 +116,17 @@ static ssize_t net_slirp_send_packet(const void *pkt, size_t pkt_len,
>                                        void *opaque)
>   {
>       SlirpState *s = opaque;
> +    uint8_t min_buf[ETH_ZLEN];
> +
> +    if (!s->nc.peer->do_not_pad) {
> +        /* Pad to minimum Ethernet frame length */
> +        if (pkt_len < ETH_ZLEN) {
> +            memcpy(min_buf, pkt, pkt_len);
> +            memset(&min_buf[pkt_len], 0, ETH_ZLEN - pkt_len);
> +            pkt = min_buf;
> +            pkt_len = ETH_ZLEN;
> +        }
> +    }


Let's introduce a helper for this padding then it could be reused by at 
least TAP?

Thanks


>   
>       return qemu_send_packet(&s->nc, pkt, pkt_len);
>   }
diff mbox series

Patch

diff --git a/net/slirp.c b/net/slirp.c
index be914c0be0..ad2db03182 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -31,6 +31,7 @@ 
 #include <pwd.h>
 #include <sys/wait.h>
 #endif
+#include "net/eth.h"
 #include "net/net.h"
 #include "clients.h"
 #include "hub.h"
@@ -115,6 +116,17 @@  static ssize_t net_slirp_send_packet(const void *pkt, size_t pkt_len,
                                      void *opaque)
 {
     SlirpState *s = opaque;
+    uint8_t min_buf[ETH_ZLEN];
+
+    if (!s->nc.peer->do_not_pad) {
+        /* Pad to minimum Ethernet frame length */
+        if (pkt_len < ETH_ZLEN) {
+            memcpy(min_buf, pkt, pkt_len);
+            memset(&min_buf[pkt_len], 0, ETH_ZLEN - pkt_len);
+            pkt = min_buf;
+            pkt_len = ETH_ZLEN;
+        }
+    }
 
     return qemu_send_packet(&s->nc, pkt, pkt_len);
 }