Losing 10-80% of packets

[ryanoneill1970]

We are VERY rural (no landline or non EE signal) and the 4GEE broadband has become very slow of late. In checking it out it seems that packets are being dropped sporadically once they leave the 4GEE router. Last night it was getting to 80% packet loss on a ping of bbc.co.uk. Right now it's reporting 40% loss (see below).

I'm pretty good with networking and computers so I'm fairly certain it is a problem on the outside of the network, probably the bandwidth utilisation on the mast itself. How can I troubleshoot further?

How do I raise this with EE? I'm unable to call as my voice line goes over the 4GEE device which due to the packet loss is extremely garbled. The option to start a live chat from https://ee.co.uk/contact-ee/technical-support/mobile-broadband does not appear on 3 different browsers or on my mobile (it is currently within working hours according to that page).

Thanks in advance,

Ryan

Ping from firewall (direct connection to router);

PING bbc.co.uk (151.101.128.81): 56 data bytes
64 bytes from 151.101.128.81: icmp_seq=0 ttl=53 time=88.423 ms
64 bytes from 151.101.128.81: icmp_seq=2 ttl=53 time=93.612 ms
64 bytes from 151.101.128.81: icmp_seq=3 ttl=53 time=82.313 ms
64 bytes from 151.101.128.81: icmp_seq=4 ttl=53 time=86.131 ms
64 bytes from 151.101.128.81: icmp_seq=8 ttl=53 time=82.805 ms
64 bytes from 151.101.128.81: icmp_seq=9 ttl=53 time=95.034 ms

--- bbc.co.uk ping statistics ---
10 packets transmitted, 6 packets received, 40.0% packet loss
round-trip min/avg/max/stddev = 82.313/88.053/95.034/4.898 ms

Tracert from my desktop (10.1.1.1 is LAN side of the 4GEE, 192.168.225.1 is the WAN side of that device);

Tracing route to bbc.co.uk [151.101.64.81]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms firewall.localdomain [192.168.1.1]
                                  2 <1 ms <1 ms    <1 ms  10.1.1.1
  3     2 ms     3 ms     2 ms  MDM9640 [192.168.225.1]
  4     *        *        *     Request timed out.
  5    89 ms    87 ms     *     10.248.28.233
  6    92 ms    84 ms    82 ms  10.247.86.27
  7     *        *        *     Request timed out.
  8    86 ms    95 ms     *     10.247.86.9
  9    87 ms    81 ms    59 ms  10.247.86.18
 10     *       85 ms     *     87.237.20.232
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13    89 ms    87 ms    85 ms  151.101.64.81
                            

[mikeliuk]

Hi @ryanoneill1970 ,

Are you able to find the SINR/SNR parameter using online sources to help with your particular model?

I highly recommend moving off 10.0.0.0/8 for any device which must connect to the service provider's network as EE sometimes assigns IPs in this subnet to customer WANs.

I think it's unlikely that 192.168.225.1 would be the IP of the WAN sitting on EE's network.

I recommend to remove or disconnect any 10.0.0.0/8 subnet and try again with a network assigned IP on the WAN which should not be a private address from any smaller subnet.

[ryanoneill1970]

Hi @mikeliuk ,

Thanks for helping.

I've managed to get some data out of the unit using Chrome dev tools, it is reporting back an SINR value of 2. I have no idea what this means. The full JSON response is below. On the unit we only get 1 LED for signal strength but that's always been the case, we can get up to 60mbps sometimes. We use an external Panorama aerial, fitted by EE.

I can certainly change the IP ranges but I really would rather not move anything just yet as most packets get through and I'm worried about compounding issues if I change too much at once. I think if it was a routing issue then we would not get any data through at all. I understand what you say about the 10.x range being used by EE internally, at the moment we are on different subnets.

{
  "jsonrpc": "2.0",
  "result": {
    "PLMN": "23430",
    "NetworkType": 8,
    "NetworkName": "EE",
    "SpnName": "EE",
    "LAC": "0",
    "CellId": "4372992",
    "RncId": "reserved",
    "Roaming": 1,
    "Domestic_Roaming": 1,
    "SignalStrength": 1,
    "mcc": "234",
    "mnc": "30",
    "SINR": "2",
    "RSRP": "-107",
    "RSSI": "-76",
    "eNBID": "17082",
    "CGI": "2343042ba00",
    "CenterFreq": "0.000000",
    "TxPWR": "0",
    "LTE_state": 105971712,
    "PLMN_name": "",
    "Band": 122,
    "DL_channel": "reserved",
    "UL_channel": "reserved",
    "RSRQ": "-10",
    "EcIo": 0.0,
    "RSCP": -1
  },
  "id": "12"
}

[mikeliuk]

Hi @ryanoneill1970 ,

SINR of 2 is not great but I don't feel it fully accounts for the extent of the packet loss.

I think it's just a case of checking one thing at a time to isolate the root cause.

Things to check would include error counters on routers, behaviour in a phone or other device, taking the external antenna and thus linking cable out of the equation etc.

I feel it's worth considering the network configuration as hops 1 to 3 seemed to be bouncing between subnets which doesn't seem normal. If it's not an issue of configuration, something may be faulty (e.g. device, port, or cable).

https://usatcorp.com/faqs/understanding-lte-signal-strength-values/

Pinging 8.8.8.8 or 1.1.1.1 should be a slightly better test as DNS are typically used to monitor links (not content webservers).

[ryanoneill1970 · Accepted solution]

It seems the mast I was pointed at by the EE subcontractor was not the closest and has become fairly busy of late. I used cellmapper.net to locate a nearer mast and the packet loss has almost disappeared (1 in 100 maybe), download increased to 50mbps and ping is around 30ms!

I'll be fixing the new antennae orientation properly tomorrow. Thanks for your help.

FYI, the updated stats are below;

{
  "jsonrpc": "2.0",
  "result": {
    "PLMN": "23430",
    "NetworkType": 8,
    "NetworkName": "EE",
    "SpnName": "EE",
    "LAC": "0",
    "CellId": "5673216",
    "RncId": "reserved",
    "Roaming": 1,
    "Domestic_Roaming": 1,
    "SignalStrength": 1,
    "mcc": "234",
    "mnc": "30",
    "SINR": "5",
    "RSRP": "-112",
    "RSSI": "-78",
    "eNBID": "22161",
    "CGI": "23430569100",
    "CenterFreq": "0.000000",
    "TxPWR": "0",
    "LTE_state": 105971712,
    "PLMN_name": "",
    "Band": 122,
    "DL_channel": "reserved",
    "UL_channel": "reserved",
    "RSRQ": "-15",
    "EcIo": 0.0,
    "RSCP": -1
  },
  "id": "12"
}

[mikeliuk]

Great news!

If cellmapper shows a few base stations scattered and not a single obviously best one, an omni-directional antenna may be less trouble (congestion can move around during the day).

Your quoted numbers are slightly better than my usual numbers near a town centre within the M25. Typically I see 30 ms and around 35 Mbps.

At 0400 I've seen 130 Mbps down measured by fast.com and speedtest.net reports as low as 22 ms but this is rare.