summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1838228
blob: e8903fbb3ab43499a63fbbe2c33ca5c06fe1c784 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
graphic: 0.561
mistranslation: 0.424
performance: 0.405
semantic: 0.403
device: 0.400
virtual: 0.302
network: 0.288
user-level: 0.287
socket: 0.251
architecture: 0.236
debug: 0.186
ppc: 0.161
register: 0.155
hypervisor: 0.150
vnc: 0.124
permissions: 0.123
boot: 0.099
PID: 0.097
assembly: 0.095
kernel: 0.087
files: 0.080
x86: 0.078
peripherals: 0.070
arm: 0.070
risc-v: 0.061
i386: 0.059
VMM: 0.051
KVM: 0.047
TCG: 0.046

Slirp Broadcast traffic

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

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().

Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9.

The ticket in the libslirp tracker has been closed a year ago, so I think we can close this ticket here, too.