Bug 54021 (korn2012) - No internet with kernel 3.7 or 3.8 with LAN
Summary: No internet with kernel 3.7 or 3.8 with LAN
Status: CLOSED CODE_FIX
Alias: korn2012
Product: Networking
Classification: Unclassified
Component: IPV4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-17 13:37 UTC by korn2012
Modified: 2017-04-12 09:35 UTC (History)
12 users (show)

See Also:
Kernel Version: since 3.7
Tree: Mainline
Regression: No


Attachments
tcpdump -n -i eth0 when connection is dropped. (175.96 KB, text/plain)
2013-03-07 19:05 UTC, Otamay
Details
tcpdump -n -i eth0 doing ping -c 10 13.xxx.xxx.23 (729 bytes, text/plain)
2013-03-07 19:06 UTC, Otamay
Details
patch to dump dma mappings on error (647 bytes, patch)
2013-07-05 15:22 UTC, Neil Horman
Details | Diff
new debug patch to check hardware interrupt mask (1.12 KB, patch)
2013-07-12 15:28 UTC, Neil Horman
Details | Diff
syslog after ptaching using attachment 106879 (114.52 KB, text/plain)
2013-07-12 16:43 UTC, Vincent Alquier
Details
patch to ensure that __netdev_alloc_skb returns DMA safe memory (1.40 KB, patch)
2013-07-26 14:10 UTC, Neil Horman
Details | Diff
atl1c_rx_overflow_debug.patch (1.04 KB, patch)
2016-05-30 08:10 UTC, Feng Tang
Details | Diff

Description korn2012 2013-02-17 13:37:57 UTC
Hello since kernel update 3.7 or 3.8 I have no internet connection with LAN, wlan is working very well, with lan my internet connection is working for 5 minutes, then internet is not working anymore. I have to unplug the cable and the i have to plug it again - so it will work 5 minutes.....

I have a netbook (acer aspire one d255)


With kernel 3.5x everything is working fine.

Problem is reported here (German)  

http://forum.ubuntuusers.de/topic/internet-verbindung-bricht-ab/

If you need more information, feel free to ask


kind regards
Comment 1 korn2012 2013-02-17 19:07:37 UTC
packman@packman-AOD255:~$ sudo lshw -class network
[sudo] password for packman: 
  *-network               
       Beschreibung: Ethernet interface
       Produkt: AR8152 v1.1 Fast Ethernet
       Hersteller: Atheros Communications Inc.
       Physische ID: 0
       Bus-Informationen: pci@0000:01:00.0
       Logischer Name: eth0
       Version: c1
       Seriennummer: 88:ae:1d:9d:24:8f
       Größe: 100Mbit/s
       Kapazität: 100Mbit/s
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: pm msi pciexpress vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       Konfiguration: autonegotiation=on broadcast=yes driver=atl1c driverversion=1.0.1.0-NAPI duplex=full ip=192.168.2.103 latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
       Ressourcen: irq:45 memory:57000000-5703ffff ioport:5000(Größe=128)
Comment 2 QCA Ethernet team 2013-02-19 15:36:39 UTC
can you please paste dmesg log when issue arise ?
Comment 3 QCA Ethernet team 2013-02-19 15:45:46 UTC
I found your log at ubuntun forum, it seems that PHY/cable link isn't stable.
can you please try:

1. change a cable
2. change a swtich (or router) port with which the NIC connect.
3. change a switch (or router)

I don't know if the driver for 3.5 is same as for 3.7/3.8, do you have source code on hand ?

thanks
Xiong
Comment 4 korn2012 2013-02-19 16:03:18 UTC
1. changed it but with no success
2. I also did it

With kernel 3.5 everything is working fine. Where to get the source code? 

thx

kind regards
Comment 5 QCA Ethernet team 2013-02-19 16:05:01 UTC
please tell me your detailed kernel version for 3.5 3.7/3.8, thanks
Comment 6 korn2012 2013-02-19 16:27:53 UTC
3.5.0.22/24 ubuntu (with working lan)
3.8 rc or final or 3.7.8 or 3.7.6 (fedora) (not working lan)

x86
Comment 7 QCA Ethernet team 2013-02-19 18:02:36 UTC
can you please paste the log for 
lspci -d 1969:2060
Comment 8 QCA Ethernet team 2013-02-19 18:03:21 UTC
sorry, type this command, please
lspci -d 1969:2060 -xxx
Comment 9 korn2012 2013-02-19 19:58:48 UTC
with kernel 3.8 final

packman@packman-AOD255:~$ lspci -d 1969:2060 -xxx
01:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v1.1 Fast Ethernet (rev c1)
00: 69 19 60 20 07 00 10 00 c1 00 00 02 10 00 00 00
10: 04 00 00 57 00 00 00 00 01 50 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 49 03
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00

packman@packman-AOD255:~$
Comment 10 korn2012 2013-02-19 20:02:43 UTC
with kernel 3.5.0.24 (latest ubuntu)

packman@packman-AOD255:~$ lspci -d 1969:2060 -xxx
01:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v1.1 Fast Ethernet (rev c1)
00: 69 19 60 20 07 00 10 00 c1 00 00 02 10 00 00 00
10: 04 00 00 57 00 00 00 00 01 50 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 49 03
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00

packman@packman-AOD255:~$
Comment 11 Otamay 2013-02-27 19:38:48 UTC
I have the same problem, with a similar ethernet controller, an Atheros AR8152 v2.0 (same module, atl1c)

rchavez-iron rchavez # lspci -d 1969:2062
02:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v2.0 Fast Ethernet (rev c1)

Kernel problems:

3.6.11 does works
3.7.0  does not work
3.7.2  does not work
3.7.3  does not work
3.8.0  does not work

I've reverted all linux/drivers/net/ethernet/atheros/atl1c/* files from 3.7.0 kernel to 3.6.11 and didn't work. I think this could be related to the networking regressions from 3.7 .

Related problem:
http://forums.gentoo.org/viewtopic-t-949168-highlight-.html
Comment 12 Eric Dumazet 2013-02-28 22:07:07 UTC
If you disable TSO, does it change anything ?

ethtool -K eth0 tso off
Comment 13 Otamay 2013-02-28 22:59:51 UTC
It didn't work =/.

rchavez-iron rchavez # ethtool -K eth0 tso off
rchavez-iron rchavez # ethtool -k eth0
Features for eth0:
rx-checksumming: off [fixed]
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
Comment 14 Otamay 2013-03-05 18:51:58 UTC
A git bisect shows this information:

rchavez-iron linux # git bisect good
69b08f62e17439ee3d436faf0b9a7ca6fffb78db is the first bad commit
commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 26 06:46:57 2012 +0000

    net: use bigger pages in __netdev_alloc_frag

    We currently use percpu order-0 pages in __netdev_alloc_frag
    to deliver fragments used by __netdev_alloc_skb()

    Depending on NIC driver and arch being 32 or 64 bit, it allows a page to
    be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096

    Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows :

    - Better filling of space (the ending hole overhead is less an issue)

    - Less calls to page allocator or accesses to page->_count

    - Could allow struct skb_shared_info futures changes without major
      performance impact.

    This patch implements a transparent fallback to smaller
    pages in case of memory pressure.

    It also uses a standard "struct page_frag" instead of a custom one.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Duyck <alexander.h.duyck@intel.com>
    Cc: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

:040000 040000 a2c23214cb3bbcd9482a3cb3de4a402885062a24 3073def37d7f7eb1f6769d46
f8a9d0ff7b49963b M      net

log:
rchavez-iron linux # git bisect log
git bisect start
# bad: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect bad 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# good: [b2824f4e0990716407b0c0e7acee75bb6353febf] Linux 3.6.11
git bisect good b2824f4e0990716407b0c0e7acee75bb6353febf
# good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
# bad: [d66e6737d454553e1e62109d8298ede5351178a4] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect bad d66e6737d454553e1e62109d8298ede5351178a4
# good: [6d55d5968a8622f3ea20ec40737aea1cfba6438c] Merge branch 'next/soc' into HEAD
git bisect good 6d55d5968a8622f3ea20ec40737aea1cfba6438c
# bad: [aecdc33e111b2c447b622e287c6003726daa1426] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad aecdc33e111b2c447b622e287c6003726daa1426
# bad: [a248afdc1b5916c2bfd007233112333d85aa28f6] Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
git bisect bad a248afdc1b5916c2bfd007233112333d85aa28f6
# good: [b6069a95706ca5738be3f5d90fd286cbd13ac695] filter: add MOD operation
git bisect good b6069a95706ca5738be3f5d90fd286cbd13ac695
# good: [4c0ba9ac4bf5f20ada774f5d181d03044e0147e7] NFC: Fix typo negociating -> negotiating
git bisect good 4c0ba9ac4bf5f20ada774f5d181d03044e0147e7
# good: [016818d076871c4ee34db1e8d74dc17ac1de626a] tcp: TCP Fast Open Server - take SYNACK RTT after completing 3WHS
git bisect good 016818d076871c4ee34db1e8d74dc17ac1de626a
# good: [e2bcabec6ea5ba30dd2097dc1566e9957d14117c] net: remove sk_init() helper
git bisect good e2bcabec6ea5ba30dd2097dc1566e9957d14117c
# good: [97ea6d0f3eb019891038cd2dfddb749d6bf219be] Merge tag 'nfc-next-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0
git bisect good 97ea6d0f3eb019891038cd2dfddb749d6bf219be
# bad: [6c636503260d1a5598f44f940f284cf679dc38f9] smsc75xx: add wol magic packet support
git bisect bad 6c636503260d1a5598f44f940f284cf679dc38f9
# bad: [cf2acec2e90beffc20c8a63322f0a978ea4941df] smsc95xx: sleep before read for lengthy operations
git bisect bad cf2acec2e90beffc20c8a63322f0a978ea4941df
# bad: [69b08f62e17439ee3d436faf0b9a7ca6fffb78db] net: use bigger pages in __netdev_alloc_frag
git bisect bad 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
# good: [5dff747b7038d10f9c174a1245263fd1c36a644d] tcp: Remove unused parameter from tcp_v4_save_options
git bisect good 5dff747b7038d10f9c174a1245263fd1c36a644d
Comment 15 Eric Dumazet 2013-03-05 18:57:28 UTC
Thanks for the bisection.

You need to report to atl1c author/maintainer this bug, as the driver needs a fix.
Comment 16 Eric Dumazet 2013-03-05 22:41:56 UTC
By the way it might be already solved in current tree. Please try 3.9-rc1
Comment 17 Otamay 2013-03-06 00:40:11 UTC
Kernel 3.9-rc1 tested and the problem still exists.

However, I've noticed some more. When I start without my wireless card (Atheros AR9285 rev01, 168c:002b ) by blacklisting, ethernet works without problems.

When I do `modprobe ath9k`, NetworkManager connects via wireless, and ethernet works for a minute, then drops connection. Wireless is fine.

If I do `modprobe -r ath9k` and reconnect ethernet cable, NetworkManager do it's job and ethernet works as usual.

My routing table and ifconfig, with both kernels, are the same:

rchavez-iron rchavez # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dsldevice.lan   0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        13.xxx.xxx.254  255.0.0.0       UG    0      0        0 eth0
13.0.0.0        13.xxx.xxx.254  255.0.0.0       UG    0      0        0 eth0
13.xxx.xxx.0    *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0

rchavez-iron rchavez # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 13.xxx.xxx.60  netmask 255.255.255.0  broadcast 13.138.119.255
        ether dc:0e:a1:7d:34:b5  txqueuelen 1000  (Ethernet)
        RX packets 8258  bytes 5876498 (5.6 MiB)
        RX errors 0  dropped 461  overruns 437  frame 437
        TX packets 9430  bytes 3099723 (2.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 20  bytes 6548 (6.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 6548 (6.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.174  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 9c:b7:0d:32:4e:66  txqueuelen 1000  (Ethernet)
        RX packets 1137  bytes 515943 (503.8 KiB)
        RX errors 0  dropped 85  overruns 0  frame 0
        TX packets 659  bytes 170183 (166.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Perhaps it's a routing problem non existing before?

Thank you very much for your attention.
Comment 18 QCA Ethernet team 2013-03-07 00:50:37 UTC
hi Eric Dumazet,
   I have a quesiton about netdev_alloc_skb, doesn't it allocate contiguous physical memory any more ?
   I found some drivers like tg3 & r8169 don't use this function directly
DMA used by the NIC, but allocate DMA memory by kmalloc or netdev_alloc_frag

   Should I revise the code in that way ?  

thanks !
Comment 19 Eric Dumazet 2013-03-07 02:11:39 UTC
It allocates contiguous memory as before.

Only difference you might hit is that a skb->data might now cross a 4K boundary.

Maybe your NIC doesnt allow that ?
Comment 20 QCA Ethernet team 2013-03-07 02:14:04 UTC
not sure, I need doulbe check with the hardware designer.
thanks for your info !
Comment 21 QCA Ethernet team 2013-03-07 03:06:47 UTC
it supports that case.
Comment 22 Eric Dumazet 2013-03-07 05:00:10 UTC
What strikes me is : it works for a while, then it doesnt work.

It looks like a configuration problem (comment #17 is really confusing)

Xiong, can you reproduce this in your lab ?
Comment 23 Otamay 2013-03-07 05:44:01 UTC
I'll try to explain better.

I'm connected via ethernet to a local network, and via wireless to internet (route command output shows the configuration).

When I start browsing through local network webpages, the connection suddendly drops and never recovers. Browsing internet webpages works fine.

If I disconnect ethernet cable and reconnect it, the local network is reestablished, but only for a minute or two, and the same behaviour is seen again.

But if I don't use the wireless connection (by blacklisting wireless module), local network connection is never lost, working as expected.

This could be seen as a routing problem, but the problem is only present in kernels from 3.7 to 3.9-rc1 (most recent version). Using Linux 3.6.11 does not seems to present the anomaly.

I'll do other tests tomorrow when I have an ethernet connection again, at work.

Thank you for your help!
Comment 24 Eric Dumazet 2013-03-07 06:05:58 UTC
It could be a memory issue.

Maybe your wireless adapter leaks memory after a while.

Do you have CONFIG_COMPACTION=y in your .config ?
Comment 25 Anonymous Emailer 2013-03-07 15:19:58 UTC
Reply-To: xiong@qca.qualcomm.com

> 
> Xiong, can you reproduce this in your lab ?
> 
> --

We have no same platform at Lab, but if we use merely NIC, everything is ok :(
Comment 26 Otamay 2013-03-07 16:00:38 UTC
Yes, I do have CONFIG_COMPACTION=y (due to TRANSPARENT_HUGEPAGE=y). However, even disabling both options the problem persists.
Comment 27 Eric Dumazet 2013-03-07 16:24:58 UTC
Nothing in your kernel log ? (dmesg)
Comment 28 Eric Dumazet 2013-03-07 16:26:05 UTC
When problem happens, take a snapshot of 

cat /proc/buddyinfo
ifconfig -a
Comment 29 Otamay 2013-03-07 16:39:55 UTC
There is no additional output in dmesg after problem occurs.

rchavez-iron rchavez # cat /proc/buddyinfo
Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3
Node 0, zone    DMA32    710    111    295    131      6      3      3      4      2      3    184 

rchavez-iron rchavez # ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 13.xxx.xxx.60  netmask 255.255.255.0  broadcast 13.138.119.255
        ether dc:0e:a1:7d:34:b5  txqueuelen 1000  (Ethernet)
        RX packets 634  bytes 681620 (665.6 KiB)
        RX errors 0  dropped 518  overruns 514  frame 514
        TX packets 618  bytes 145274 (141.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 20  bytes 6548 (6.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 6548 (6.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.191  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 9c:b7:0d:32:4e:66  txqueuelen 1000  (Ethernet)
        RX packets 2312  bytes 1053816 (1.0 MiB)
        RX errors 0  dropped 116  overruns 0  frame 0
        TX packets 1169  bytes 261470 (255.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Comment 30 korn2012 2013-03-07 18:17:00 UTC
I have installed ubuntu 12.10 64 bit

With the latest ubuntu kernel (3.5.0.25) i'll get no connection after reboot, I have to plug the cable again (then everything is working fine; for hours), with kernel 3.8.2 final (x64) conncection will lost after a couple of minutes
Didn't have this problem with kernel 3.5x on ubuntu x86.

With kernel 3.9rc1 x64 I have no connection after reboot, after plugging cable again everything is working fine, internet work for hours. 

So imo kernel 3.9 is a improovment, but in order to have a connection the first time, I have to plug the lan cable again.
Comment 31 QCA Ethernet team 2013-03-07 18:21:24 UTC
(In reply to comment #30)
> I have installed ubuntu 12.10 64 bit
> 
> With the latest ubuntu kernel (3.5.0.25) i'll get no connection after reboot,
> I
> have to plug the cable again (then everything is working fine; for hours),
> with
> kernel 3.8.2 final (x64) conncection will lost after a couple of minutes
> Didn't have this problem with kernel 3.5x on ubuntu x86.
> 
> With kernel 3.9rc1 x64 I have no connection after reboot, after plugging
> cable
> again everything is working fine, internet work for hours. 
> 
> So imo kernel 3.9 is a improovment, but in order to have a connection the
> first
> time, I have to plug the lan cable again.

korn, your senario is different with Otamay, Otamay's log doesn't show any PHY link event. the NIC itself looks normal.
Comment 32 Eric Dumazet 2013-03-07 18:22:43 UTC
The "carrier 1" indication might be a wrong error path in the driver, letting interrupts disabled or something.

What gives "tcpdump -n -i eth0" ?
(try a ping to the gateway in another term-

Are some packets still transmitted ?
Comment 33 korn2012 2013-03-07 18:26:35 UTC
packman@packman-AOD255:~$ tcpdump -n -i eth0
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)
packman@packman-AOD255:~$ sudo tcpdump -n -i eth0
[sudo] password for packman: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:25:24.152064 IP 192.168.2.105.37800 > 194.25.95.91.443: Flags [.], ack 3649373091, win 243, options [nop,nop,TS val 204288 ecr 707784256], length 0
19:25:24.152161 IP 192.168.2.105.33787 > 194.25.94.203.443: Flags [.], ack 3063472207, win 198, options [nop,nop,TS val 204288 ecr 4268339333], length 0
19:25:24.152197 IP 192.168.2.105.33789 > 194.25.94.203.443: Flags [.], ack 2205615230, win 198, options [nop,nop,TS val 204288 ecr 4268339333], length 0
19:25:24.152227 IP 192.168.2.105.33791 > 194.25.94.203.443: Flags [.], ack 1324631540, win 153, options [nop,nop,TS val 204288 ecr 4268339333], length 0
19:25:24.175581 IP 194.25.95.91.443 > 192.168.2.105.37800: Flags [.], ack 1, win 8848, options [nop,nop,TS val 707829313 ecr 136719], length 0
19:25:24.176080 IP 194.25.94.203.443 > 192.168.2.105.33787: Flags [.], ack 1, win 8848, options [nop,nop,TS val 4268384389 ecr 136725], length 0
19:25:24.176138 IP 194.25.94.203.443 > 192.168.2.105.33789: Flags [.], ack 1, win 8848, options [nop,nop,TS val 4268384389 ecr 136727], length 0
19:25:24.176170 IP 194.25.94.203.443 > 192.168.2.105.33791: Flags [.], ack 1, win 8848, options [nop,nop,TS val 4268384389 ecr 136737], length 0
19:25:24.280086 IP 192.168.2.105.33788 > 194.25.94.203.443: Flags [.], ack 2533162408, win 243, options [nop,nop,TS val 204320 ecr 4268339461], length 0
19:25:24.280142 IP 192.168.2.105.33790 > 194.25.94.203.443: Flags [.], ack 3187549829, win 198, options [nop,nop,TS val 204320 ecr 4268339461], length 0
19:25:24.304244 IP 194.25.94.203.443 > 192.168.2.105.33788: Flags [.], ack 1, win 9384, options [nop,nop,TS val 4268384517 ecr 136738], length 0
19:25:24.304309 IP 194.25.94.203.443 > 192.168.2.105.33790: Flags [.], ack 1, win 9384, options [nop,nop,TS val 4268384517 ecr 136740], length 0
19:25:25.206191 ARP, Request who-has 192.168.2.183 tell 192.168.2.1, length 46
19:25:26.207295 ARP, Request who-has 192.168.2.183 tell 192.168.2.1, length 46
19:25:27.030111 IP 198.145.19.217.443 > 192.168.2.105.36972: Flags [P.], seq 405007017:405007054, ack 2985194844, win 122, options [nop,nop,TS val 4237841579 ecr 189955], length 37
19:25:27.030525 IP 198.145.19.217.443 > 192.168.2.105.36972: Flags [F.], seq 37, ack 1, win 122, options [nop,nop,TS val 4237841579 ecr 189955], length 0
19:25:27.053195 IP 198.145.19.217.443 > 192.168.2.105.36975: Flags [P.], seq 2895323378:2895323415, ack 3788361742, win 122, options [nop,nop,TS val 4237841602 ecr 189956], length 37
19:25:27.053462 IP 198.145.19.217.443 > 192.168.2.105.36975: Flags [F.], seq 37, ack 1, win 122, options [nop,nop,TS val 4237841602 ecr 189956], length 0
19:25:27.068100 IP 192.168.2.105.36972 > 198.145.19.217.443: Flags [.], ack 38, win 123, options [nop,nop,TS val 205017 ecr 4237841579], length 0
19:25:27.082169 IP 198.145.19.217.443 > 192.168.2.105.36971: Flags [P.], seq 2863236535:2863236572, ack 2693871193, win 122, options [nop,nop,TS val 4237841632 ecr 189954], length 37
19:25:27.082581 IP 198.145.19.217.443 > 192.168.2.105.36971: Flags [F.], seq 37, ack 1, win 122, options [nop,nop,TS val 4237841632 ecr 189954], length 0
19:25:27.082638 IP 198.145.19.217.443 > 192.168.2.105.36974: Flags [P.], seq 833867014:833867051, ack 1449184370, win 122, options [nop,nop,TS val 4237841632 ecr 189956], length 37
19:25:27.082989 IP 198.145.19.217.443 > 192.168.2.105.36974: Flags [F.], seq 37, ack 1, win 122, options [nop,nop,TS val 4237841632 ecr 189956], length 0
19:25:27.085157 IP 198.145.19.217.443 > 192.168.2.105.36973: Flags [P.], seq 3176514240:3176514277, ack 3123848025, win 122, options [nop,nop,TS val 4237841634 ecr 189955], length 37
19:25:27.085574 IP 198.145.19.217.443 > 192.168.2.105.36973: Flags [F.], seq 37, ack 1, win 122, options [nop,nop,TS val 4237841634 ecr 189955], length 0
19:25:27.092090 IP 192.168.2.105.36975 > 198.145.19.217.443: Flags [.], ack 38, win 123, options [nop,nop,TS val 205023 ecr 4237841602], length 0
19:25:27.096066 IP 192.168.2.105.44738 > 62.156.209.162.443: Flags [.], ack 1351045313, win 131, options [nop,nop,TS val 205024 ecr 4272101560], length 0
19:25:27.120168 IP 192.168.2.105.36971 > 198.145.19.217.443: Flags [.], ack 38, win 123, options [nop,nop,TS val 205030 ecr 4237841632], length 0
19:25:27.120237 IP 192.168.2.105.36974 > 198.145.19.217.443: Flags [.], ack 38, win 123, options [nop,nop,TS val 205030 ecr 4237841632], length 0
19:25:27.124228 IP 192.168.2.105.36973 > 198.145.19.217.443: Flags [.], ack 38, win 123, options [nop,nop,TS val 205031 ecr 4237841634], length 0
19:25:27.124412 IP 62.156.209.162.443 > 192.168.2.105.44738: Flags [.], ack 1, win 8373, options [nop,nop,TS val 4272146616 ecr 137466], length 0
19:25:31.212514 ARP, Request who-has 192.168.2.184 tell 192.168.2.1, length 46
19:25:31.873310 IP 69.171.248.16.443 > 192.168.2.105.48169: Flags [P.], seq 2935143350:2935143735, ack 671898706, win 84, options [nop,nop,TS val 2151584338 ecr 196115], length 385
19:25:31.892455 IP 192.168.2.105.48169 > 69.171.248.16.443: Flags [P.], seq 1:1011, ack 385, win 331, options [nop,nop,TS val 206223 ecr 2151584338], length 1010
19:25:32.018384 IP 69.171.248.16.443 > 192.168.2.105.48169: Flags [.], ack 1011, win 90, options [nop,nop,TS val 2151584483 ecr 206223], length 0
19:25:32.213642 ARP, Request who-has 192.168.2.184 tell 192.168.2.1, length 46
19:25:34.588823 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 4181725537:4181725591, ack 2772513713, win 1971, length 54
19:25:34.588936 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 54, win 671, length 0
19:25:34.588958 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 54:87, ack 1, win 1971, length 33
19:25:34.589020 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 87, win 671, length 0
19:25:34.627299 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], seq 1:1431, ack 87, win 671, length 1430
19:25:34.627356 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 1431:1896, ack 87, win 671, length 465
19:25:34.649346 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [.], ack 1896, win 1971, length 0
19:25:34.679196 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 87:145, ack 1896, win 1971, length 58
19:25:34.679258 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 145:199, ack 1896, win 1971, length 54
19:25:34.679394 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 199, win 671, length 0
19:25:34.851958 IP 192.168.2.105.36971 > 198.145.19.217.443: Flags [F.], seq 1, ack 38, win 123, options [nop,nop,TS val 206962 ecr 4237841632], length 0
19:25:34.853000 IP 192.168.2.105.36972 > 198.145.19.217.443: Flags [F.], seq 1, ack 38, win 123, options [nop,nop,TS val 206963 ecr 4237841579], length 0
19:25:34.853868 IP 192.168.2.105.36973 > 198.145.19.217.443: Flags [F.], seq 1, ack 38, win 123, options [nop,nop,TS val 206963 ecr 4237841634], length 0
19:25:34.854985 IP 192.168.2.105.36974 > 198.145.19.217.443: Flags [F.], seq 1, ack 38, win 123, options [nop,nop,TS val 206963 ecr 4237841632], length 0
19:25:34.855898 IP 192.168.2.105.36975 > 198.145.19.217.443: Flags [F.], seq 1, ack 38, win 123, options [nop,nop,TS val 206963 ecr 4237841602], length 0
19:25:35.056515 IP 198.145.19.217.443 > 192.168.2.105.36971: Flags [.], ack 2, win 122, options [nop,nop,TS val 4237849606 ecr 206962], length 0
19:25:35.057647 IP 198.145.19.217.443 > 192.168.2.105.36972: Flags [.], ack 2, win 122, options [nop,nop,TS val 4237849606 ecr 206963], length 0
19:25:35.058661 IP 198.145.19.217.443 > 192.168.2.105.36973: Flags [.], ack 2, win 122, options [nop,nop,TS val 4237849607 ecr 206963], length 0
19:25:35.059644 IP 198.145.19.217.443 > 192.168.2.105.36974: Flags [.], ack 2, win 122, options [nop,nop,TS val 4237849608 ecr 206963], length 0
19:25:35.060616 IP 198.145.19.217.443 > 192.168.2.105.36975: Flags [.], ack 2, win 122, options [nop,nop,TS val 4237849609 ecr 206963], length 0
19:25:37.218988 ARP, Request who-has 192.168.2.185 tell 192.168.2.1, length 46
19:25:38.220130 ARP, Request who-has 192.168.2.185 tell 192.168.2.1, length 46
19:25:38.849866 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.859818 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.869900 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.879867 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.889940 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.899829 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.909917 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.919901 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:38.929936 IP 192.168.2.1.138 > 192.168.2.255.138: NBT UDP PACKET(138)
19:25:43.225513 ARP, Request who-has 192.168.2.186 tell 192.168.2.1, length 46
19:25:44.226639 ARP, Request who-has 192.168.2.186 tell 192.168.2.1, length 46
19:25:46.424092 IP 192.168.2.105.33786 > 194.25.94.203.443: Flags [.], ack 502479045, win 311, options [nop,nop,TS val 209856 ecr 4268361605], length 0
19:25:46.447978 ARP, Request who-has 192.168.2.105 tell 192.168.2.1, length 46
19:25:46.448105 ARP, Reply 192.168.2.105 is-at 88:ae:1d:9d:24:8f, length 28
19:25:46.448127 IP 194.25.94.203.443 > 192.168.2.105.33786: Flags [.], ack 1, win 10456, options [nop,nop,TS val 4268406661 ecr 176060], length 0
19:25:49.232009 ARP, Request who-has 192.168.2.187 tell 192.168.2.1, length 46
19:25:49.756063 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [.], ack 2367080131, win 481, options [nop,nop,TS val 210689 ecr 3632845701], length 0
19:25:49.793593 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [.], ack 1, win 206, options [nop,nop,TS val 3632890736 ecr 188178], length 0
19:25:50.233157 ARP, Request who-has 192.168.2.187 tell 192.168.2.1, length 46
19:25:50.842684 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], seq 1896:3326, ack 199, win 671, length 1430
19:25:50.842747 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 3326:3882, ack 199, win 671, length 556
19:25:50.843424 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 3882:3919, ack 199, win 671, length 37
19:25:50.844067 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 3919:4023, ack 199, win 671, length 104
19:25:50.864746 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [.], ack 3882, win 1971, length 0
19:25:50.865746 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [.], ack 4023, win 1971, length 0
19:25:50.865838 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 199:236, ack 4023, win 1971, length 37
19:25:50.895796 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 236:287, ack 4023, win 1971, length 51
19:25:50.895876 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 287:330, ack 4023, win 1971, length 43
19:25:50.895906 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 330:384, ack 4023, win 1971, length 54
19:25:50.896059 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 384, win 671, length 0
19:25:53.208082 IP 192.168.2.105.35578 > 173.194.69.94.443: Flags [.], ack 4216733882, win 511, length 0
19:25:53.227763 IP 173.194.69.94.443 > 192.168.2.105.35578: Flags [.], ack 1, win 1002, length 0
19:25:54.852435 IP 192.168.2.105.33787 > 194.25.94.203.443: Flags [F.], seq 1, ack 1, win 198, options [nop,nop,TS val 211963 ecr 4268384389], length 0
19:25:54.853310 IP 192.168.2.105.33791 > 194.25.94.203.443: Flags [F.], seq 1, ack 1, win 153, options [nop,nop,TS val 211963 ecr 4268384389], length 0
19:25:54.854458 IP 192.168.2.105.33789 > 194.25.94.203.443: Flags [F.], seq 1, ack 1, win 198, options [nop,nop,TS val 211963 ecr 4268384389], length 0
19:25:54.855326 IP 192.168.2.105.33788 > 194.25.94.203.443: Flags [F.], seq 1, ack 1, win 243, options [nop,nop,TS val 211963 ecr 4268384517], length 0
19:25:54.856329 IP 192.168.2.105.33790 > 194.25.94.203.443: Flags [F.], seq 1, ack 1, win 198, options [nop,nop,TS val 211964 ecr 4268384517], length 0
19:25:54.858003 IP 192.168.2.105.37800 > 194.25.95.91.443: Flags [F.], seq 1, ack 1, win 243, options [nop,nop,TS val 211964 ecr 707829313], length 0
19:25:54.876008 IP 194.25.94.203.443 > 192.168.2.105.33787: Flags [P.], seq 1:54, ack 2, win 8848, options [nop,nop,TS val 4268415090 ecr 211963], length 53
19:25:54.876140 IP 192.168.2.105.33787 > 194.25.94.203.443: Flags [R], seq 3847634255, win 0, length 0
19:25:54.876393 IP 194.25.94.203.443 > 192.168.2.105.33787: Flags [F.], seq 54, ack 2, win 8848, options [nop,nop,TS val 4268415090 ecr 211963], length 0
19:25:54.876431 IP 192.168.2.105.33787 > 194.25.94.203.443: Flags [R], seq 3847634255, win 0, length 0
19:25:54.876953 IP 194.25.94.203.443 > 192.168.2.105.33791: Flags [P.], seq 1:54, ack 2, win 8848, options [nop,nop,TS val 4268415090 ecr 211963], length 53
19:25:54.877022 IP 192.168.2.105.33791 > 194.25.94.203.443: Flags [R], seq 443889631, win 0, length 0
19:25:54.877472 IP 194.25.94.203.443 > 192.168.2.105.33791: Flags [F.], seq 54, ack 2, win 8848, options [nop,nop,TS val 4268415090 ecr 211963], length 0
19:25:54.877519 IP 192.168.2.105.33791 > 194.25.94.203.443: Flags [R], seq 443889631, win 0, length 0
19:25:54.878050 IP 194.25.94.203.443 > 192.168.2.105.33789: Flags [P.], seq 1:54, ack 2, win 8848, options [nop,nop,TS val 4268415092 ecr 211963], length 53
19:25:54.878113 IP 192.168.2.105.33789 > 194.25.94.203.443: Flags [R], seq 2118082992, win 0, length 0
19:25:54.879891 IP 194.25.94.203.443 > 192.168.2.105.33788: Flags [P.], seq 1:54, ack 2, win 9384, options [nop,nop,TS val 4268415093 ecr 211963], length 53
19:25:54.879957 IP 192.168.2.105.33788 > 194.25.94.203.443: Flags [R], seq 1549002910, win 0, length 0
19:25:54.880318 IP 194.25.94.203.443 > 192.168.2.105.33788: Flags [F.], seq 54, ack 2, win 9384, options [nop,nop,TS val 4268415093 ecr 211963], length 0
19:25:54.880362 IP 192.168.2.105.33788 > 194.25.94.203.443: Flags [R], seq 1549002910, win 0, length 0
19:25:54.880735 IP 194.25.94.203.443 > 192.168.2.105.33790: Flags [P.], seq 1:54, ack 2, win 9384, options [nop,nop,TS val 4268415094 ecr 211964], length 53
19:25:54.880858 IP 192.168.2.105.33790 > 194.25.94.203.443: Flags [R], seq 1794499959, win 0, length 0
19:25:54.880889 IP 194.25.94.203.443 > 192.168.2.105.33790: Flags [F.], seq 54, ack 2, win 9384, options [nop,nop,TS val 4268415094 ecr 211964], length 0
19:25:54.880930 IP 192.168.2.105.33790 > 194.25.94.203.443: Flags [R], seq 1794499959, win 0, length 0
19:25:54.881968 IP 194.25.95.91.443 > 192.168.2.105.37800: Flags [P.], seq 1:54, ack 2, win 8848, options [nop,nop,TS val 707860019 ecr 211964], length 53
19:25:54.882107 IP 192.168.2.105.37800 > 194.25.95.91.443: Flags [R], seq 3379002539, win 0, length 0
19:25:54.883220 IP 194.25.95.91.443 > 192.168.2.105.37800: Flags [F.], seq 54, ack 2, win 8848, options [nop,nop,TS val 707860019 ecr 211964], length 0
19:25:54.883300 IP 192.168.2.105.37800 > 194.25.95.91.443: Flags [R], seq 3379002539, win 0, length 0
19:25:55.238541 ARP, Request who-has 192.168.2.188 tell 192.168.2.1, length 46
19:25:56.239670 ARP, Request who-has 192.168.2.188 tell 192.168.2.1, length 46
19:25:56.284790 IP 192.168.2.1 > 224.0.0.1: igmp query v3
19:25:57.944075 IP 192.168.2.105.35054 > 173.194.69.120.443: Flags [.], ack 3976208143, win 330, length 0
19:25:57.964462 IP 173.194.69.120.443 > 192.168.2.105.35054: Flags [.], ack 1, win 1002, length 0
19:25:58.600087 IP 192.168.2.105 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:25:58.712092 IP 192.168.2.105.35853 > 173.194.69.138.443: Flags [.], ack 3834898145, win 205, length 0
19:25:58.731981 IP 173.194.69.138.443 > 192.168.2.105.35853: Flags [.], ack 1, win 1002, length 0
19:25:59.741459 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [P.], seq 1:446, ack 1, win 481, options [nop,nop,TS val 213185 ecr 3632890736], length 445
19:25:59.742069 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [P.], seq 446:483, ack 1, win 481, options [nop,nop,TS val 213185 ecr 3632890736], length 37
19:25:59.742745 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [P.], seq 483:1221, ack 1, win 481, options [nop,nop,TS val 213185 ecr 3632890736], length 738
19:25:59.779252 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [.], ack 446, win 212, options [nop,nop,TS val 3632900723 ecr 213185], length 0
19:25:59.779360 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [.], ack 483, win 212, options [nop,nop,TS val 3632900723 ecr 213185], length 0
19:25:59.779653 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [P.], seq 1:38, ack 483, win 212, options [nop,nop,TS val 3632900723 ecr 213185], length 37
19:25:59.779707 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [.], ack 38, win 481, options [nop,nop,TS val 213194 ecr 3632900723], length 0
19:25:59.781453 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [.], ack 1221, win 217, options [nop,nop,TS val 3632900724 ecr 213185], length 0
19:26:00.109966 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [P.], seq 38:780, ack 1221, win 217, options [nop,nop,TS val 3632901052 ecr 213194], length 742
19:26:00.110071 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [.], ack 780, win 479, options [nop,nop,TS val 213277 ecr 3632901052], length 0
19:26:00.110094 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [P.], seq 780:823, ack 1221, win 217, options [nop,nop,TS val 3632901052 ecr 213194], length 43
19:26:00.110150 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [.], ack 823, win 479, options [nop,nop,TS val 213277 ecr 3632901052], length 0
19:26:00.110171 IP 31.13.72.23.443 > 192.168.2.105.50994: Flags [P.], seq 823:856, ack 1221, win 217, options [nop,nop,TS val 3632901053 ecr 213194], length 33
19:26:00.110216 IP 192.168.2.105.50994 > 31.13.72.23.443: Flags [.], ack 856, win 479, options [nop,nop,TS val 213277 ecr 3632901053], length 0
19:26:01.245058 ARP, Request who-has 192.168.2.189 tell 192.168.2.1, length 46
19:26:01.684368 ARP, Request who-has 192.168.2.109 tell 192.168.2.1, length 46
19:26:02.246193 ARP, Request who-has 192.168.2.189 tell 192.168.2.1, length 46
19:26:03.502743 ARP, Request who-has 192.168.2.108 tell 192.168.2.1, length 46
19:26:04.253310 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 384:438, ack 4023, win 1971, length 54
19:26:04.292177 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 438, win 671, length 0
19:26:04.853014 IP 192.168.2.105.44738 > 62.156.209.162.443: Flags [F.], seq 1, ack 1, win 131, options [nop,nop,TS val 214463 ecr 4272146616], length 0
19:26:04.881245 IP 62.156.209.162.443 > 192.168.2.105.44738: Flags [P.], seq 1:54, ack 2, win 8373, options [nop,nop,TS val 4272184373 ecr 214463], length 53
19:26:04.881374 IP 192.168.2.105.44738 > 62.156.209.162.443: Flags [R], seq 2627265937, win 0, length 0
19:26:04.881455 IP 62.156.209.162.443 > 192.168.2.105.44738: Flags [F.], seq 54, ack 2, win 8373, options [nop,nop,TS val 4272184373 ecr 214463], length 0
19:26:04.881491 IP 192.168.2.105.44738 > 62.156.209.162.443: Flags [R], seq 2627265937, win 0, length 0
19:26:07.251560 ARP, Request who-has 192.168.2.190 tell 192.168.2.1, length 46
19:26:08.252693 ARP, Request who-has 192.168.2.190 tell 192.168.2.1, length 46
19:26:11.748486 IP 69.171.248.16.443 > 192.168.2.105.48169: Flags [P.], seq 385:770, ack 1011, win 90, options [nop,nop,TS val 2151624214 ecr 206223], length 385
19:26:11.775133 IP 192.168.2.105.48169 > 69.171.248.16.443: Flags [P.], seq 1011:2021, ack 770, win 331, options [nop,nop,TS val 216193 ecr 2151624214], length 1010
19:26:11.901570 IP 69.171.248.16.443 > 192.168.2.105.48169: Flags [.], ack 2021, win 95, options [nop,nop,TS val 2151624367 ecr 216193], length 0
19:26:12.734502 IP 173.194.69.120.443 > 192.168.2.105.35054: Flags [P.], seq 1:62, ack 1, win 1002, length 61
19:26:12.734606 IP 192.168.2.105.35054 > 173.194.69.120.443: Flags [.], ack 62, win 330, length 0
19:26:12.734624 IP 173.194.69.120.443 > 192.168.2.105.35054: Flags [P.], seq 62:103, ack 1, win 1002, length 41
19:26:12.734674 IP 192.168.2.105.35054 > 173.194.69.120.443: Flags [.], ack 103, win 330, length 0
19:26:12.735334 IP 173.194.69.120.443 > 192.168.2.105.35054: Flags [F.], seq 103, ack 1, win 1002, length 0
19:26:12.735792 IP 192.168.2.105.35054 > 173.194.69.120.443: Flags [F.], seq 1, ack 104, win 330, length 0
19:26:12.756711 IP 173.194.69.120.443 > 192.168.2.105.35054: Flags [.], ack 2, win 1002, length 0
19:26:13.258079 ARP, Request who-has 192.168.2.191 tell 192.168.2.1, length 46
19:26:14.259216 ARP, Request who-has 192.168.2.191 tell 192.168.2.1, length 46
^A^A19:26:18.883257 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], seq 4023:5453, ack 438, win 671, length 1430
19:26:18.883305 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 5453:6435, ack 438, win 671, length 982
19:26:18.883817 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [P.], seq 6435:6472, ack 438, win 671, length 37
19:26:18.905692 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [.], ack 6435, win 1971, length 0
19:26:18.906144 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 438:475, ack 6472, win 1971, length 37
19:26:18.906224 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 475, win 671, length 0
^A19:26:19.264609 ARP, Request who-has 192.168.2.192 tell 192.168.2.1, length 46
19:26:19.376515 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 475:615, ack 6472, win 1971, length 140
19:26:19.376633 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 615, win 670, length 0
19:26:19.377967 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 615:1965, ack 6472, win 1971, length 1350
19:26:19.378028 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 1965, win 667, length 0
19:26:19.378041 IP 173.194.69.19.443 > 192.168.2.105.37324: Flags [P.], seq 1965:2057, ack 6472, win 1971, length 92
19:26:19.378068 IP 192.168.2.105.37324 > 173.194.69.19.443: Flags [.], ack 2057, win 667, length 0
19:26:20.265737 ARP, Request who-has 192.168.2.192 tell 192.168.2.1, length 46
19:26:25.271138 ARP, Request who-has 192.168.2.193 tell 192.168.2.1, length 46
19:26:26.272258 ARP, Request who-has 192.168.2.193 tell 192.168.2.1, length 46
Comment 34 korn2012 2013-03-07 18:46:53 UTC
BTW

after 1 hour connection lost:-(
Comment 35 Otamay 2013-03-07 19:05:36 UTC
Created attachment 94751 [details]
tcpdump -n -i eth0 when connection is dropped.

Testing by opening 13.xxx.xxx.23 webserver in a browser.
Comment 36 Otamay 2013-03-07 19:06:44 UTC
Created attachment 94761 [details]
tcpdump -n -i eth0 doing ping -c 10 13.xxx.xxx.23
Comment 37 korn2012 2013-03-07 19:15:08 UTC
packman@packman-AOD255:~$ sudo tcpdump -n -i eth0 doing ping -c 10 13.xxx.xxx.23[sudo] password for packman: 
tcpdump: syntax error
packman@packman-AOD255:~$
Comment 38 Misha Labjuk 2013-03-10 21:10:15 UTC
02:00.0 Ethernet controller: Qualcomm Atheros AR8152 v2.0 Fast Ethernet (rev c1)

If configured by iproute2 (ip addr add...) stable working.

If NetworkManager running (just running, not managing) - ethernet die after 1-5 min. After "mii-tool -r eth0" working until next freeze.
Comment 39 korn2012 2013-03-11 06:53:30 UTC
same problem with kernel 3.9 rc2
Comment 40 nucleo 2013-04-08 03:18:58 UTC
I confirm that since kernel 3.7 (and still in 3.9 rc3) after some traffic received/sent atl1c became sending ARP requests but not receiving ARP replies (on other side seen ARP requests/replies)

Adding static ARP entry for gateway makes it working again.
Comment 41 nucleo 2013-04-09 00:11:29 UTC
More testing showed that I was wrong, setting static ARP entry didn't help, incoming traffic still disappears after some time.
Only 'rmmod atl1c' 'modprobe atl1c' restores incoming traffic.
Comment 42 nucleo 2013-04-12 12:54:26 UTC
See also info on RedHat bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=928220
Comment 43 Misha Labjuk 2013-06-16 18:15:52 UTC
After set ethtool -s ifname msglvl 0xffff
kernel print many messages like:

atl1c 0000:02:00.0: TX/RX overflow (status = 0x8)
Comment 44 RussianNeuroMancer 2013-06-22 09:15:54 UTC
Same here with Linux 3.8.

~# lshw -class network
  *-network               
       description: Ethernet interface
       product: AR8151 v2.0 Gigabit Ethernet
       vendor: Qualcomm Atheros
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: eth0
       version: c0
       serial: 
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=atl1c driverversion=1.0.1.1-NAPI duplex=full ip=192.168.1.82 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:44 memory:f0100000-f013ffff ioport:2000(size=128)

(Just like described in Commentary 17)
In my case issue reproducible when some other network driver in use:
1. Broadcom proprietary driver (version 6). If driver is just installed (even if wireless connection doesn't established) Ethernet stop working few minutes later.
2. VirtualBox kernel modules (version 4.2). If VirtualBox just installed, but VM's doesn't running, Ethernet works fine. But if I start VM - Ethernet stop working few minutes later with same symptoms people describe above.
Disable/enable networking via Network Manager checkbox help for some time, but not for long.
If no other network driver is used, Ethernet works fine.
Comment 45 Neil Horman 2013-07-03 14:42:51 UTC
When you say "Broadcom proprietary driver" do you mean your atl1c card looses link if you enable some wireless interface other than an ath9k based interface?

Can someone having the problem enable dynamic debug in the atl1c driver and reproduce the problem, I've had some reporters do that here:
https://bugzilla.redhat.com/show_bug.cgi?id=928220

And the result has been that the atl1c driver reports a flood of TX/RX overflow events followed some time later by a hardware error, which resets the NIC and restores operation, only to have the device go offline again sometime later.  It would be nice to confirm others are seeing that as well

It seems that a rapid succession of TX/RX overflows in the hardware would be cause to either stop the netdevices tx queue, or reset the hardware earier after a threshold of errors was reached, but given that the problem recurrs, thats not going to help long term.
Comment 46 RussianNeuroMancer 2013-07-03 15:26:44 UTC
> When you say "Broadcom proprietary driver" do you mean your atl1c card looses
link if you enable some wireless interface other than an ath9k based interface?
When I enable Broadcom wireless interface or VirtualBox network interface (see item 2 in my previous message).
Comment 47 Neil Horman 2013-07-05 15:22:31 UTC
Created attachment 106811 [details]
patch to dump dma mappings on error

Ok, so this isn't directly related to enabling a wireless interface then, nor is is the problem specific to ath9k and atl1c.

Can you please try the following:

1) Rebuild your kernel with the attached patch and CONFIG_DMA_API_DEBUG enabled

2) use ethtool to set the driver msg_enabled flags to all on for both the network interfaces in question.

3) Recreate the problem.

That should let us see what the dma state of the driver is when this problem  occurs.  If you can upload the message log after doing these things something will jump out about it to us.
Comment 48 RussianNeuroMancer 2013-07-05 15:52:29 UTC
Personally I can't do that (I am not developer). Hopefully other people who have this issue can help dump dma mappings.
Comment 49 Neil Horman 2013-07-08 15:04:51 UTC
Do you have the kernel source?  I can walk you through building it if you like.
Comment 50 Neil Horman 2013-07-10 14:52:49 UTC
anyone, can someone run the above patch?
Comment 51 Eric Dumazet 2013-07-10 15:17:16 UTC
And make sure following fix was applied

commit 7cb08d7f3a5ea6131f4f243c2080530ac41cb293
Author: Huang, Xiong <xiong@qca.qualcomm.com>
Date:   Tue Feb 19 07:23:09 2013 +0000

    atl1c: restore buffer state
    
    in the previous commit : f1f220ea1dda078, the BUSY state of buffer is wrongly
    deleted. this patch just restore it.
Comment 52 Vincent Alquier 2013-07-11 13:39:46 UTC
(In reply to Neil Horman from comment #47)
> Created attachment 106811 [details]
> patch to dump dma mappings on error
> 
> Ok, so this isn't directly related to enabling a wireless interface then,
> nor is is the problem specific to ath9k and atl1c.
> 
> Can you please try the following:
> 
> 1) Rebuild your kernel with the attached patch and CONFIG_DMA_API_DEBUG
> enabled
> 
> 2) use ethtool to set the driver msg_enabled flags to all on for both the
> network interfaces in question.
> 
> 3) Recreate the problem.
> 
> That should let us see what the dma state of the driver is when this problem
> occurs.  If you can upload the message log after doing these things
> something will jump out about it to us.

I did reproduce the problem after applying your patch and rebuild the kernel with CONFIG_DMA_API_DEBUG enabled.

It produces 50 MB of log. You can download it (in .xz format) from
http://demo.ovh.eu/download/dd45ef7b1e001cd85766a6b13500aa7f/syslog.xz

here is the md5sum:
41609e6033ee273124f15e44b90fafc7  syslog.xz

Sorry for the download link, but the file seems to big to be uploaded as attachment.
Comment 53 Neil Horman 2013-07-11 16:15:58 UTC
Thank you Vincent.

There doesn't appear to be anything wrong with the DMA entries themselves, which is good

That said, I do note that for every TX/RX overflow message we get we see the exact same dma descriptor dump.  Its all 512 descriptors available to the RX ring, that are just sitting there, mapped.

That suggests that either:

1) The hardware has sent/received no frames and is just sitting idle, but then why would we receive overflow errors

2) We've received lots of frames, and their waiting in dma memory, but we never get an interrupt about them, i.e. the ISR_RX_PKT bit in the IMR isn't set

Theres certainly other possibilities, but these two stand out to me, although I don't really believe either of them yet.  

Some more questions:
1) What kernel version were you running this on?  As Eric notes in comment 51, does your build have commit 7cb08d7f3a5ea6131f4f243c2080530ac41cb293 in place (FWIW the person reporting this on fedora 18 had this patch in place and it didn't fix this problem), but It would still be good to know.

2) Can you modify the patch to dump out the IMR on the TX/RX overflow error?  I can send an updated patch if you would rather.  Thanks!
Comment 54 Vincent Alquier 2013-07-11 16:46:38 UTC
(In reply to Neil Horman from comment #53)
> Thank you Vincent.

Thank you Neil, for working on this problem !

> 
> There doesn't appear to be anything wrong with the DMA entries themselves,
> which is good
> 
> That said, I do note that for every TX/RX overflow message we get we see the
> exact same dma descriptor dump.  Its all 512 descriptors available to the RX
> ring, that are just sitting there, mapped.
> 
> That suggests that either:
> 
> 1) The hardware has sent/received no frames and is just sitting idle, but
> then why would we receive overflow errors
> 
> 2) We've received lots of frames, and their waiting in dma memory, but we
> never get an interrupt about them, i.e. the ISR_RX_PKT bit in the IMR isn't
> set
> 
> Theres certainly other possibilities, but these two stand out to me,
> although I don't really believe either of them yet.  
> 
> Some more questions:
> 1) What kernel version were you running this on?  As Eric notes in comment
> 51, does your build have commit 7cb08d7f3a5ea6131f4f243c2080530ac41cb293 in
> place (FWIW the person reporting this on fedora 18 had this patch in place
> and it didn't fix this problem), but It would still be good to know.

Debian kernel 3.9.8 built from debian source package. The 7cb08d7f3a5ea6131f4f243c2080530ac41cb293 commit is in place.

> 
> 2) Can you modify the patch to dump out the IMR on the TX/RX overflow error?
> I can send an updated patch if you would rather.  Thanks!

Yes, can you please send me a patch to apply ?
Comment 55 Neil Horman 2013-07-12 15:28:49 UTC
Created attachment 106879 [details]
new debug patch to check hardware interrupt mask

Here you go, I removed the dma debug dump to avoid too much noise, and add a dump of the hardware interrupt mask on tx/rx overflow.  I also noted something interesting.  When enabling/disabling irqs directly (on ifup/ifdown), we set the irq mask and immediately flush the register write, but we don't do so on napi poll, which strikes me as very odd.  I don't see why it would start causing problems now, but certainly it would seem to me, that if there could be some latency between the time you masked rx packet interrupt behavior and the time you actually started honoring that, you might get some odd behavior.  As such I've added flushes to the interrupt service routine when we disable rx pkt interrupt status notifications and the napi poll routine where we re-enable them, just in case it alleviates the issue.

Thanks!
Comment 56 Vincent Alquier 2013-07-12 16:43:14 UTC
Created attachment 106881 [details]
syslog after ptaching using attachment 106879 [details]


Here is the syslog after patching using attachment 106879 [details].

Few seconds before the TX/RX overflow, I noticed the NetworkManager warning :
nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted

I don't think it's related, but I didn't remove it, so you can see.
Comment 57 Neil Horman 2013-07-15 15:53:13 UTC
dang, thank you for trying, but that pretty clearly shows that bit 16 (mask 0x10000) is set in the mask register which should indicate that we get receive packet interrupts.  I'm not sure what else might be going on here, Eric, do you have any thoughts?
Comment 58 Neil Horman 2013-07-19 14:54:19 UTC
Ok, so I've gone over this and I don't see any other way to get visibility on this without someone from atheros chiming in.  AT this point I think the best course of action is likely a bisect.  Is anyone in a position to run one?
Comment 59 Luis Henriques 2013-07-26 10:22:51 UTC
I've managed to bisect this and reached the some results as those presented in comment #14.  I've built a 3.11.0-rc2 test kernel reverting the following two commits:

e5e67305885eb12849b5475764b0542f03dc2b59 skbuff: Move definition of NETDEV_FRAG_PAGE_MAX_SIZE
69b08f62e17439ee3d436faf0b9a7ca6fffb78db net: use bigger pages in __netdev_alloc_frag

And it does seem to solve the issue.  However, I couldn't figure out what was wrong with commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db.
Comment 60 Neil Horman 2013-07-26 13:43:36 UTC
hmm, I have a _very_ loose theory.  atl1c uses netdev_alloc_skb to allocate buffers in the rx path, which is not uncommon.  The difference between atl1c and every other net driver that uses this call is what the driver does with the skb afterwards.  Every other driver uses the allocated skb in a copy path - that is the received data from the wire is copied into the skb and sent up the stack.  atl1c uses the skb as dma-able memory - i.e., it refills its rx ring with that data.  The problem is that netdev_alloc_skb doesn't set the GFP_DMA flag when it does the allocation.  I'm hypothesizing that some aspect of the netdev_alloc_frag changes in 69b08f62e17439ee3d436faf0b9a7ca6fffb78db increase the likelyhood under various circumstances that netdev_alloc_skb will return memory that isn't appropriate for DMA, leading to our odd lockup behavior.  I'll have a patch to test this out shortly.
Comment 61 Neil Horman 2013-07-26 14:10:42 UTC
Created attachment 107018 [details]
patch to ensure that __netdev_alloc_skb returns DMA safe memory

here you go, I think this will fix the problem.  The more I look at it the more I think this explains the behavior everyone has been seeing.
Comment 62 Luis Henriques 2013-07-26 14:32:29 UTC
Looks like you were right.  I've tested your patch and I can't reproduce the issue anymore.

Thanks a lot Neil.
Comment 63 Vincent Alquier 2013-07-26 15:11:50 UTC
It seems good for me too.

Big thanks !


2013/7/26  <bugzilla-daemon@bugzilla.kernel.org>:
> https://bugzilla.kernel.org/show_bug.cgi?id=54021
>
> --- Comment #62 from Luis Henriques <luis.henrix@gmail.com> ---
> Looks like you were right.  I've tested your patch and I can't reproduce the
> issue anymore.
>
> Thanks a lot Neil.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 64 Neil Horman 2013-07-26 16:02:05 UTC
Thanks for testing all, I'll get this posted ASAP
Comment 65 Neil Horman 2013-07-26 17:03:20 UTC
http://marc.info/?l=linux-netdev&m=137485728003941&w=2

Posted here
Comment 66 Vincent Alquier 2013-07-31 13:25:07 UTC
(In reply to Vincent Alquier from comment #63)
> It seems good for me too.

hum. Sorry for that, I spoked too soon.

I can reproduce the problem using the patched kernel driver.
But it seems it was much longer before it happends.
Comment 67 Eric Dumazet 2013-08-04 19:35:56 UTC
OK, could you please latest David Miller net or net-next tree ?

(They now include following commit 

http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=7b70176421993866e616f1cbc4d0dd4054f1bf78
Comment 68 Vincent Alquier 2013-08-05 17:27:30 UTC
(In reply to Eric Dumazet from comment #67)
> OK, could you please latest David Miller net or net-next tree ?
> 
> (They now include following commit 
> 
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/
> ?id=7b70176421993866e616f1cbc4d0dd4054f1bf78

I am running the driver from David Miller net-next tree for few hours now (with the specific atl1c_alloc_skb allocation method) and I still wasn't able to reproduce the problem.

I will test it for few more days/packets/GB, but it works fine for now.

Note: I still got the carrier counter doing some increments (it's now to 6).

eth0      Link encap:Ethernet  HWaddr f0:bf:97:14:eb:62  
          inet addr:10.1.0.40  Bcast:10.1.0.255  Mask:255.255.255.0
          inet6 addr: fe80::f2bf:97ff:fe14:eb62/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12555727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14947855 errors:0 dropped:0 overruns:0 carrier:6
          collisions:0 txqueuelen:1000 
          RX bytes:16482016938 (15.3 GiB)  TX bytes:15266617038 (14.2 GiB)
Comment 69 Feng Tang 2016-05-30 08:10:22 UTC
Created attachment 218221 [details]
atl1c_rx_overflow_debug.patch
Comment 70 Feng Tang 2016-05-30 08:12:09 UTC
Could anyone help to test the atl1c_rx_overflow_debug.patch ? we met a similar problem in https://bugzilla.kernel.org/show_bug.cgi?id=70761 

the idea is trying to work around the HW problem directly without adding a new custom allocator
Comment 71 charanskr 2017-04-12 09:35:34 UTC
i have connected but no response

Note You need to log in before you can comment on or make changes to this bug.