No DNS with BT Home Hub 5a + OpenWRT + ZTE MF823 USB Stick

[Java Jive]

As previous posts and title, trying out different USB sticks in my spare
BTHH5a with OpenWRT 18.06.1, currently having some success with a ZTE
MF823, but can't get DNS to work.

The ZTE MF823 is an RNDIS type of USB 4g Stick, offering a connection
via an onboard DHCP in the 192.168.0.1 range. When used with a Windows
PC, the onboard CD-ROM image installs a Windows service called
ZDServ.exe and the configuration 'program' actually just launches the
default browser, in my case Pale Moon, with a new tab showing the
onboard configuration pages at 192.168.0.1. In addition, the links
below show that also there is a telnet port at the same address.
Further information is available online, but is often mutually
contradictory - these are the three I've found most useful so far:

OpenWRT - Use RNDIS USB Dongle for WAN connection
https://openwrt.org/docs/guide-user/network/wan/wwan/ethernetoverusb_rndis

Guide to ZTE MF 823 USB dongles with OpenWrt and Gargoyle Routers
https://www.tbdproductions.com.au/telstra4gzte823/

Inside the ZTE MF823 4G Dongle
https://www.development-cycle.com/2017/04/27/zte-mf823-inside/

The main problems I would be grateful for help with are:

1) There is no DNS (note the rather odd IPv6 fragment).

C:\TEMP>ping www.macfh.co.uk

Pinging www.macfh.co.uk [64:ff9b::d9a0:21] with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 64:ff9b::d9a0:21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\TEMP>ping 217.160.0.33 # IP4 of www.macfh.co.uk

Pinging 217.160.0.33 with 32 bytes of data:

Reply from 217.160.0.33: bytes=32 time=291ms TTL=51
Reply from 217.160.0.33: bytes=32 time=108ms TTL=51
Reply from 217.160.0.33: bytes=32 time=95ms TTL=51
Reply from 217.160.0.33: bytes=32 time=79ms TTL=51

Ping statistics for 217.160.0.33:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 79ms, Maximum = 291ms, Average = 143ms


2) How to enter the SIM pin code during boot so that the stick can start
automatically. What I'm currently having to do is log on to 198.162.0.1
from a browser on a PC and enter the pin and start the stick from there.

3) This 192.168.0.1 web control interface has no password to prevent
unauthorised access, though there is a note about that at the bottom of
the first link above.

Some diagnostic output too long to append to this is available here:
www.macfh.co.uk/Temp/ZTE_MF823.txt

[Java Jive]

On 19/08/2019 22:40, Java Jive wrote:
> As previous posts and title, trying out different USB sticks in my spare
> BTHH5a with OpenWRT 18.06.1, currently having some success with a ZTE
> MF823, but can't get DNS to work.

> [...]

> Some diagnostic output too long to append to this is available here:
>     www.macfh.co.uk/Temp/ZTE_MF823.txt

Getting the same thing now with an Alcatel IK40V.

[Andy Burns]

Java Jive wrote:

>> ZTE MF823, but can't get DNS to work.
>

> Getting the same thing now with an Alcatel IK40V.

ppp misconfiguration?

[Java Jive]

PPP is not involved. Both USB sticks are configured as ...
Protocol: DHCP Client
Physical device: usb0
Firewall: wan

[Andy Burns]

Java Jive wrote:

> Andy Burns wrote:
>
>> ppp misconfiguration?
>
> PPP is not involved.  Both USB sticks are configured as ...
>     Protocol:        DHCP Client
>     Physical device:    usb0
>     Firewall:        wan

I thought openWRThad some ppp flavour of dhcpclient that faked dhcp? I
remember sitting there and watching something send "dhcp requests" with
no reply while I was still getting my USB dongle to work ...

[Andy Burns]

Java Jive wrote:

> Some diagnostic output too long to append to this is available here:
> www.macfh.co.uk/Temp/ZTE_MF823.txt

Anything interesting from "logread -f" while bringing the 4G interface up?

[Java Jive]

The appended is what happens while bringing up the Alcatel IK40V.

Note: This USB stick defaults to being an IPv4 DHCP server at
192.168.1.1, the same as the default LAN range for the BTHH5a, which
means that the latter has to be reconfigured to another subnet for the
test, I'm using 192.168.100.1. * I've also tried setting the LAN
gateway to 192.168.1.1, and then also adding that as a DNS server, but
neither nor both changes made any difference.

* The ZTE MF823 more conveniently defaults to 192.168.0.1, so there is
no clash, but it's a black mark against both, and also a lot of modern
cameras that provide a WiFi hotspot, that you can't easily, if at all,
change the factory set range if, as inevitably will happen because they
default to a commonly used range, it happens to clash with your existing
LAN.

Curiously, some web pages already loaded previously in Pale Moon, such
as the OpenWRT ones, will reload successfully, while others time out and
fail. From a CMD prompt, all attempts to ping my own domain and the BBC
by name fail, only an IP works, but once the domain has been found by
IP, subsequent attempts to ping by name succeed.

root@Test:~# logread -f
Wed Aug 21 20:34:47 2019 daemon.notice netifd: Interface 'WAN_USB' is
enabled
Wed Aug 21 20:34:47 2019 daemon.notice netifd: Network device 'usb0'
link is up
Wed Aug 21 20:34:47 2019 daemon.notice netifd: Interface 'WAN_USB' has
link connectivity
Wed Aug 21 20:34:47 2019 daemon.notice netifd: Interface 'WAN_USB' is
setting up now
Wed Aug 21 20:34:47 2019 daemon.notice netifd: WAN_USB (3739): udhcpc:
started, v1.28.3
Wed Aug 21 20:34:47 2019 daemon.notice netifd: WAN_USB (3739): udhcpc:
sending discover
Wed Aug 21 20:34:50 2019 daemon.notice netifd: WAN_USB (3739): udhcpc:
sending discover
Wed Aug 21 20:34:50 2019 daemon.notice netifd: WAN_USB (3739): udhcpc:
sending select for 192.168.1.195
Wed Aug 21 20:34:50 2019 daemon.notice netifd: WAN_USB (3739): udhcpc:
lease of 192.168.1.195 obtained, lease time 7200
Wed Aug 21 20:34:50 2019 daemon.notice netifd: Interface 'WAN_USB' is now up
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: reading
/tmp/resolv.conf.auto
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain test
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain onion
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain localhost
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain local
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain invalid
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain bind
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using local
addresses only for domain lan
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using nameserver
192.168.1.1#53
Wed Aug 21 20:34:50 2019 daemon.info dnsmasq[2772]: using nameserver
192.168.1.1#53
Wed Aug 21 20:34:51 2019 user.notice firewall: Reloading firewall due to
ifup of WAN_USB (usb0)

[Java Jive]

New info ...

On 19/08/2019 22:40, Java Jive wrote:
>

> As previous posts and title, trying out different USB sticks in my spare
> BTHH5a with OpenWRT 18.06.1, currently having some success with a ZTE
> MF823, but can't get DNS to work.

[...]

> 1)    There is no DNS (note the rather odd IPv6 fragment).
>
> C:\TEMP>ping www.macfh.co.uk
>
> Pinging www.macfh.co.uk [64:ff9b::d9a0:21] with 32 bytes of data:
>
> Destination host unreachable.
> Destination host unreachable.
> Destination host unreachable.
> Destination host unreachable.
>
> Ping statistics for 64:ff9b::d9a0:21:
>     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

But there *is* within the OpenWRT console???!!!

root@Test:~# ping www.macfh.co.uk
PING www.macfh.co.uk (217.160.0.33): 56 data bytes
64 bytes from 217.160.0.33: seq=0 ttl=42 time=58.847 ms
64 bytes from 217.160.0.33: seq=1 ttl=42 time=83.693 ms
64 bytes from 217.160.0.33: seq=3 ttl=42 time=80.245 ms
[...]
--- www.macfh.co.uk ping statistics ---
8 packets transmitted, 7 packets received, 12% packet loss
round-trip min/avg/max = 58.847/77.808/87.780 ms

I've now tried ...
Alcatel IK40V USB Stick
ZTE MF823 USB Stick
USB tethering my Samsung SM-T719 Tablet
... and the result has been pretty much the same for all. DNS within
the OpenWRT unit itself, but it doesn't make its way out to clients.

> 2)    How to enter the SIM pin code during boot so that the stick can
> start automatically.  What I'm currently having to do is log on to
> 198.162.0.1 from a browser on a PC and enter the pin and start the stick
> from there.
>
> 3)    This 192.168.0.1 web control interface has no password to prevent
> unauthorised access, though there is a note about that at the bottom of
> the first link above.

I'm still struggling with particularly the first of these.

[Andy Burns]

Java Jive wrote:

> DNS within the OpenWRT unit itself, but it doesn't make its way out to
> clients.

firewall rule blocking port 53 from the 4G WAN's RFC1918 addr? I don't
think "rebind protection" should interfere with that.

[Java Jive]

I tried creating a test firewall rule for TCP+UDP to allow port 53 from
any zone to any zone, but I'm still getting the same results - only
domains that have previously been accessed directly via IP address, and
therefore are remembered by the PC's DNS cache, are accessible by name
from the PC. Domains that haven't been successfully found since the
last PC reboot aren't found:

C:\TEMP>ping bbc.co.uk

Pinging bbc.co.uk [2a04:4e42:600::81] with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 2a04:4e42:600::81:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\TEMP>ping6 bbc.co.uk

Pinging bbc.co.uk [2a04:4e42:400::81]
from fd67:c0c5:ae16:0:7c0d:d6f1:9a52:ddcc with 32 bytes of data:

Reply from fd67:c0c5:ae16:0:7c0d:d6f1:9a52:ddcc: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:7c0d:d6f1:9a52:ddcc: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:7c0d:d6f1:9a52:ddcc: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:7c0d:d6f1:9a52:ddcc: Destination address
unreachable.

Ping statistics for 2a04:4e42:400::81:

[Andy Burns]

Java Jive wrote:

> I tried creating a test firewall rule for TCP+UDP to allow port 53 from
> any zone to any zone, but I'm still getting the same results

If it were me, I'd crank up the firewall logging and/or use tcpdump, to
see what DNS requests/replies are doing on LAN and WAN interfaces ...

[Chris Green]

Java Jive <ja...@evij.com.invalid> wrote:
> only
> domains that have previously been accessed directly via IP address, and
> therefore are remembered by the PC's DNS cache, are accessible by name
> from the PC. Domains that haven't been successfully found since the
> last PC reboot aren't found:
>

Ay? That doesn't make sense to me. Why would the PC know the name of
a domain simply because you've used the numeric IP? It sounds to me
as if there's something strange going on here.

--
Chris Green
·

[Java Jive]

On 23/08/2019 09:12, Chris Green wrote:
> Java Jive <ja...@evij.com.invalid> wrote:
>> only
>> domains that have previously been accessed directly via IP address, and
>> therefore are remembered by the PC's DNS cache, are accessible by name
>> from the PC. Domains that haven't been successfully found since the
>> last PC reboot aren't found:
>>
> Ay? That doesn't make sense to me. Why would the PC know the name of
> a domain simply because you've used the numeric IP?

I think Windows PCs have a DNS cache. On the XP test PC, there's the
following service running:

DNS Client

Resolves and caches Domain Name System names for this computer. If this
service is stopped, this computer will not be able to resolve DNS names
and locate Active Directory domain controllers. If this service is
disabled, any services that explicitly depend on it will fail to start.

C:\WINNT\system32\svchost.exe -k NetworkService

Automatic

Started

> It sounds to me
> as if there's something strange going on here.

That may well be so! Certainly, I'm struggling with it. I'll have to
try Andy's suggestion next.

[Chris Green]

Java Jive <ja...@evij.com.invalid> wrote:
> On 23/08/2019 09:12, Chris Green wrote:
> > Java Jive <ja...@evij.com.invalid> wrote:
> >> only
> >> domains that have previously been accessed directly via IP address, and
> >> therefore are remembered by the PC's DNS cache, are accessible by name
> >> from the PC. Domains that haven't been successfully found since the
> >> last PC reboot aren't found:
> >>
> > Ay? That doesn't make sense to me. Why would the PC know the name of
> > a domain simply because you've used the numeric IP?
>
> I think Windows PCs have a DNS cache. On the XP test PC, there's the
> following service running:
>

Yes, but that still doesn't explain how the PC finds out the name for
the numeric IP. A cache simply saves DNS look-ups that have been done
already.

--
Chris Green
·

[Peter]

I am not sure your diagnosis of the problem is quite correct. You say
that DNS is not working, but the example you gave was:

C:\TEMP>ping www.macfh.co.uk

Pinging www.macfh.co.uk [64:ff9b::d9a0:21] with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 64:ff9b::d9a0:21:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

In this case DNS IS working, but your PC is using the returned IPv6
address, rather than your expected IPv4 one.

If you try
ping www.macfh.co.uk -4
does that force use of the IPv4 address?

Another thing to look at is how DNS resolution is working - using
nslookup www.macfh.co.uk

If that works then your problem is not a failure of DNS, but the fact
that your PC is trying to use IPv6, which presumably does not route over
your network. You could try unbinding IPv6.

I think you say you are using XP, I don't have any XP to check against
so my comments may be wrong.

[Martin Nicholas]

On Fri, 23 Aug 2019 14:07:04 +0100
Peter <ne...@psmason.plus.net.nospam> wrote:

> I think you say you are using XP, I don't have any XP to check
> against so my comments may be wrong.

XP used to cache DNS results for 24-hrs. regardless of any TTL unless
you switched it off (and thus got it to work properly). How long it
caches a NXDOMAIN for, I don't know.

ping 8.8.8.8 should always work, unless someone is blocking ping
packets.

--
Regards,

Martin Nicholas.

E-mail: reply-...@mgn.org.uk (Address will be valid throughout
August).

The Usenet: Proof that social media didn't begin in 2006.

[Java Jive]

On 23/08/2019 14:07, Peter wrote:
>
> If you try
> ping www.macfh.co.uk -4
> does that force use of the IPv4 address?

Now that's very interesting, yes! This from a cold boot, rather than a
hibernation ...

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\TEMP>ipconfig /all
[...]
Ethernet adapter Local Area Connection (Wired):

Connection-specific DNS Suffix . : lan
Description . . . . . . . . . . . : Broadcom NetXtreme 57xx
Gigabit Controller
Physical Address. . . . . . . . . : 00-11-43-44-FE-DA
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.16
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . :
fd67:c0c5:ae16:0:155b:ef07:b40:943e
IP Address. . . . . . . . . . . . :
fd67:c0c5:ae16:0:211:43ff:fe44:feda
IP Address. . . . . . . . . . . . : fe80::211:43ff:fe44:feda%4
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Lease Obtained. . . . . . . . . . : 23 August 2019 15:50:38
Lease Expires . . . . . . . . . . : 24 August 2019 15:50:38
[...]

C:\TEMP>ping -4 www.macfh.co.uk

Pinging www.macfh.co.uk [217.160.0.33] with 32 bytes of data:

Reply from 217.160.0.33: bytes=32 time=64ms TTL=51
Reply from 217.160.0.33: bytes=32 time=112ms TTL=51
Reply from 217.160.0.33: bytes=32 time=112ms TTL=51
Reply from 217.160.0.33: bytes=32 time=136ms TTL=51

Ping statistics for 217.160.0.33:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:

Minimum = 64ms, Maximum = 136ms, Average = 106ms

C:\TEMP>ping www.macfh.co.uk

Pinging www.macfh.co.uk [64:ff9b::d9a0:21] with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 64:ff9b::d9a0:21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\TEMP>ping6 www.macfh.co.uk

Pinging www.macfh.co.uk [64:ff9b::d9a0:21]

from fd67:c0c5:ae16:0:155b:ef07:b40:943e with 32 bytes of data:

Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address

unreachable.

Ping statistics for 64:ff9b::d9a0:21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\TEMP>ping -4 www.bbc.co.uk

Pinging www.bbc.net.uk [212.58.249.212] with 32 bytes of data:

Reply from 212.58.249.212: bytes=32 time=34ms TTL=50
Reply from 212.58.249.212: bytes=32 time=43ms TTL=50
Reply from 212.58.249.212: bytes=32 time=43ms TTL=50
Reply from 212.58.249.212: bytes=32 time=100ms TTL=50

Ping statistics for 212.58.249.212:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:

Minimum = 34ms, Maximum = 100ms, Average = 55ms

C:\TEMP>ping www.bbc.co.uk

Pinging www.bbc.net.uk [64:ff9b::d43a:f446] with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 64:ff9b::d43a:f446:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\TEMP>ping6 www.bbc.co.uk

Pinging www.bbc.net.uk [64:ff9b::d43a:f9d4]
from fd67:c0c5:ae16:0:155b:ef07:b40:943e with 32 bytes of data:

Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.
Reply from fd67:c0c5:ae16:0:155b:ef07:b40:943e: Destination address
unreachable.

Ping statistics for 64:ff9b::d43a:f9d4:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

So, it looks like a problem particularly with IPv6.

> Another thing to look at is how DNS resolution is working - using
> nslookup www.macfh.co.uk

C:\TEMP>nslookup www.macfh.co.uk
Server: MacFH-HH5a.lan
Address: 192.168.1.1

Non-authoritative answer:
Name: www.macfh.co.uk
Address: 217.160.0.33

By constrast, this W7 64-bit PC connected to the live rather than the
test router, where DNS-or-related problem is not occurring, gives:

C:\TEMP>nslookup www.macfh.co.uk
Server: MacFH-HH5a.lan
Address: fd67:c0c5:ae16::1

Non-authoritative answer:
Name: www.macfh.co.uk
Address: 217.160.0.33

> If that works then your problem is not a failure of DNS, but the fact
> that your PC is trying to use IPv6, which presumably does not route over
> your network.  You could try unbinding IPv6.

I could, but I'd rather fix whatever the problem with IPv6 is.

> I think you say you are using XP, I don't have any XP to check against
> so my comments may be wrong.

So far, they've been spot on! Many thanks!

I'll look into Andy's logging suggestion next.

[Andy Burns]

Java Jive wrote:

> I think Windows PCs have a DNS cache.

It does, and you can clear it with "ipconfig /flushdns" for testing, but
what Chris was getting at is that just because you've done

ping 212.58.244.68

and got replies from it which happens to be an/the IP addr for
www.bbc.co.uk, that is of no help to Windows in doing

ping www.bbc.co.uk

because the entry can't be cached after the first ping beause it wasn't
looked up by name to start with.

[Andy Burns]

Java Jive wrote:

> I'd rather fix whatever the problem with IPv6 is.

Is the 4G dongle giving you an IPv6 WAN address?

[Peter]

So, to add to the DNS confusion

From your W7 computer , it looks like you are using IPv6 to reach the
DNS server, and getting back an IPv4 address.

From your XP computer you seem to be getting back the IPv6 address for
your server. But this is not a normal IPv6 address, it looks like a
NAT64 address 64:ff9b::217.160.0.33 (d9a0:0021 is 217.160.0.33)

So you seem to have something doing NAT64. Or your DNS server is
responding to DNS AAAA requests using DNS64. See
https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

Hope this helps ;-)

[Java Jive]

Yes, as per my original log file:

root@Test:~# ifconfig
[...]
usb0 Link encap:Ethernet HWaddr 86:F6:2F:1D:EF:C6
inet addr:192.168.0.121 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::84f6:2fff:fe1d:efc6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28754 errors:2 dropped:0 overruns:0 frame:2
TX packets:27740 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6692914 (6.3 MiB) TX bytes:6701052 (6.3 MiB)
[...]

[Andy Burns]

Java Jive wrote:

> Andy Burns wrote:
>

>> Is the 4G dongle giving you an IPv6 WAN address?
>
> Yes, as per my original log file:

but it's only a link-local address, you could disable that in the
openWRT config, I have started to see SIMs that give an actual IPv6
address instead of IPv4.

[Java Jive]

Now, after a day or so's research, I'm more up to the mark on IPv6,
which was something that I've meaning to get around to, but never had
both the motive and time together.

This research led me to the following site ...
https://test-ipv6.com/
... where I score 0/10 in IPv6 readiness! As far as I have been able to
tell so far, this seems to be because EE are not offering IPv6 on their
connections, certainly none of the USB sticks that I've investigated
have been given any routable ones - as Andy suggests, the only ones
I've found have been Link Local.

I've found a workaround for now, in disabling DHCPv6 on the LAN, and
this has enabled me to reconfigure the main router to drive the ZTE
MF823, which is *slightly* slower, around 19-20Mbps as opposed to 25Mbps
for the Huawei E3372s *when* actually it could be arsed to work! It's
not been up for long, but the signs so far suggest that the connection
is more reliable, which is much more important to me than a slight loss
of speed.

As to why the E3372s had started playing up after being rock solid for
several months, I'm not really sure, but I had noticed that it seemed
rather warm.

Hopefully problem solved, so many thanks to all for the many helpful
comments here, particularly Peter and Andy.