We have also managed to confirm the issue on a BT Retail FTTC (fixed IP) line as well. It is very specific, and relates to PPPoE over an FTTC link, where recent IP/port combinations stop working after a PPPoE reconnect, but start if the Ethernet port is disconnected and reconnected.
We had several engineers at our offices working with us today, and engineers from BT at the exchange and Huawei in China on the phone as well. After several hours working with Paul we can confirm that they have managed to identify the problem and reproduce it in their labs.
Now we wait for a fix to be released and rolled out - no idea on timescales yet. We'll keep a close eye on it.
Once again, with all the ISPs and all the FTTCs lines in the country, it is A&A that are leading the way identifying issues like this and working with BT to resolve them. We are very pleased that it is actually taken seriously by both BT and Huawei.
Thanks to the customers who reported the issue and helped us pin it down, and well done to Paul in our offices for diligently identifying the issue and working with BT and Huawei to help them find the cause.
Well done all at AA for this work.
ReplyDeleteDid you get any more technical details on what is causing it (particular byte sequences getting corrupted?) or just "ah yes, we're losing packets on our test system in the lab too, so we'll take it from here"?
ReplyDeleteI'm very impressed with A&A so far - my three complaints with my previous ISP were all fixed just by switching (throughput just over half the sync speed, at all times; no reverse-DNS entries for my IPv6 addresses; no usage information for a long time, though they did get a workaround for that in the end). Pretty much what I expected from reading of the "BT eating IPv6 packets" saga in the past, but great to experience first-hand.
I have recently found that the same issue has been affecting my IAX traffic, between my local Asterisk server and an Asterisk server out on the internet. The asterisk log reports toggling between REACHABLE and UNREACHABLE every minute or two. As reported in the original description, this started at the same time as a PPP restart, and continued until I briefly disconnected the ethernet on the FTTC modem.
ReplyDeleteSo, has there been any progress on the issue? Thanks!
Great, but I assume they won't care to comment on why an Ethernet bridge would hold state on UDP packets encapsulated in a PPP frame?
ReplyDeleteQuite!
DeletePerhaps the Chinese Security Services want Huawei to block VPNs...
Delete