TCP IPv4 Requirements and testing

D

DelJo63

To assist in debugging PC networking; here's some requirements to keep in mind:

TCP IPv4 requirements:

  • an IP v4 address
  • a network mask consistent with the V4 class address
  • a Gateway address
  • (typically the default address/mask 0.0.0.0/0.0.0.0 routed thru the IPv4 address)[*]
  • A DHCP address
  • one or more DNS addresses
example:
  • IPv4 Address. . . . . . . . . . . : 192.168.0.5(Preferred)
  • Subnet Mask . . . . . . . . . . . : 255.255.255.0
  • Lease Obtained. . . . . . . . . . : Friday, November 03, 2017 3:53:52 PM
  • Lease Expires . . . . . . . . . . : Monday, December 10, 2153 10:48:24 PM
  • Default Gateway . . . . . . . . . : 192.168.0.1
  • DHCP Server . . . . . . . . . . . : 192.168.0.1
  • DNS Servers . . . . . . . . . . . : 209.18.47.61
  • 209.18.47.62
  • NetBIOS over Tcpip. . . . . . . . : Enabled

Route print(partially) shows:
Code:
   Active Routes:
   Network Destination   Netmask   Gateway   Interface  Metric
[*]   0.0.0.0          0.0.0.0   192.168.0.1   192.168.0.5   2984

the default shows, to get to the Gateway, we send every thing on the interface address 192.168.0.5

Notes on the LEASE:
  • The lease is relative to the Gateway that provided it - - in this case, it's the
  • Local Lan Router located at 192.168.0.1 - - that's a private, non-routed LAN address.
  • This is not the same thing as the ISP lease provided for the PUBLIC WAN access - -
  • which is only seen within the router setup.

The WAN side of the router has settings for
  • the Public address/mask
  • the default ISP Gateway address
  • and the DHCP server
  • A DNS pair of addresses operated by the ISP
  • and the lease begin/end for the Public address

Your access to the Internet REQUIRES that you can access the ISP Gateway, DHCP and DNS Servers as shown. Typically such access is proven via PING, although the ISP is not required to make these servers respond to it.

BTW: No home network EVER needs IPv6 support which in fact opens your system to IPv6 Tunneling issues which are difficult to both control and to debug.
 
Last edited by a moderator:
What is the ISP gateway to which I am connected??

If you can't get to the ISP, you can't get anywhere, so this is an important requirement. If you are connected, you can find it with TRACERT. To make two points at the same time, you may have multiple routers on you lan (I have two) and need to know which is the router that connects directly to the ISP.
In the example shown below, my ISP gateway is on line 2: 98.148.232.1 - - it's the first address that is NOT associated with any local area network (lan) - - line 1a,b,c are doctored up to show you these addresses.

> TRACERT /d 8.8.8.8
Code:
Tracing route to 8.8.8.8 over a maximum of 30 hops

  1a    <1 ms    <1 ms    <1 ms  192.168.0.1 -> 192.168.255.254
  1b    <1 ms    <1 ms    <1 ms  172.16.1.x --> 172.31.255.254
  1c    <1 ms    <1 ms    <1 ms  10.x.x.x -> 10.255.255.254
  2    18 ms    13 ms    12 ms  98.148.232.1
  3    14 ms    15 ms   105 ms  24.30.172.109
  4    18 ms    15 ms    15 ms  72.129.14.168
  5    32 ms    14 ms    15 ms  72.129.13.2
  6    18 ms    15 ms    16 ms  66.109.6.64
  7    20 ms    23 ms    15 ms  107.14.19.37
  8    16 ms    15 ms    13 ms  107.14.17.248
  9    17 ms    14 ms    15 ms  66.110.59.81
 10    19 ms    17 ms    22 ms  72.14.195.102
 11     *        *        *     Request timed out.
 12    18 ms    18 ms    15 ms  108.170.225.68
 13    15 ms    18 ms    14 ms  216.239.50.89
 14    15 ms    13 ms    14 ms  8.8.8.8

But if you're having connection issues and can't PING 8.8.8.8 you'll need to go deeper.
Log into your router and look at the WAN side settings to see your Public IP address and the
ISP Gateway to which it is connected:
On my Netgear, clicking the Connection Status button will show the ISP Gateway.

upload_2017-11-5_7-38-57.jpeg
 
Last edited by a moderator:
To determine if your problem is in the TCP or in a browser, we use PING.
In a Command Prompt window; we
  1. first PING BY ADDRESS
  2. and then PING BY DOMAIN NAME
ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=16ms TTL=57
Reply from 8.8.8.8: bytes=32 time=14ms TTL=57
Reply from 8.8.8.8: bytes=32 time=18ms TTL=57
Reply from 8.8.8.8: bytes=32 time=16ms TTL=57

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 18ms, Average = 16ms

This shows we can connect to our ISP and send packets to an ip address. Without this we go no where and our TCP setup is flat wrong for our ISP.

ping yahoo.com
Pinging yahoo.com [98.139.180.180] with 32 bytes of data:
Reply from 98.139.180.180: bytes=32 time=102ms TTL=47
Reply from 98.139.180.180: bytes=32 time=95ms TTL=47
Reply from 98.139.180.180: bytes=32 time=121ms TTL=47
Reply from 98.139.180.180: bytes=32 time=97ms TTL=47

Ping statistics for 98.139.180.180:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 95ms, Maximum = 121ms, Average = 103ms

Using the domain name does another step - - it accesses the DNS to return the correct ip address and then proceeds per the above. If we can't resolve the name-to-address, then our applications and browsers will not access websites.
 
Back