TekSavvy or Rogers blocking apt user agent
Well this is a new low: https://askubuntu.com/questions/1185612/apt-get-stuck-on-waiting-for-headers... Mind-boggling that it is/was even an issue at an ISP & HTTP level. Either they have a giant whitelist of browser agents to maintain, or a blacklist to update and added apt to it. In either case, they're looking at HTTP traffic and acting on it directly. Still an issue for anyone? Jamon
What does Wireshark show? That article shows "Connection reset by peer". On 2019-11-04 04:13 PM, Jamon Camisso via talk wrote:
Well this is a new low:
https://askubuntu.com/questions/1185612/apt-get-stuck-on-waiting-for-headers...
Mind-boggling that it is/was even an issue at an ISP & HTTP level.
Either they have a giant whitelist of browser agents to maintain, or a blacklist to update and added apt to it.
In either case, they're looking at HTTP traffic and acting on it directly.
Still an issue for anyone?
Jamon --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
| From: Jamon Camisso via talk <talk@gtalug.org> | Well this is a new low: | | https://askubuntu.com/questions/1185612/apt-get-stuck-on-waiting-for-headers... | | Mind-boggling that it is/was even an issue at an ISP & HTTP level. | | Either they have a giant whitelist of browser agents to maintain, or a | blacklist to update and added apt to it. | | In either case, they're looking at HTTP traffic and acting on it directly. | | Still an issue for anyone? Is this happening to you? I will assume so. - my main internet connection is directly through Rogers. - I use Ubuntu infrequently. - when I do update it, I have had no issue. Most recently: a couple of days ago. The ip address in the wireshark log is 91.189.91.23 (AKA economy.canonical.com). When I point (Fedora) firefox at it, it claims that it cannot connect to a web server there. Of course that's with Firefox's User Agent String. ping does get responses. Could it be that you are somehow trying to use a mirror that has been decommissioned? I think that this problem is likely unintended and would be fixed if 1) the problem would be with your ISP 2) it were reported and 3) teksavvy could reproduce it.
On 04/11/2019 21:24, D. Hugh Redelmeier via talk wrote:
Is this happening to you? I will assume so.
- my main internet connection is directly through Rogers.
- I use Ubuntu infrequently.
- when I do update it, I have had no issue. Most recently: a couple of days ago.
The ip address in the wireshark log is 91.189.91.23 (AKA economy.canonical.com). When I point (Fedora) firefox at it, it claims that it cannot connect to a web server there. Of course that's with Firefox's User Agent String. ping does get responses.
Teksavvy have done something on their end: https://twitter.com/TekSavvyCSR/status/1191486635764068355
On Mon, 4 Nov 2019 at 21:27, Jamon Camisso via talk <talk@gtalug.org> wrote:
On 04/11/2019 21:24, D. Hugh Redelmeier via talk wrote:
Is this happening to you? I will assume so.
- my main internet connection is directly through Rogers.
- I use Ubuntu infrequently.
- when I do update it, I have had no issue. Most recently: a couple of days ago.
The ip address in the wireshark log is 91.189.91.23 (AKA economy.canonical.com). When I point (Fedora) firefox at it, it claims that it cannot connect to a web server there. Of course that's with Firefox's User Agent String. ping does get responses.
Teksavvy have done something on their end:
Wouldn't it be great if they said WHAT had caused it rather than just "we fixed it?" If you told us the how, we might have more faith that you wouldn't do it again. But more and more, technical support departments are hiding these outcomes - either to disguise what they think could be regarded as incompetence or because they're afraid it might reveal secrets about their processes or infrastructure. Both have some validity. Having been in the position myself [1], I get that it's not appealing to reveal the process and problems discovered, but I'm still a believer in transparency. [1] I'm in "Operations," here's just one example. We upgraded Debian on a back end server which in turn broke Chrome 49 - but it took over a week to figure out that HAProxy was the reason for the Chrome 49 breakage. We then upgraded HAProxy again (to Debian backports) which fixed Chrome 49. Yes, we still have to support that. And this has led to a big dispute at work about whether we should be notifying people and on what level of upgrade ... You get the idea. -- Giles https://www.gilesorr.com/ gilesorr@gmail.com
On 2019-11-05 12:13 p.m., Giles Orr via talk wrote: Teksavvy have done something on their end: https://twitter.com/TekSavvyCSR/status/1191486635764068355 Wouldn't it be great if they said WHAT had caused it rather than just "we fixed it?" If you told us the how, we might have more faith that you wouldn't do it again. But more and more, technical support departments are hiding these outcomes - either to disguise what they think could be regarded as incompetence or because they're afraid it might reveal secrets about their processes or infrastructure. Having owned a customer support team in the past (Interleaf), they had a mission from management to "make you happy with what you have", and to close tickets as soon as possible. Less than good. Even more extreme was Honeywell, who only allowed staff to file bugs if we had our director's written approval. Tek Savvy is still relatively small and non-stupid, so customers can probably escalate and get a response. I'd call by voice, write down the person's name when they answer, and when they say "no", ask to speak to their escalations manager (Ie, the equivalent of me, but for Tek). When you're connected, thank the manager for the good service that <name of rep> provided, but ask for the thing they couldn't provide. Say why it is to Tek's advantage to provide it and make you, their customer, happy with the company. And they're in Chatham, where I grew up, and Chathamites were and still are really nice to one another. Very Canadian. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
On 2019-11-06 11:55 AM, Dave Collier-Brown via talk wrote:
Having owned a customer support team in the past (Interleaf), they had a mission from management to "make you happy with what you have", and to close tickets as soon as possible. Less than good.
Having worked in the telecom and networking fields for years, I can say there's a big difference between companies. In my experience, Rogers performs much better than Bell. Bell tends to be bad, I suspect, because they moved their help(?) desk to India. On one occasion, I was connecting a router to an ADSL line and was having issues. I called Bell and was told to click on the start button! Last I checked, routers don't have a start button. When I asked to escalate, the person I was talking to refused and then hung up. This was for a business customer!!! On the other hand, I've never had a problem escalating with Rogers. In another example, I was working with a certain company's equipment. After that company was bought by another, their support suddenly became more of problem, rather than a solution. It was hard to get them on the phone and harder to get them to actually do anything. Bottom line, a lot depends on the companies involved. Some provide decent support and some don't.
On Wed, 6 Nov 2019 at 11:55, Dave Collier-Brown via talk <talk@gtalug.org> wrote:
Tek Savvy is still relatively small and non-stupid, so customers can probably escalate and get a response. I'd call by voice, write down the person's name when they answer, and when they say "no", ask to speak to their escalations manager (Ie, the equivalent of me, but for Tek). When you're connected, thank the manager for the good service that <name of rep> provided, but ask for the thing they couldn't provide. Say why it is to Tek's advantage to provide it and make you, their customer, happy with the company.
And they're in Chatham, where I grew up, and Chathamites were and still are really nice to one another. Very Canadian.
https://www.dslreports.com/forum/teksavdirect is what brings me to TekSavvy's second tier support straight away. They often respond within minutes and in my experience, they have been incredibly helpful.
On 2019-11-05 12:13 p.m., Giles Orr via talk wrote:
Wouldn't it be great if they said WHAT had caused it rather than just "we fixed it?"
That might've been what Teksavvy got from Rogers. Or at least, what the person on Teksavvy's technical social media account heard. They've come on a bit from when I first started using them in 2006 when it was Rocky Gaudrault who'd set up your account over the phone and Rocky's sister who handled the payments. Technical support was a cell phone number in Hamilton, and the guy would come out anywhere in the GTHA to help. I never had the apt problem on Teksavvy via Bell DSL. cheers, Stewart
I've seen this before on a fortigate firewall. The FW will detect "apt" as app:XMLRPC rather than app:HTTP for the purposes of "Application Detection" and if the "allow port 80 rules" is infact an "Allow only app:HTTP on port 80" rule , then XMLRPC over port 80 is disallowed. David On Mon, Nov 4, 2019 at 4:13 PM Jamon Camisso via talk <talk@gtalug.org> wrote:
Well this is a new low:
https://askubuntu.com/questions/1185612/apt-get-stuck-on-waiting-for-headers...
Mind-boggling that it is/was even an issue at an ISP & HTTP level.
Either they have a giant whitelist of browser agents to maintain, or a blacklist to update and added apt to it.
In either case, they're looking at HTTP traffic and acting on it directly.
Still an issue for anyone?
Jamon --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- David Thornton https://wiki.quadratic.net https://github.com/drthornt/ https://twitter.com/northdot9/
participants (8)
-
D. Hugh Redelmeier -
Dave Collier-Brown -
David Thornton -
Giles Orr -
James Knott -
Jamon Camisso -
Stewart C. Russell -
Val Kulkov