LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 05-02-2018, 01:31 PM   #1
adrhc
Member
 
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Rep: Reputation: 13
Question internet access with ping has 100% loss


LAST BREAKTHROUGH -> search the tshark results below for a possible cause of the problem

Hi, at home I have the following setup:

Internet - NAS (Ubuntu 16.04.4 LTS) - LAN (Asus N56U WiFi) - family users. NAS connects using pppoe (ppp0, cable) to Internet while having eth0 (192.168.0.1, cable) to LAN. Asus N56U connects to NAS using static ip 192.168.0.2/255.255.255.0 with DNS 192.168.0.1.

Everything works fine:
NAS & family users access the Internet while Internet access NAS.

I also have another extremely similar router (Asus RT-AC66U) which simply swapping with Asus N56U while keeping same simple settings doesn't work . I mean anything that touches the Internet dies though my personal web sites are still accessible from LAN.

I tried this command on NAS (108.177.119.94 is www.google.ro):
Code:
sudo tcpdump -vv -i eth0 --direction=in -n ip proto \\icmp
while on RT-AC66U (with telnet access) I execute this:
Code:
ping www.google.com
On NAS I receive this:
Code:
$sudo tcpdump -vv -i eth0 --direction=in -n ip proto \\icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:33:57.279728 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 172.217.17.36: ICMP echo request, id 15109, seq 0, length 64
20:36:56.759155 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 172.217.17.35: ICMP echo request, id 44293, seq 0, length 64
...
while on RT-AC66U I get 100% ping loss.
When RT-AC66U is pinging NAS:
Code:
ping -c 1 -s 1472 -I eth0 192.168.0.1
I have 100% ping success (max MTU is 1472).
Also RT-AC66U clearly shows in its admin interface that has Internet access but all (browser, ping) that touch the Internet fails.
What could be the problem or how could I further troubleshoot this?

EDIT

With the command:
Code:
    ping -c 1 www.google.ro
I get (there's also a NTP service running on router):
Code:
    $sudo tcpdump -vv --direction=inout -n
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    09:31:08.734787 IP (tos 0x0, ttl 64, id 54539, offset 0, flags [DF], proto UDP (17), length 59)
        192.168.0.2.45945 > 192.168.0.1.53: [udp sum ok] 2+ AAAA? www.google.ro. (31)
    09:31:08.735222 IP (tos 0x0, ttl 64, id 51978, offset 0, flags [DF], proto UDP (17), length 87)
        192.168.0.1.53 > 192.168.0.2.45945: [udp sum ok] 2 q: AAAA? www.google.ro. 1/0/0 www.google.ro. AAAA 2a00:1450:4005:800::2003 (59)
    09:31:08.735692 IP (tos 0x0, ttl 64, id 54539, offset 0, flags [DF], proto UDP (17), length 59)
        192.168.0.2.49395 > 192.168.0.1.53: [udp sum ok] 3+ A? www.google.ro. (31)
    09:31:08.736093 IP (tos 0x0, ttl 64, id 51979, offset 0, flags [DF], proto UDP (17), length 75)
        192.168.0.1.53 > 192.168.0.2.49395: [udp sum ok] 3 q: A? www.google.ro. 1/0/0 www.google.ro. A 172.217.16.67 (47)
    09:31:08.737265 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        192.168.0.2 > 172.217.16.67: ICMP echo request, id 49922, seq 0, length 64
    09:31:09.084884 IP (tos 0x0, ttl 64, id 54574, offset 0, flags [DF], proto UDP (17), length 62)
        192.168.0.2.54246 > 192.168.0.1.53: [udp sum ok] 2+ A? dns.msftncsi.com. (34)
    09:31:09.085301 IP (tos 0x0, ttl 64, id 52022, offset 0, flags [DF], proto UDP (17), length 78)
        192.168.0.1.53 > 192.168.0.2.54246: [udp sum ok] 2 q: A? dns.msftncsi.com. 1/0/0 dns.msftncsi.com. A 131.107.255.255 (50)
    09:31:14.081697 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.2, length 46
    09:31:14.081787 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.1 is-at d0:50:99:7c:28:bf, length 28
    09:31:14.084774 IP (tos 0x0, ttl 64, id 55074, offset 0, flags [DF], proto UDP (17), length 62)
        192.168.0.2.56118 > 192.168.0.1.53: [udp sum ok] 2+ A? dns.msftncsi.com. (34)
    09:31:14.085194 IP (tos 0x0, ttl 64, id 52668, offset 0, flags [DF], proto UDP (17), length 78)
        192.168.0.1.53 > 192.168.0.2.56118: [udp sum ok] 2 q: A? dns.msftncsi.com. 1/0/0 dns.msftncsi.com. A 131.107.255.255 (50)
    09:31:19.084681 IP (tos 0x0, ttl 64, id 55574, offset 0, flags [DF], proto UDP (17), length 62)
        192.168.0.2.48848 > 192.168.0.1.53: [udp sum ok] 2+ A? dns.msftncsi.com. (34)
    09:31:19.088817 IP (tos 0x0, ttl 64, id 52778, offset 0, flags [DF], proto UDP (17), length 78)
        192.168.0.1.53 > 192.168.0.2.48848: [udp sum ok] 2 q: A? dns.msftncsi.com. 1/0/0 dns.msftncsi.com. A 131.107.255.255 (50)
    ^C
    13 packets captured
    13 packets received by filter
    0 packets dropped by kernel
I have for the NAS/ppp0 interface the ip 188.25.28.84. Running:
Code:
    ping 188.25.28.84
has 100% success so I guess NAS/eth0 is indeed passing further the ping requests.

With everything the same, just replacing the RT-AC66U router with N56U router I get (for same ping command):
Code:
    $sudo tcpdump -vv --direction=inout -n
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    09:42:49.938781 IP (tos 0x0, ttl 64, id 46253, offset 0, flags [DF], proto UDP (17), length 59)
        192.168.0.2.43709 > 192.168.0.1.53: [udp sum ok] 2+ AAAA? www.google.ro. (31)
    09:42:49.939220 IP (tos 0x0, ttl 64, id 32438, offset 0, flags [DF], proto UDP (17), length 87)
        192.168.0.1.53 > 192.168.0.2.43709: [udp sum ok] 2 q: AAAA? www.google.ro. 1/0/0 www.google.ro. AAAA 2a00:1450:400e:801::2003 (59)
    09:42:49.940179 IP (tos 0x0, ttl 64, id 46253, offset 0, flags [DF], proto UDP (17), length 59)
        192.168.0.2.40809 > 192.168.0.1.53: [udp sum ok] 3+ A? www.google.ro. (31)
    09:42:49.943623 IP (tos 0x0, ttl 64, id 32439, offset 0, flags [DF], proto UDP (17), length 75)
        192.168.0.1.53 > 192.168.0.2.40809: [udp sum ok] 3 q: A? www.google.ro. 1/0/0 www.google.ro. A 216.58.212.163 (47)
    09:42:49.944931 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        192.168.0.2 > 216.58.212.163: ICMP echo request, id 20227, seq 0, length 64
    09:42:49.984249 IP (tos 0xc, ttl 55, id 0, offset 0, flags [none], proto ICMP (1), length 84)
        216.58.212.163 > 192.168.0.2: ICMP echo reply, id 20227, seq 0, length 64
    ^C
    6 packets captured
    6 packets received by filter
    0 packets dropped by kernel
The UFW log has nothing for this ping command. It's odd the fact that is not working the internet access while same configuration works for the N56U router, an Asus too, with same configuration options & interface.

Last edited by adrhc; 05-12-2018 at 08:35 AM. Reason: announcing last finding
 
Old 05-02-2018, 05:21 PM   #2
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,987

Rep: Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626
The two models ought to be very similar and ought to have almost exact same Asus OS.
That makes me think it isn't the router but you will have to prove this router will work like you wish.

My feeling is I'd look to the server and see if you set any settings in it for mac address or leases.
 
Old 05-04-2018, 01:56 AM   #3
adrhc
Member
 
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Original Poster
Rep: Reputation: 13
I would agree with you there's some wrong configuration on NAS but see EDIT2: only swapping RT-AC66U with N56U makes things working.
I have default configuration for mac (both NAS and routers) while there's no DHCP lease because I use a static ip for the router's WAN configuration.
 
Old 05-04-2018, 05:25 PM   #4
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,987

Rep: Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626
So the question is if the router is at fault or something else.

Can you test the router in the configuration that you wish to run it outside of your setup?

There are logs and network tools in each of the routers. The web based config ought to be almost identical. Maybe some variation in options. This one isn't a T-mobile branded router is it?

Last edited by jefro; 05-04-2018 at 05:27 PM.
 
Old 05-05-2018, 07:17 AM   #5
adrhc
Member
 
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Original Poster
Rep: Reputation: 13
I don't know exactly if it's a T-mobile ... Anyway these are the routers:
https://www.asus.com/us/Networking/R...pecifications/
https://www.asus.com/Networking/RTAC66U/specifications/
The problematic one (AC66U) is new meaning just 2 days ago I opened its box (yeah, was unused from 2015 ). Also is working fine; right now is directly connected to internet using pppoe (I installed it in another location).

I further investigated by using this command (on NAS) for both routers (108.177.119.94 is www.google.ro):
Code:
sudo tcpdump -AX -vnni eth0 -c 2 dst 108.177.119.94
while running this on routers (I have telnet access to them):
Code:
ping -c 2 108.177.119.94
I get this for N56U:
Code:
09:00:47.036839 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 108.177.119.94: ICMP echo request, id 63814, seq 0, length 64
        0x0000:  4500 0054 0000 4000 4001 95ef c0a8 0002  E..T..@.@.......
        0x0010:  6cb1 775e 0800 d64a f946 0000 7cd9 ab94  l.w^...J.F..|...
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000                                ....
09:00:48.044176 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 108.177.119.94: ICMP echo request, id 63814, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 95ef c0a8 0002  E..T..@.@.......
        0x0010:  6cb1 775e 0800 95eb f946 0001 ad37 bb94  l.w^.....F...7..
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000                                ....
and this for AC66U (the problematic one):
Code:
09:07:16.655875 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 108.177.119.94: ICMP echo request, id 27906, seq 0, length 64
    0x0000:  4500 0054 0000 4000 4001 95ef c0a8 0002  E..T..@.@.......
    0x0010:  6cb1 775e 0800 638c 6d02 0000 de6b 4905  l.w^..c.m....kI.
    0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0050:  0000 0000                                ....
09:07:17.668123 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 108.177.119.94: ICMP echo request, id 27906, seq 1, length 64
    0x0000:  4500 0054 0000 4000 4001 95ef c0a8 0002  E..T..@.@.......
    0x0010:  6cb1 775e 0800 7e18 6d02 0001 b4de 5805  l.w^..~.m.....X.
    0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0050:  0000 0000                                ....
With N56U I see (using tcpdump) the request travelling from eth0 through ppp0 to Internet and back; with AC66U the above result is all I see (the request is received by eth0 then nothing).

Considering the routers to be very similar (same company, same configuration options) and the entire context the same (I'm just swapping the routers) I guess the only difference should be between the above request, but what possibly could be?

PS: I'm on AC66U while writing these; RDP also works fine

Last edited by adrhc; 05-05-2018 at 07:59 AM. Reason: typo
 
Old 05-05-2018, 07:46 AM   #6
adrhc
Member
 
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Original Poster
Rep: Reputation: 13
Another way of viewing the above results (already saved as *.pcap files) is with tshark (1th frame only).

For N56U I get:
Code:
$tshark -r n56u-eth0-dst.pcap -V
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: May  5, 2018 09:00:47.036839000 EEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1525500047.036839000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:data]
Ethernet II, Src: Motorola_1b:ed:f2 (98:0c:a5:1b:ed:f2), Dst: AsrockIn_7c:28:bf (d0:50:99:7c:28:bf)
    Destination: AsrockIn_7c:28:bf (d0:50:99:7c:28:bf)
        Address: AsrockIn_7c:28:bf (d0:50:99:7c:28:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Motorola_1b:ed:f2 (98:0c:a5:1b:ed:f2)
        Address: Motorola_1b:ed:f2 (98:0c:a5:1b:ed:f2)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.0.2, Dst: 108.177.119.94
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 84
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x95ef [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.0.2
    Destination: 108.177.119.94
    [Source GeoIP: Unknown]
    [Destination GeoIP: United States, AS15169 Google Inc., Mountain View, CA, 37.419201, -122.057404]
        [Destination GeoIP Country: United States]
        [Destination GeoIP AS Number: AS15169 Google Inc.]
        [Destination GeoIP City: Mountain View, CA]
        [Destination GeoIP Latitude: 37.419201]
        [Destination GeoIP Longitude: -122.057404]
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xd64a [correct]
    [Checksum Status: Good]
    Identifier (BE): 63814 (0xf946)
    Identifier (LE): 18169 (0x46f9)
    Sequence number (BE): 0 (0x0000)
    Sequence number (LE): 0 (0x0000)
    Data (56 bytes)

0000  7c d9 ab 94 00 00 00 00 00 00 00 00 00 00 00 00   |...............
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00                           ........
        Data: 7cd9ab940000000000000000000000000000000000000000...
        [Length: 56]
For AC66U I get:
Code:
$tshark -r ac66u-eth0-dst.pcap -V
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: May  5, 2018 09:07:16.655875000 EEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1525500436.655875000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:data]
Ethernet II, Src: AsustekC_cb:20:d0 (2c:56:dc:cb:20:d0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: AsustekC_cb:20:d0 (2c:56:dc:cb:20:d0)
        Address: AsustekC_cb:20:d0 (2c:56:dc:cb:20:d0)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.0.2, Dst: 108.177.119.94
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 84
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x95ef [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.0.2
    Destination: 108.177.119.94
    [Source GeoIP: Unknown]
    [Destination GeoIP: United States, AS15169 Google Inc., Mountain View, CA, 37.419201, -122.057404]
        [Destination GeoIP Country: United States]
        [Destination GeoIP AS Number: AS15169 Google Inc.]
        [Destination GeoIP City: Mountain View, CA]
        [Destination GeoIP Latitude: 37.419201]
        [Destination GeoIP Longitude: -122.057404]
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x638c [correct]
    [Checksum Status: Good]
    Identifier (BE): 27906 (0x6d02)
    Identifier (LE): 621 (0x026d)
    Sequence number (BE): 0 (0x0000)
    Sequence number (LE): 0 (0x0000)
    Data (56 bytes)

0000  de 6b 49 05 00 00 00 00 00 00 00 00 00 00 00 00   .kI.............
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00                           ........
        Data: de6b49050000000000000000000000000000000000000000...
        [Length: 56]
I guess the section (for AC66U):
Code:
Destination: Broadcast (ff:ff:ff:ff:ff:ff)

might be the problem? If affirmative then why this happened?

Last edited by adrhc; 05-05-2018 at 08:05 AM.
 
Old 05-07-2018, 01:10 PM   #7
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,987

Rep: Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626
Gateway entry or subnet issue?

Last edited by jefro; 05-07-2018 at 01:11 PM.
 
Old 05-09-2018, 02:18 AM   #8
adrhc
Member
 
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Original Poster
Rep: Reputation: 13
Just swapping the routers makes things work so I don't know. The configuration is exactly the same for both routers - easy task to do when the GUI is the same. Anyway, what kind of issue do you think might happen?
 
Old 05-09-2018, 03:08 PM   #9
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,987

Rep: Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626Reputation: 3626
They could share the same basic version of the ASWRT OS but each device may have a few unique features. I'd think it more of a basic networking setting over any added feature. Would be nice to be on same level I'd guess.

Might even be able to set the settings from working to non-working model.
 
  


Reply

Tags
router configuration



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
100% Packet Loss on external Ping requests on Fedora 10 trev2006 Linux - Networking 1 01-04-2011 02:25 PM
Wine - Multiping and ping plotter show 100% loss mnstrprtier858 Linux - Newbie 3 11-29-2008 04:51 PM
ping packet loss 100% kpachopoulos Linux - Networking 1 04-14-2005 05:29 PM
ping 100% packets loss. linux 2.5.69 odomae Linux - Networking 11 08-11-2003 11:17 AM
Can ping LAN but cant access internet. Dirt Linux - Networking 2 08-11-2003 02:45 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 06:47 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration