Paolo Bonzini, on jeu. 04 janv. 2018 18:57:18 +0100, wrote:
> On 04/01/2018 18:45, Samuel Thibault wrote:
> > Paolo Bonzini, on jeu. 04 janv. 2018 18:11:00 +0100, wrote:
> >> On 04/01/2018 16:56, Samuel Thibault wrote:
> >>>> However, adding magic to "-d
Paolo Bonzini, on jeu. 04 janv. 2018 18:11:00 +0100, wrote:
> On 04/01/2018 16:56, Samuel Thibault wrote:
> >> However, adding magic to "-device usb-braille" that creates both a
> >> front-end and a back-end is completely the opposite of sane...
> > Well, this
Paolo Bonzini, on jeu. 04 janv. 2018 16:47:16 +0100, wrote:
> The point of deprecation is not to make the interface simpler, it is to
> avoid cases where one option is doing too much and/or crossing
> abstraction boundaries, for example -net creating both a device and a
> hub port.
>
> "-serial" i
Paolo Bonzini, on jeu. 04 janv. 2018 16:28:27 +0100, wrote:
> On 04/01/2018 16:24, Samuel Thibault wrote:
> >> Maybe we can add "-braille" instead.
> > I guess such legacy-looking option would be frowned up :)
>
> Not really. As long as it doesn't propagate
Hello,
Paolo Bonzini, on jeu. 04 janv. 2018 16:19:02 +0100, wrote:
> On 04/01/2018 15:21, Samuel Thibault wrote:
> > Samuel Thibault, on jeu. 04 janv. 2018 15:15:24 +0100, wrote:
> >> I'm however still unable to make usb-serial and usb-braille work, as
> >
Hello,
Thomas Huth, on jeu. 04 janv. 2018 16:01:24 +0100, wrote:
> On 04.01.2018 15:23, Samuel Thibault wrote:
> > Thomas Huth, on jeu. 04 janv. 2018 15:22:25 +0100, wrote:
> >> On 04.01.2018 14:26, Samuel Thibault wrote:
> >> I think it's more common to not
Thomas Huth, on jeu. 04 janv. 2018 15:22:25 +0100, wrote:
> On 04.01.2018 14:26, Samuel Thibault wrote:
> I think it's more common to not do any magic default setup with
> "-device", but if you think this should be the case here, it can
> certainly be added again
Yes, p
Samuel Thibault, on jeu. 04 janv. 2018 15:15:24 +0100, wrote:
> I'm however still unable to make usb-serial and usb-braille work, as
> mentioned in my other mail :)
Ah, now with the documentation I understand, one has to also pass
-chardev braille,chardev=foobar, and then
-device
Thomas Huth, on jeu. 04 janv. 2018 15:12:56 +0100, wrote:
> On 04.01.2018 15:09, Samuel Thibault wrote:
> > Thomas Huth, on jeu. 04 janv. 2018 14:15:52 +0100, wrote:
> >> -@item host:@var{bus}.@var{addr}
> >> -Pass through the host device identified by @var{bus}.@
Thomas Huth, on jeu. 04 janv. 2018 14:15:52 +0100, wrote:
> -@item host:@var{bus}.@var{addr}
> -Pass through the host device identified by @var{bus}.@var{addr} (Linux only).
> -
> -@item host:@var{vendor_id}:@var{product_id}
> -Pass through the host device identified by @var{vendor_id}:@var{product
Hello,
I'm afraid I can't even work out how to replace -usbdevice braille (or
-usbdevice serial, all questions below apply, except making chardev
default to braille):
... -usbdevice braille
-usbdevice braille: '-usbdevice' is deprecated, please use '-device usb-...'
instead
but -device usb-ser
sched_get/setaffinity linux-user syscalls were missing conversions for
little/big endian, which is hairy since longs may not be the same size
either.
For simplicity, this just introduces loops to convert bit by bit like is
done for select.
Signed-off-by: Samuel Thibault
---
linux-user
Laurent Vivier, on jeu. 28 déc. 2017 18:50:14 +0100, wrote:
> > +for (j = 0; j < abi_ubits; j++, bit++) {
> > +if (mask[bit / ubits] & (1UL << (bit % ubits))) {
>
> You should use __CPUMASK() and introduce a TARGET_CPUMASK().
Err, do we really want to u
Signed-off-by: Samuel Thibault
---
linux-user/syscall.c | 16
1 file changed, 16 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 8ec7de96ce..bb8cb726f5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -296,6 +296,8 @@ _syscall3(int
sched_get/setaffinity linux-user syscalls were missing conversions for
little/big endian, which is hairy since longs may not be the same size
either.
For simplicity, this just introduces loops to convert bit by bit like is
done for select.
Signed-off-by: Samuel Thibault
---
linux-user
heir scripts to the new syntax. Time to remove the
> old parameters now.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Samuel Thibault
> ---
> include/net/net.h | 3 ---
> include/net/slirp.h | 4
> net/slirp.c | 58
> ---
Thomas Huth, on jeu. 07 déc. 2017 19:02:34 +0100, wrote:
> It has never been documented, so hardly anybody knows about this
> parameter, and it is marked as deprecated since QEMU v2.6.
> Time to let it go now.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Samuel Thibault
>
Eric Blake, on lun. 11 déc. 2017 08:30:39 -0600, wrote:
> On 12/10/2017 06:19 PM, Samuel Thibault wrote:
> > Baum device bigger than 84 do not actually exist, some guest drivers
> > would be upset by such sizes.
> >
> > Signed-off-by: Samuel Thibault
>
Baum device bigger than 84 do not actually exist, some guest drivers
would be upset by such sizes.
Signed-off-by: Samuel Thibault
---
chardev/baum.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/chardev/baum.c b/chardev/baum.c
index 67fd783a59..78b0c87625 100644
Peter Maydell, on lun. 04 déc. 2017 15:36:32 +, wrote:
> On 4 December 2017 at 15:26, Samuel Thibault wrote:
> > Peter Maydell, on lun. 04 déc. 2017 15:21:48 +, wrote:
> >> On 4 December 2017 at 15:17, Samuel Th
Hello,
Peter Maydell, on lun. 04 déc. 2017 15:21:48 +, wrote:
> On 4 December 2017 at 15:17, Samuel Thibault
> wrote:
> > warning: redirection vers https://people.debian.org/~sthibault/qemu.git/
> > The following changes since commit 7edaf99759017d3e175e37cffc3536e86a3bd38
Baum device bigger than 84 do not actually exist, some guest drivers
would be upset by such sizes.
Signed-off-by: Samuel Thibault
---
chardev/baum.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/chardev/baum.c b/chardev/baum.c
index 67fd783a59..78b0c87625 100644
warning: redirection vers https://people.debian.org/~sthibault/qemu.git/
The following changes since commit 7edaf99759017d3e175e37cffc3536e86a3bd380:
Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into
staging (2017-11-13 13:54:59 +)
are available
Tao Wu(吴涛@Eng), on jeu. 09 nov. 2017 10:48:27 -0800, wrote:
> Thanks. Actually this is a follow up with my previous effort to fix this bug.
> I was busy on something else and then got lost in that old thread. Now I just
> checked some my local patch
> to see if they've merged to upstream and then f
/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 990132cda9baa27bdc558df6c9c15aacb0322d2c:
slirp: don't zero the whole ti_i when m == NULL (2017-11-09 18:59:22 +0100)
slirp up
d fix some rare cases (some RST cases, keep alive probes)
where packets would be sent to 0.0.0.0.
Signed-off-by: Tao Wu
Signed-off-by: Samuel Thibault
---
slirp/tcp_subr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
index
Hello,
Tao Wu, on mer. 08 nov. 2017 14:53:40 -0800, wrote:
> The current code looks buggy, we zero ti_i while we access
> ti_dst/ti_src later.
Mmm, indeed, looking again at how it was introduced, it was too much.
Samuel
Hello,
Philippe Mathieu-Daudé, on ven. 06 oct. 2017 20:49:31 -0300, wrote:
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -869,7 +869,7 @@ net_init_slirp_configs(const StringList *fwd, int flags)
> while (fwd) {
> struct slirp_config_str *config;
>
> -config = g_malloc0(sizeo
.
Signed-off-by: Kevin Cernekee
Signed-off-by: Samuel Thibault
---
slirp/if.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/slirp/if.c b/slirp/if.c
index 6262d77495..590753c658 100644
--- a/slirp/if.c
+++ b/slirp/if.c
@@ -73,14 +73,16 @@ if_output(struct
ess)
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Samuel Thibault
---
net/slirp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/slirp.c b/net/slirp.c
index 01ed21c006..318a26e892 100644
--- a/net/slirp.c
+++ b
g Chromium OS VM tests[1] which rapidly create and
destroy ssh connections through hostfwd.
[0] https://pastebin.com/NNy6LreF
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=766323
Signed-off-by: Kevin Cernekee
Signed-off-by: Samuel Thibault
---
slirp/if
repository at:
http://people.debian.org/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 13146a83951e045c810c37c5c11c2a016ebc0663:
slirp: Add a special case for the NULL socket (2017-09-24 20:04:09 +0200)
Kevin Cernekee, on mer. 20 sept. 2017 13:42:05 -0700, wrote:
> NULL sockets are used for NDP, BOOTP, and other critical operations.
> If the topmost mbuf in a NULL session is blocked pending resolution,
> it may cause problems if it blocks other packets with a NULL socket.
> So do not add mbufs wit
Hello,
Kevin Cernekee, on mer. 20 sept. 2017 13:42:04 -0700, wrote:
> if_output() originally sent one mbuf per call and used the slirp->next_m
> variable to keep track of where it left off. But nowadays it tries to
> send all of the mbufs from the fastq, and one mbuf from each session on
> the ba
Philippe Mathieu-Daudé, on ven. 08 sept. 2017 13:19:56 -0300, wrote:
> Hi David,
>
> On 09/08/2017 12:53 PM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > e.g.
> > ./x86_64-softmmu/qemu-system-x86_64 -nographic -netdev
> > 'user,id=vnet,hostfwd=:555.0.0.0:0-:22'
Thomas Huth, on mer. 30 août 2017 09:50:45 +0200, wrote:
> On 26.08.2017 00:37, Samuel Thibault wrote:
> > The if_fastq and if_batchq contain not only packets, but queues of packets
> > for the same socket. When sofree frees a socket, it thus has to clear ifq_so
> > from all
Peter Maydell, on mar. 29 août 2017 16:31:03 +0100, wrote:
> On 29 August 2017 at 10:22, Samuel Thibault wrote:
> > Peter Maydell, on mar. 29 août 2017 10:20:31 +0100, wrote:
> >> On 28 August 2017 at 00:05, Samuel Thibault
> >> wrote:
> >> > warning: red
Peter Maydell, on mar. 29 août 2017 10:20:31 +0100, wrote:
> On 28 August 2017 at 00:05, Samuel Thibault
> wrote:
> > warning: redirection vers https://people.debian.org/~sthibault/qemu.git/
> > The following changes since commit 04d74e07b4542aad5aa4ad03951b38b767f5314a:
&g
Samuel Thibault, on lun. 28 août 2017 17:44:55 +0200, wrote:
> Eric Blake, on lun. 28 août 2017 10:43:48 -0500, wrote:
> > This is a pull request, but missed 2.10-rc4, which makes it really hard
> > to justify for inclusion in 2.10 proper. Is it okay that this doesn't
Hello,
Eric Blake, on lun. 28 août 2017 10:43:48 -0500, wrote:
> This is a pull request, but missed 2.10-rc4, which makes it really hard
> to justify for inclusion in 2.10 proper. Is it okay that this doesn't
> go in until 2.11?
Well, AIUI we have been living with the issue for years (decades?),
/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 04d74e07b4542aad5aa4ad03951b38b767f5314a:
slirp: fix clearing ifq_so from pending packets (2017-08-26 01:04:12 +0200)
slirp updates
The if_fastq and if_batchq contain not only packets, but queues of packets
for the same socket. When sofree frees a socket, it thus has to clear ifq_so
from all the packets from the queues, not only the first.
Signed-off-by: Samuel Thibault
Reviewed-by: Philippe Mathieu-Daudé
---
slirp
Samuel Thibault, on sam. 26 août 2017 01:05:04 +0200, wrote:
> So Wjjzhang and PJP, can you confirm that this fixes your uses?
PJP, can you forward it to Wjjzhang? I keep getting
: host cloudmx.qq.com[113.108.11.188] said: 550 Mail
content denied.
http://ascloud.qq.com/cgi-
Hello,
So Wjjzhang and PJP, can you confirm that this fixes your uses?
Samuel
Samuel Thibault, on sam. 26 août 2017 00:37:21 +0200, wrote:
> The if_fastq and if_batchq contain not only packets, but queues of packets
> for the same socket. When sofree frees a socket, it thus has to clear
The if_fastq and if_batchq contain not only packets, but queues of packets
for the same socket. When sofree frees a socket, it thus has to clear ifq_so
from all the packets from the queues, not only the first.
Signed-off-by: Samuel Thibault
Acked-by: Philippe Mathieu-Daudé
---
slirp/socket.c
Hello,
Thanks for the reproducer you sent me offline. Here is a fix which makes
a lot of sense and fixes the reproducer. Could you try it with your
whole testcase?
Could somebody also review the patch?
Samuel
commit 1a3a763509fad895c907e6978ea034a5c19ee370
Author: Samuel Thibault
Date: Fri
Hello,
P J P, on jeu. 03 août 2017 17:45:06 +0530, wrote:
> ==31922==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6141ff8c at pc 0x56485de28ea0 bp 0x7f00f44fc950 sp 0x7f00f44fc940
> READ of size 4 at 0x6141ff8c thread T2
> #0 0x56485de28e9f in if_start slirp/if.c:230
>
Eric Blake, on sam. 12 août 2017 06:41:30 -0500, wrote:
> Here's an idea: Instead of using struct ip6 { ... } QEMU_PACKED, use
>
> struct ip6 {
> ...
> };
> QEMU_BUG_ON(sizeof(struct ip6) != 32);
That's an interesting way indeed. I however wonder whether there may be
not-so-uncommon systems whe
Peter Maydell, on sam. 12 août 2017 12:18:16 +0100, wrote:
> On 12 August 2017 at 12:04, Samuel Thibault wrote:
> > Peter Maydell, on sam. 12 août 2017 11:53:20 +0100, wrote:
> >> The utility of the warning is that it means you get told
> >> about stuff that might b
Peter Maydell, on sam. 12 août 2017 11:53:20 +0100, wrote:
> The utility of the warning is that it means you get told
> about stuff that might break on other architectures.
Sure, I understand that. But here all fields are aligned on their size
inside the packed structure. So there can't be alignme
Hello,
Programmingkid, on jeu. 10 août 2017 16:44:19 -0400, wrote:
> While compiling I saw these error messages:
>
> slirp/ip6_icmp.c:79:32: warning: taking address of packed member 'ip_src' of
> class or
> structure 'ip6' may result in an unaligned pointer value
> [-Waddress-of-pack
/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 413d463f43fbc4dd3a601e80a5724aa384a265a0:
slirp: check len against dhcp options array end (2017-08-03 00:26:44 +0200)
slirp updates
Samuel Thibault, on jeu. 03 août 2017 00:26:07 +0200, wrote:
> From: Prasad J Pandit
>
> While parsing dhcp options string in 'dhcp_decode', if an options'
> length 'len' appeared towards the end of 'bp_vend' array, ensuing
> read could lead to
-off-by: Hervé Poussineau
Signed-off-by: Samuel Thibault
---
net/slirp.c | 134 ++--
1 file changed, 94 insertions(+), 40 deletions(-)
diff --git a/net/slirp.c b/net/slirp.c
index 9fbc949e81..01ed21c006 100644
--- a/net/slirp.c
+++ b/net
rted-by: Reno Robert
Signed-off-by: Prasad J Pandit
Signed-off-by: Samuel Thibault
---
slirp/bootp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/slirp/bootp.c b/slirp/bootp.c
index 5a4646c182..5dd1a415b5 100644
--- a/slirp/bootp.c
+++ b/slirp/bootp.c
@@ -123,6 +123,9 @@ static void dhcp_d
-off-by: Hervé Poussineau
Signed-off-by: Samuel Thibault
---
net/slirp.c | 134 ++--
1 file changed, 94 insertions(+), 40 deletions(-)
diff --git a/net/slirp.c b/net/slirp.c
index 9fbc949e81..01ed21c006 100644
--- a/net/slirp.c
+++ b/net
/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 2fe00b96b750f8c7a48dd3a98c5cb7370947264e:
slirp: check len against dhcp options array end (2017-08-03 00:24:31 +0200)
slirp updates
off-by: Prasad J Pandit
Signed-off-by: Samuel Thibault
---
slirp/bootp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/slirp/bootp.c b/slirp/bootp.c
index 5a4646c182..5dd1a415b5 100644
--- a/slirp/bootp.c
+++ b/slirp/bootp.c
@@ -123,6 +123,9 @@ static void dhcp_decode(const
Reno Robert, on lun. 17 juil. 2017 23:10:02 +0530, wrote:
> +if (p + len > p_end) {
>
> Shouldn't this be (p + len >= p_end) ?
No: if p_end-p is 1, len being 1 is fine.
Samuel
P J P, on lun. 17 juil. 2017 17:33:26 +0530, wrote:
> From: Prasad J Pandit
>
> While parsing dhcp options string in 'dhcp_decode', if an options'
> length 'len' appeared towards the end of 'bp_vend' array, ensuing
> read could lead to an OOB memory access issue. Add check to avoid it.
>
> Repor
HEllo,
Hervé Poussineau, on sam. 15 juil. 2017 18:43:50 +0200, wrote:
> With "-netdev user,id=net0,dns=1.2.3.4"
> error was:
> qemu-system-i386: -netdev user,id=net0,dns=1.2.3.4: Device 'user' could not
> be initialized
>
> Error is now:
> qemu-system-i386: -netdev user,id=net0,dns=1.2.3.4: DNS
From: Marc-André Lureau
I used the clang-tidy qemu-round check to generate the fix:
https://github.com/elmarco/clang-tools-extra
Signed-off-by: Marc-André Lureau
Signed-off-by: Samuel Thibault
---
slirp/ip6.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/slirp/ip6
/~sthibault/qemu.git tags/samuel-thibault
for you to fetch changes up to 75cb298d905030fca897ea1d80e409c7f7e3e5ea:
slirp: Handle error returns from sosendoob() (2017-07-15 14:28:25 +0200)
slirp updates
check this return
value currently, though.)
Signed-off-by: Peter Maydell
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Samuel Thibault
---
slirp/socket.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/slirp/socket.c b/slirp/socket.c
write failure in sosendoob() the same way we handle a write failure
for the normal data.
Signed-off-by: Peter Maydell
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Samuel Thibault
---
slirp/sbuf.c | 2 +-
slirp/socket.c | 23 +--
2 files changed, 18 insertions(+), 7
y: Dr. David Alan Gilbert
Signed-off-by: Samuel Thibault
---
slirp/misc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/slirp/misc.c b/slirp/misc.c
index 88e9d94197..260187b6b6 100644
--- a/slirp/misc.c
+++ b/slirp/misc.c
@@ -112,7 +112,9 @@ fork_exec(struct socket *so,
Dr. David Alan Gilbert, on ven. 14 juil. 2017 15:24:19 +0100, wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > sosendoob() can return a failure code, but all its callers ignore it.
> > This is OK in sbappend(), as the comment there states -- we will try
> > again later in sowrite(). A
Peter Maydell, on lun. 05 juin 2017 17:19:35 +0100, wrote:
> The code in sosendoob() assumes that slirp_send() always
> succeeds, but it might return an OS error code (for instance
> if the other end has disconnected). Catch these and return
> the caller either -1 on error or the number of urgent b
Peter Maydell, on lun. 05 juin 2017 17:19:36 +0100, wrote:
> diff --git a/slirp/socket.c b/slirp/socket.c
> index a17caa9..84cf13a 100644
> --- a/slirp/socket.c
> +++ b/slirp/socket.c
> @@ -404,7 +404,14 @@ sowrite(struct socket *so)
> DEBUG_ARG("so = %p", so);
>
> if (so->so_urgc) {
Peter Maydell, on dim. 09 juil. 2017 18:54:22 +0100, wrote:
> In a fork_exec() error path we try to closesocket(s) when s might
> be a negative number because the thing that failed was the
> qemu_socket() call. Add a guard so we don't do this.
>
> (Spotted by Coverity: CID 1005727 issue 1 of 2.)
Peter Maydell, on dim. 09 juil. 2017 22:21:01 +0100, wrote:
> Ping^2 ?
I'm sorry I'm still too busy ATM, it's still far in my mbox.
Samuel
Marc-André Lureau, on jeu. 22 juin 2017 14:41:45 +0200, wrote:
> I used the clang-tidy qemu-round check to generate the fix:
> https://github.com/elmarco/clang-tools-extra
>
> Signed-off-by: Marc-André Lureau
Applied to my tree, thanks!
> ---
> slirp/ip6.h | 6 +++---
> 1 file changed, 3 inser
The following changes since commit 9964e96dccf7f7c936ee854a795415d19b60:
Merge remote-tracking branch 'jasowang/tags/net-pull-request' into staging
(2017-05-23 15:01:31 +0100)
are available in the git repository at:
http://people.debian.org/~sthibault/qemu.git tags/samuel-thi
From: Sjors Gielen
When forwarding TCP packets, the internal tcpiphdr struct length was wrongly
used inside the IP header. This commit changes the behaviour to what is used
by tcp_output.c, using the correct full IP header + payload length.
Signed-off-by: Sjors Gielen
Signed-off-by: Samuel
From: Tao Wu
This bug was introduced by https://github.com/qemu/qemu/commit/98c6305
Signed-off-by: Tao Wu
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-bu: Samuel Thibault
---
slirp/tcp_input.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/slirp/tcp_input.c b
/elmarco/src/qemu/net/slirp.c:506
#5 0x556f11f8dd83 in hmp_hostfwd_add /home/elmarco/src/qemu/net/slirp.c:535
There might be a better way to fix this, but calling slirp tcp_close()
doesn't work.
Signed-off-by: Marc-André Lureau
Signed-off-by: Samuel Thibault
---
slirp/socket.c | 3 +++
1
Sjors Gielen, on mer. 24 mai 2017 17:51:12 +, wrote:
> When forwarding TCP packets, the internal tcpiphdr struct length was wrongly
> used inside the IP header. This commit changes the behaviour to what is used
> by tcp_output.c, using the correct full IP header + payload length.
Indeed, appli
t have to free it then.
>
> Signed-off-by: Laurent Vivier
Acked-by: Samuel Thibault
> ---
> hw/net/vmxnet3.c| 8 ++--
> hw/s390x/s390-skeys.c | 9 +++--
> hw/s390x/s390-virtio-ccw.c | 8 ++--
> include/migration/vmstate.h | 8 -
Thomas Huth, on mar. 23 mai 2017 09:25:30 +0200, wrote:
> > /tmp/qemu-test/src/slirp/tcp_input.c: In function ‘tcp_input’:
> > /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_p’ may be
> > used uninitialized in this function
>
> I've never seen these warnings in tcp_input.c before
Hello,
Laurent Vivier, on mar. 09 mai 2017 21:31:11 +0200, wrote:
> This patch implements the SOCKS5 client part for "-net user" backend.
Thanks for the changes!
It seems from the bot result that windows doesn't define in_port_t.
Could you post a revised patch which uses sizeof(uint16_t) instead
Hello,
Laurent Vivier, on mar. 09 mai 2017 09:21:09 +0200, wrote:
> Le 08/05/2017 à 22:09, Samuel Thibault a écrit :
> > Laurent Vivier, on sam. 06 mai 2017 15:19:44 +0200, wrote:
> >>> Laurent Vivier, on sam. 06 mai 2017 00:48:33 +0200, wrote:
> >> T
Hello,
Laurent Vivier, on sam. 06 mai 2017 15:19:44 +0200, wrote:
> > Laurent Vivier, on sam. 06 mai 2017 00:48:33 +0200, wrote:
> >> @@ -617,6 +622,10 @@ void slirp_pollfds_poll(GArray *pollfds, int
> >> select_error)
> >> * Check sockets for reading
> >> */
>
Hello,
lepton, on lun. 08 mai 2017 12:08:55 -0700, wrote:
> 1. For some reason, caller didn't setup anything in tcpiphdr, so there is
> random data inside it.
> 2. For some reason, caller setup correct src/dst address in tcpiphdr but
> don't
> zero ix_h1
> If you still think this doesn't look
FONNEMANN Mark, on sam. 06 mai 2017 04:18:52 +, wrote:
> >That's so weird there's no packet log. Does your guest perhaps have the
> >strace tool? Or perhaps you >can manage to copy it over from another VM,
> >since it only depends on libc.
>
> See attached file.
Ok, so for some reason it do
FONNEMANN Mark, on sam. 06 mai 2017 01:06:31 +, wrote:
> root@qemu:~# /initrd/bin/nslookup www.google.com 10.0.2.3
> Server:10.0.2.3
> Address 1: 10.0.2.3
>
> nslookup: can't resolve 'www.google.com'
That's so weird there's no pa
FONNEMANN Mark, on sam. 06 mai 2017 00:33:40 +, wrote:
> >The attached patch should be dumping the same kind of information.
>
> Nslookup does not produce any output in curses or in logfile (-D logfile.txt).
Uh. So qemu can't be the culprit since it doesn't receive anything :)
> root@qemu:~
Applied to my tree, thanks!
Hello,
Laurent Vivier, on sam. 06 mai 2017 00:48:33 +0200, wrote:
> @@ -617,6 +622,10 @@ void slirp_pollfds_poll(GArray *pollfds, int
> select_error)
> * Check sockets for reading
> */
> else if (revents & (G_IO_IN | G_IO_HUP | G_IO_ERR)) {
> +
FONNEMANN Mark, on ven. 05 mai 2017 22:38:20 +, wrote:
> >Could you run tcpdump inside the guest so we are sure what the nslookup call
> >emits?
>
> Is there another way to determine this info? My guest OS is an embedded
> system with BusyBox 1.25 and not much else.
The attached patch shoul
Hello,
lepton, on mer. 03 mai 2017 11:35:05 -0700, wrote:
> It sounds like a bug that caller set up a
> right src and dst address and without set right ih_x1.
I wouldn't bet on that. ih_x1 is only a filler, the caller can be using
the structure only as a C structure, and it's only here just befo
FONNEMANN Mark, on dim. 30 avril 2017 12:42:41 +, wrote:
> root@qemu:~# nslookup www.google.com
>*** Unknown host
>
>nslookup: www.google.com: Unknown host
Could you run tcpdump inside the guest so we are sure what the nslookup
call emits?
Samuel
FONNEMANN Mark, on sam. 29 avril 2017 23:15:08 +, wrote:
> [mfonnemann@desktopPC qemu]$ /usr/local/bin/qemu-system-i386 -display curses
> -readconfig NG.cfg --enable-kvm
Could you show us your NG.cfg, your guest /sbin/ifconfig and /sbin/route
output and /etc/resolv.conf content for that host?
FONNEMANN Mark, on sam. 29 avril 2017 20:06:09 +, wrote:
> [mfonnemann@localhost qemu]$ /usr/local/bin/qemu-system-i386 -display curses
> -readconfig qemu.cfg -D logfile
Ah, you are using curses... I've been putting logs onto stderr for
simplicity, not the proper qemu logs. Here is a fixed pa
FONNEMANN Mark, on sam. 29 avril 2017 18:25:26 +, wrote:
> 0 packets received by filter
Ok, so nothing going out from qemu. Could you try to apply the attached
patch to qemu-2.9 and see what it makes qemu print when you resolve a
domain from the guest?
Samuel
--- a/slirp/socket.c
+++ b/slirp/
FONNEMANN Mark, on sam. 29 avril 2017 15:32:35 +, wrote:
> >When running with a Linux host (since that's what I'm most familiar with),
> >what do you have in /etc/resolv.conf?
>
> [mfonnemann@localhost ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 4.2.2.1
> nameserver
From: "Dr. David Alan Gilbert"
Working up the stack, this replaces the slirp_socket_load/save
with VMState definitions.
A place holder for IPv6 support is added as a comment; it needs
testing once the rest of the IPv6 code is there.
Signed-off-by: Dr. David Alan Gilbert
Signed-off-
From: "Dr. David Alan Gilbert"
This converts the remaining components, except for the top level
loop, to VMState.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Juan Quintela
Signed-off-by: Samuel Thibault
---
slirp/slirp.c | 48 +++---
From: "Dr. David Alan Gilbert"
Convert the migration of the struct tcpcb to use a VMStateDescription,
the rest of it will come later.
Mostly mechanical, except for conversion of some 'char' to uint8_t
to ensure portability.
Signed-off-by: Dr. David Alan Gilbert
Reviewed
ned-off-by: Samuel Thibault
---
slirp/sbuf.h | 4 +-
slirp/slirp.c | 116 ++
2 files changed, 78 insertions(+), 42 deletions(-)
diff --git a/slirp/sbuf.h b/slirp/sbuf.h
index efcec39a6b..a722ecb629 100644
--- a/slirp/sbuf.h
+++ b/sl
la
Signed-off-by: Samuel Thibault
---
slirp/socket.h | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/slirp/socket.h b/slirp/socket.h
index 8feed2aea4..c1be77eaf3 100644
--- a/slirp/socket.h
+++ b/slirp/socket.h
@@ -15,6 +15,12 @@
* Our socket structure
*
801 - 900 of 1571 matches
Mail list logo
