* [Qemu-devel] [Bug 1838228] [NEW] Slirp Broadcast traffic
@ 2019-07-29 6:29 Chris Koch
2019-07-29 7:59 ` [Qemu-devel] [Bug 1838228] " elmarco
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Chris Koch @ 2019-07-29 6:29 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
Hi all,
Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
I'm running some DHCP traffic to a *custom* DHCP server with user-mode
networking in QEMU. I'm using port 30067 for the server, so this does
not conflict with the built-in DHCP server.
DHCP broadcasts to and from the server, and I'm observing issues with
both sending and receiving packets.
Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway)
makes it to the server, but a packet sent to 255.255.255.255 does not.
I'd suspect that Slirp has to support sending to the broadcast IP
address? Or is this something I can turn on with a configuration option?
(My QEMU version too old?)
Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by
RFC). That means that any return packet will have 0.0.0.0 swapped in as
its destination address. However, that packet doesn't make it into the
VM at all. I know that if you deliver this packet to Linux, a raw socket
will spit it back out. The packets' destination address should not
prevent the packet from being delivered to the right VM, since Slirp
(should?) know exactly which VM the session belongs to. (It's a proxy,
not a router.)
WDYT? Did I miss some configuration options or use too old a version?
Thanks,
Chris
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838228
Title:
Slirp Broadcast traffic
Status in QEMU:
New
Bug description:
Hi all,
Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
I'm running some DHCP traffic to a *custom* DHCP server with user-mode
networking in QEMU. I'm using port 30067 for the server, so this does
not conflict with the built-in DHCP server.
DHCP broadcasts to and from the server, and I'm observing issues with
both sending and receiving packets.
Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway)
makes it to the server, but a packet sent to 255.255.255.255 does not.
I'd suspect that Slirp has to support sending to the broadcast IP
address? Or is this something I can turn on with a configuration
option? (My QEMU version too old?)
Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by
RFC). That means that any return packet will have 0.0.0.0 swapped in
as its destination address. However, that packet doesn't make it into
the VM at all. I know that if you deliver this packet to Linux, a raw
socket will spit it back out. The packets' destination address should
not prevent the packet from being delivered to the right VM, since
Slirp (should?) know exactly which VM the session belongs to. (It's a
proxy, not a router.)
WDYT? Did I miss some configuration options or use too old a version?
Thanks,
Chris
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838228/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Qemu-devel] [Bug 1838228] Re: Slirp Broadcast traffic
2019-07-29 6:29 [Qemu-devel] [Bug 1838228] [NEW] Slirp Broadcast traffic Chris Koch
@ 2019-07-29 7:59 ` elmarco
2019-07-29 18:16 ` Chris Koch
2021-04-22 7:15 ` Thomas Huth
2 siblings, 0 replies; 4+ messages in thread
From: elmarco @ 2019-07-29 7:59 UTC (permalink / raw)
To: qemu-devel
slirp has been moved to a standalone project, can you report here:
https://gitlab.freedesktop.org/slirp/libslirp/issues
I don't have an answer off the top of my head, but I would suggest
looking/tweaking at the network mask. And for the receive side,
debugging from sorecvfrom().
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838228
Title:
Slirp Broadcast traffic
Status in QEMU:
New
Bug description:
Hi all,
Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
I'm running some DHCP traffic to a *custom* DHCP server with user-mode
networking in QEMU. I'm using port 30067 for the server, so this does
not conflict with the built-in DHCP server.
DHCP broadcasts to and from the server, and I'm observing issues with
both sending and receiving packets.
Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway)
makes it to the server, but a packet sent to 255.255.255.255 does not.
I'd suspect that Slirp has to support sending to the broadcast IP
address? Or is this something I can turn on with a configuration
option? (My QEMU version too old?)
Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by
RFC). That means that any return packet will have 0.0.0.0 swapped in
as its destination address. However, that packet doesn't make it into
the VM at all. I know that if you deliver this packet to Linux, a raw
socket will spit it back out. The packets' destination address should
not prevent the packet from being delivered to the right VM, since
Slirp (should?) know exactly which VM the session belongs to. (It's a
proxy, not a router.)
WDYT? Did I miss some configuration options or use too old a version?
Thanks,
Chris
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838228/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Qemu-devel] [Bug 1838228] Re: Slirp Broadcast traffic
2019-07-29 6:29 [Qemu-devel] [Bug 1838228] [NEW] Slirp Broadcast traffic Chris Koch
2019-07-29 7:59 ` [Qemu-devel] [Bug 1838228] " elmarco
@ 2019-07-29 18:16 ` Chris Koch
2021-04-22 7:15 ` Thomas Huth
2 siblings, 0 replies; 4+ messages in thread
From: Chris Koch @ 2019-07-29 18:16 UTC (permalink / raw)
To: qemu-devel
Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9.
** Bug watch added: gitlab.freedesktop.org/slirp/libslirp/issues #9
https://gitlab.freedesktop.org/slirp/libslirp/issues/9
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838228
Title:
Slirp Broadcast traffic
Status in QEMU:
New
Bug description:
Hi all,
Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
I'm running some DHCP traffic to a *custom* DHCP server with user-mode
networking in QEMU. I'm using port 30067 for the server, so this does
not conflict with the built-in DHCP server.
DHCP broadcasts to and from the server, and I'm observing issues with
both sending and receiving packets.
Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway)
makes it to the server, but a packet sent to 255.255.255.255 does not.
I'd suspect that Slirp has to support sending to the broadcast IP
address? Or is this something I can turn on with a configuration
option? (My QEMU version too old?)
Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by
RFC). That means that any return packet will have 0.0.0.0 swapped in
as its destination address. However, that packet doesn't make it into
the VM at all. I know that if you deliver this packet to Linux, a raw
socket will spit it back out. The packets' destination address should
not prevent the packet from being delivered to the right VM, since
Slirp (should?) know exactly which VM the session belongs to. (It's a
proxy, not a router.)
WDYT? Did I miss some configuration options or use too old a version?
Thanks,
Chris
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838228/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 1838228] Re: Slirp Broadcast traffic
2019-07-29 6:29 [Qemu-devel] [Bug 1838228] [NEW] Slirp Broadcast traffic Chris Koch
2019-07-29 7:59 ` [Qemu-devel] [Bug 1838228] " elmarco
2019-07-29 18:16 ` Chris Koch
@ 2021-04-22 7:15 ` Thomas Huth
2 siblings, 0 replies; 4+ messages in thread
From: Thomas Huth @ 2021-04-22 7:15 UTC (permalink / raw)
To: qemu-devel
The ticket in the libslirp tracker has been closed a year ago, so I
think we can close this ticket here, too.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838228
Title:
Slirp Broadcast traffic
Status in QEMU:
Fix Released
Bug description:
Hi all,
Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
I'm running some DHCP traffic to a *custom* DHCP server with user-mode
networking in QEMU. I'm using port 30067 for the server, so this does
not conflict with the built-in DHCP server.
DHCP broadcasts to and from the server, and I'm observing issues with
both sending and receiving packets.
Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway)
makes it to the server, but a packet sent to 255.255.255.255 does not.
I'd suspect that Slirp has to support sending to the broadcast IP
address? Or is this something I can turn on with a configuration
option? (My QEMU version too old?)
Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by
RFC). That means that any return packet will have 0.0.0.0 swapped in
as its destination address. However, that packet doesn't make it into
the VM at all. I know that if you deliver this packet to Linux, a raw
socket will spit it back out. The packets' destination address should
not prevent the packet from being delivered to the right VM, since
Slirp (should?) know exactly which VM the session belongs to. (It's a
proxy, not a router.)
WDYT? Did I miss some configuration options or use too old a version?
Thanks,
Chris
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838228/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-04-22 7:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-29 6:29 [Qemu-devel] [Bug 1838228] [NEW] Slirp Broadcast traffic Chris Koch
2019-07-29 7:59 ` [Qemu-devel] [Bug 1838228] " elmarco
2019-07-29 18:16 ` Chris Koch
2021-04-22 7:15 ` Thomas Huth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.