From: Chris Clayton <chris2553@googlemail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org, gpiez@web.de
Subject: Re: Possible networking regression in 3.6.0
Date: Fri, 28 Sep 2012 15:28:24 +0100 [thread overview]
Message-ID: <5065B408.1020604@googlemail.com> (raw)
In-Reply-To: <1348831592.5093.2251.camel@edumazet-glaptop>
On 09/28/12 12:26, Eric Dumazet wrote:
> On Fri, 2012-09-28 at 10:22 +0100, Chris Clayton wrote:
>
>> No, the WinXP guest is configured with a fixed IP address
>> (192.168.200.1). Subnet mask is 255.255.255.0, and default gateway is
>> 192.168.200.254. DNS is 192.168.0.1.
>>
>
> I have no problem with such a setup, with a linux guest.
>
> Could you send again a tcpdump, but including link-level header ?
> (option -e)
>
> Ideally, you could send two traces, one taken on tap0, and another taken
> on eth0.
>
Two traces
Trace 1 - tap0 (192.168.200.254) whilst pinging router (192.168.0.1)from
KVM guest (192.168.200.1):
15:03:14.953599 52:54:0c:3b:17:38 > Broadcast, ethertype ARP (0x0806),
length 42: Request who-has 192.168.200.254 tell 192.168.200.1, length 28
15:03:14.953617 9e:c3:0c:c8:65:8d > 52:54:0c:3b:17:38, ethertype ARP
(0x0806), length 42: Reply 192.168.200.254 is-at 9e:c3:0c:c8:65:8d,
length 28
15:03:14.953725 52:54:0c:3b:17:38 > 9e:c3:0c:c8:65:8d, ethertype IPv4
(0x0800), length 74: 192.168.200.1 > 192.168.0.1: ICMP echo request, id
512, seq 5376, length 40
15:03:20.427278 52:54:0c:3b:17:38 > 9e:c3:0c:c8:65:8d, ethertype IPv4
(0x0800), length 74: 192.168.200.1 > 192.168.0.1: ICMP echo request, id
512, seq 5632, length 40
15:03:25.942215 52:54:0c:3b:17:38 > 9e:c3:0c:c8:65:8d, ethertype IPv4
(0x0800), length 74: 192.168.200.1 > 192.168.0.1: ICMP echo request, id
512, seq 5888, length 40
15:03:31.455578 52:54:0c:3b:17:38 > 9e:c3:0c:c8:65:8d, ethertype IPv4
(0x0800), length 74: 192.168.200.1 > 192.168.0.1: ICMP echo request, id
512, seq 6144, length 40
Trace 2 - eth0 (192.168.0.40) whilst pinging router (192.168.0.1)from
KVM guest (192.168.200.1):
15:04:06.427863 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: 192.168.0.40 > 192.168.0.1: ICMP echo request, id
512, seq 6400, length 40
15:04:06.432100 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: 192.168.0.1 > 192.168.0.40: ICMP echo reply, id
512, seq 6400, length 40
15:04:11.430877 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype ARP
(0x0806), length 60: Request who-has 192.168.0.40 tell 192.168.0.1,
length 46
15:04:11.430898 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype ARP
(0x0806), length 42: Reply 192.168.0.40 is-at 5c:9a:d8:5c:63:31, length 28
15:04:11.567319 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: 192.168.0.40 > 192.168.0.1: ICMP echo request, id
512, seq 6656, length 40
15:04:11.571534 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: 192.168.0.1 > 192.168.0.40: ICMP echo reply, id
512, seq 6656, length 40
15:04:16.577137 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype ARP
(0x0806), length 42: Request who-has 192.168.0.1 tell 192.168.0.40,
length 28
15:04:16.580373 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype ARP
(0x0806), length 60: Reply 192.168.0.1 is-at 00:1f:33:80:09:44, length 46
15:04:17.083328 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: 192.168.0.40 > 192.168.0.1: ICMP echo request, id
512, seq 6912, length 40
15:04:17.086854 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: 192.168.0.1 > 192.168.0.40: ICMP echo reply, id
512, seq 6912, length 40
15:04:22.585766 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: 192.168.0.40 > 192.168.0.1: ICMP echo request, id
512, seq 7168, length 40
15:04:22.589989 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: 192.168.0.1 > 192.168.0.40: ICMP echo reply, id
512, seq 7168, length 40
15:04:32.240422 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 446: 192.168.0.112.2704 > 239.255.255.250.1900: UDP,
length 404
15:04:32.241404 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 455: 192.168.0.112.2704 > 239.255.255.250.1900: UDP,
length 413
15:04:32.242915 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 494: 192.168.0.112.2704 > 239.255.255.250.1900: UDP,
length 452
15:04:32.243986 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 490: 192.168.0.112.1434 > 239.255.255.250.1900: UDP,
length 448
15:04:32.245476 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: 192.168.0.112.2901 > 239.255.255.250.1900: UDP,
length 444
15:04:32.246545 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: 192.168.0.112.3828 > 239.255.255.250.1900: UDP,
length 444
15:04:32.342459 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 446: 192.168.0.112.4445 > 239.255.255.250.1900: UDP,
length 404
15:04:32.343506 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 455: 192.168.0.112.4445 > 239.255.255.250.1900: UDP,
length 413
15:04:32.345017 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 494: 192.168.0.112.4445 > 239.255.255.250.1900: UDP,
length 452
15:04:32.346087 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 490: 192.168.0.112.2735 > 239.255.255.250.1900: UDP,
length 448
15:04:32.348314 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: 192.168.0.112.4940 > 239.255.255.250.1900: UDP,
length 444
15:04:32.349362 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: 192.168.0.112.1029 > 239.255.255.250.1900: UDP,
length 444
The second trace seems to contain some upnp-related traffic involving my
satellite TV box. If it would help, I can turn that off when my wife
isn't watching TV, and run the traces again.
Chris
>
>
>
>
next prev parent reply other threads:[~2012-09-28 14:28 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 15:44 Possible networking regression in 3.6.0 Chris Clayton
2012-09-18 14:21 ` Chris Clayton
2012-09-18 14:31 ` Chris Clayton
2012-09-18 14:40 ` Eric Dumazet
2012-09-18 15:51 ` Chris Clayton
2012-09-19 15:26 ` Chris Clayton
2012-09-22 6:26 ` Chris Clayton
2012-09-27 11:50 ` Chris Clayton
2012-09-27 12:14 ` Eric Dumazet
2012-09-27 18:05 ` Chris Clayton
2012-09-27 21:03 ` Eric Dumazet
2012-09-27 21:17 ` Eric Dumazet
2012-09-28 6:53 ` David Miller
2012-09-28 9:14 ` Chris Clayton
2012-09-28 9:22 ` Chris Clayton
2012-09-28 11:26 ` Eric Dumazet
2012-09-28 14:28 ` Chris Clayton [this message]
2012-09-30 15:26 ` Chris Clayton
2012-09-30 19:45 ` Eric Dumazet
2012-10-01 8:36 ` Chris Clayton
2012-10-01 9:15 ` Eric Dumazet
2012-10-01 15:13 ` Chris Clayton
2012-10-01 15:31 ` Eric Dumazet
2012-10-01 16:19 ` Chris Clayton
2012-10-01 16:37 ` Eric Dumazet
2012-10-01 18:28 ` Chris Clayton
2012-10-01 18:34 ` Captain Obvious
2012-10-01 19:21 ` Eric Dumazet
2012-10-01 19:55 ` Chris Clayton
2012-10-01 19:22 ` Chris Clayton
2012-10-01 19:34 ` Dave Jones
2012-10-01 20:01 ` David Miller
2012-10-01 20:04 ` Eric Dumazet
2012-10-02 15:27 ` Edivaldo de Araújo Pereira
2012-10-02 15:35 ` Eric Dumazet
2012-10-02 15:48 ` Eric Dumazet
2012-10-02 15:57 ` Dave Jones
2012-10-02 16:06 ` Eric Dumazet
2012-10-02 18:25 ` David Miller
2012-10-02 21:14 ` Alexander Duyck
2012-10-02 21:35 ` Eric Dumazet
2012-10-02 23:24 ` Julian Anastasov
2012-10-03 3:10 ` David Miller
2012-10-03 15:01 ` Chris Clayton
2012-10-03 20:57 ` Julian Anastasov
2012-10-03 7:28 ` [PATCH] udp: increment UDP_MIB_NOPORTS in mcast receive Eric Dumazet
2012-10-03 12:45 ` David Stevens
2012-10-03 13:15 ` Eric Dumazet
2012-10-03 14:09 ` David Stevens
2012-10-03 15:29 ` Eric Dumazet
2012-10-03 17:31 ` David Stevens
2012-10-03 19:30 ` David Miller
2012-10-03 17:39 ` Rick Jones
2012-10-03 2:55 ` Possible networking regression in 3.6.0 David Miller
2012-10-04 11:25 ` [PATCH] ipv4: add a fib_type to fib_info Eric Dumazet
2012-10-04 13:08 ` Chris Clayton
2012-10-04 13:32 ` Eric Dumazet
2012-10-04 18:14 ` David Miller
2012-09-18 14:44 ` Possible networking regression in 3.6.0 Chris Clayton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5065B408.1020604@googlemail.com \
--to=chris2553@googlemail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=gpiez@web.de \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.