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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).