Bug 54021 (korn2012)
| Summary: | No internet with kernel 3.7 or 3.8 with LAN | ||
|---|---|---|---|
| Product: | Networking | Reporter: | korn2012 (david.erbs) |
| Component: | IPV4 | Assignee: | Stephen Hemminger (stephen) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | alan, charanreddy315, eric.dumazet, feng.tang, luis.henriques, Matt.Pikaflash, nhorman, nic-devel, nucleo, russianneuromancer, spike, vincent.alquier |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | since 3.7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
tcpdump -n -i eth0 when connection is dropped.
tcpdump -n -i eth0 doing ping -c 10 13.xxx.xxx.23 patch to dump dma mappings on error new debug patch to check hardware interrupt mask syslog after ptaching using attachment 106879 patch to ensure that __netdev_alloc_skb returns DMA safe memory atl1c_rx_overflow_debug.patch |
||
|
Description
korn2012
2013-02-17 13:37:57 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)
can you please paste dmesg log when issue arise ? 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 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 please tell me your detailed kernel version for 3.5 3.7/3.8, thanks 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 can you please paste the log for lspci -d 1969:2060 sorry, type this command, please lspci -d 1969:2060 -xxx 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:~$ 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:~$ 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 If you disable TSO, does it change anything ? ethtool -K eth0 tso off 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]
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 Thanks for the bisection. You need to report to atl1c author/maintainer this bug, as the driver needs a fix. By the way it might be already solved in current tree. Please try 3.9-rc1 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.
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 ! 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 ? not sure, I need doulbe check with the hardware designer. thanks for your info ! it supports that case. 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 ? 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! It could be a memory issue. Maybe your wireless adapter leaks memory after a while. Do you have CONFIG_COMPACTION=y in your .config ? 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 :( Yes, I do have CONFIG_COMPACTION=y (due to TRANSPARENT_HUGEPAGE=y). However, even disabling both options the problem persists. Nothing in your kernel log ? (dmesg) When problem happens, take a snapshot of cat /proc/buddyinfo ifconfig -a 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
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. (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. 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 ? 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 BTW after 1 hour connection lost:-( Created attachment 94751 [details]
tcpdump -n -i eth0 when connection is dropped.
Testing by opening 13.xxx.xxx.23 webserver in a browser.
Created attachment 94761 [details]
tcpdump -n -i eth0 doing ping -c 10 13.xxx.xxx.23
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:~$ 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. same problem with kernel 3.9 rc2 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. 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. See also info on RedHat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=928220 After set ethtool -s ifname msglvl 0xffff kernel print many messages like: atl1c 0000:02:00.0: TX/RX overflow (status = 0x8) 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.
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. > 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).
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.
Personally I can't do that (I am not developer). Hopefully other people who have this issue can help dump dma mappings. Do you have the kernel source? I can walk you through building it if you like. anyone, can someone run the above patch? 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. (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. 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! (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 ? 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!
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. 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? 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? 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. 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. 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.
Looks like you were right. I've tested your patch and I can't reproduce the issue anymore. Thanks a lot Neil. 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. Thanks for testing all, I'll get this posted ASAP (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. 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 (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) Created attachment 218221 [details]
atl1c_rx_overflow_debug.patch
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 i have connected but no response |