After a couple of hours of trying, I finally got Tier 1 support to add the current situation to the current ticket. I did have to change the ticket number because they closed the original one without telling us, so that was great. And then they opened two others, one for tier 1 and tier 2. But in theory, this is on the tier 2 ticket now. Yay!
That's nearly two hours to get this text added to a ticket though. Jesus.
-----
The modem is not passing IPv4 packets across LAN to WAN. It _may_ be able to send IPv4 packets from _itself_ to the WAN, and it _can_ pass IPv4 packets from itself to the LAN, but it DOES NOT pass IPv4 packets _across_ LAN to WAN or (as far as I can tell) vice versa.
A simple test is using my laptop connected by wire directly to the modem, configured by the modem's DHCP. If I attempt to query your nameserver via IPv4 from this laptop, it _always_ fails. If I attempt to query your nameserver via IPv6 from this same laptop, it _always_ succeeds. See attached screencap.
The reason I believe the modem can talk IPv4 over the WAN is because if I use the built-in IPv4 ping functionality via the web interface, it reports success. Since it does so without details, I cannot be sure it's actually succeeding, as the administrative software is unreliable. But I suspect it's working.
However, any otherwise-identical attempt from the LAN side of the modem to use IPv4 pings to the same servers fail, 100% of the time.
The modem is showing other signs of IPv4 routing irregularities. I will describe one now:
If a laptop is connected to the LAN side of the modem with modem-issued DHCP address, pinging our fixed-IP machines on the same (LAN) side of the modem will sometimes work normally, sometimes succeed with great delay in ping issuance but _not_ response time, sometimes succeed with routing error complaints on some but not necessarily all packets, and sometimes (but rarely) fail outright, all within a few minutes of each other with no configuration changes.
The modem is showing other signs of irregular behaviour as well. I will describe the main one now:
The modem is sometimes refusing logins when given valid login credentials. If your support team resets the password to default, the default password will also not work, regardless of the number of resets.
I have discovered today that if one is attempting to login via the fixed IP (173.160.243.46) and it does not work, it will _probably_ work if one does exactly the same login attempt on the DHCP root address (10.1.10.1).
The same is also true in reverse. If login via the DHCP root address (10.1.10.1) is failing, trying exactly the same login via the fixed IP (173.160.243.46) will _probably_ work.
If there is a reasonable explanation for this behaviour other than modem failure, I am not seeing it.
For these and other reasons, I am strongly suspecting that the modem is not taking provisioning properly, regardless of what it is reporting. The only reprovisioning from your side that I have seen have any effect at all is a full factory reset from remote. (My attempt to do a factory reset via the front panel failed - as in, didn't seem to work at all - and as this was when it was refusing all logins, I could not try via the customer administrative access panels.)
At this point we are down for just short of 24 hours and we yet again request escalation to Tier 2. Tier 1 have demonstrated yet again that they are NOT CAPABLE of solving this problem, and this is our fourth major network outage caused by your side since October, all previous lasting between 2 and 5 days, this one so far only 1 day.
The ticket number, again, is [deleted]. Please add all of the above to the ticket. Thank you.
Also posted to
ソ-ラ-バ-ド-のおん;
comments at Dreamwidth. Please comment there.