lgeek
CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.
If you see high packet rate from a specific IP address or prefix, it's very likely not them abusing your service, but rather you attacking them by responding to spoofed requests.
Not associated with Meta, but this piqued my interest. That being said, I found some parts confusing and hard to follow. For example what does URPF (Unicast Reverse Path Forwarding) in the title of this submission have to do with the contents?
And is the packet loss supposedly happening at specific times only? It's not mentioned anywhere, but one screenshot highlights the time. I couldn't reproduce the packet loss using any of the looking glasses and dest IP addresses in the screenshots. At this point, if this was a report I had received about one of my services, I would have probably bumped down the priority to low and asked for a reproducible test, because in my experience even issues that affect a single path in an ECMP group are not this hard to reproduce. I think it's way more important to give the engineer who will process the report an easy way to check that there is indeed a problem than to start to teach how traceroute works.
TBF, there does seem to be an issue somewhere, because sticking 129.134.80.234, one of the Meta IP addresses from a screenshot, on ping.pe does definitely show significant packet loss from more locations than you'd expect to see for an address with no connectivity issues.
* not all cameras being available
* stabilisation not working
* 60 FPS unavailable
DataPacket has a very large network though and is kind of, sort of EU-based. AFAIK most operations are in Czechia, but the company is registered in UK. And there's also the Luxembourg-based Gcore.
VNPT is a residential / mobile ISP, but they also run datacentres (e.g. [1]) and offer VPS, dedicated server rentals, etc. Most companies would use separate ASes for residential vs hosting use, but I guess they don't, which would make them very attractive to someone deploying crawlers.
And Bunny Communications (AS5065) is a pretty obvious 'residential' VPN / proxy provider trying to trick IP geolocation / reputation providers. Just look at the website [2], it's very low effort. They have a page literally called 'Sample page' up and the 'Blog' is all placeholder text, e.g. 'The Art of Drawing Readers In: Your attractive post title goes here'.
Another hint is that some of their upstreams are server-hosting companies rather than transit providers that a consumer ISP would use [3].
[1] https://vnpt.vn/doanh-nghiep/tu-van/vnpt-idc-data-center-gia... [2] https://bunnycommunications.com/ [3] https://bgp.tools/as/5065#upstreams
If you're just renting servers instead, you have a few options that are effectively closer to a 1% commit, but better have a plan B for when your upstreams drop you if the incoming attack traffic starts disrupting other customers - see Neoprotect having to shut down their service last month.
Insofar as it makes a difference for DDoS mitigation, the scarcity of IPv4 is more of a feature than a bug.
Almost all of the DDoS mitigation providers have been struggling for a few weeks because they just don't have enough edge capacity.
And normal hosting companies that are not focused on DDoS mitigation also seem to have had issues, but with less impact to other customers as they'll just blackhole addresses under larger attacks. For example, I've seen all connections to / from some of my services at Hetzner time out way more frequently than usual, and some at OVH too. Then one of my smaller hosting providers got hit with an attack of at least 1 Tbps which saturated a bunch of their transit links.
Cloudflare and maybe a couple of the other enterprise providers (Gcore?) operate at a large enough scale to handle these attacks, but all the smaller ones (who tend to have more affordable rates and more application-specific filters for sensitive applications that can't deal with much leakage) seem to be in quite a bad spot right now. Cloudflare Magic Transit pricing supposedly starts at around $4k / month, and it would really suck if that became the floor for being able to run a non-HTTP service online.
Something like Team Cymru's UTRS service (with Flowspec support) could potentially help to mitigate attacks at the source, but residential ISPs and maybe the T1s would need to join it, and I don't see that happening anytime soon.
My infrastructure is redundant and spread out among hosting providers and DCs so there's no real impact, but I'm pretty sure this is the longest outage I've ever had with any provider. And the communication level has been so dissapointing. 4 hrs to say it's a power / HVAC issue? Updates that basically just say we're still working on it since then.
I had to do a double take here. I run (mostly using dedicated servers) infrastructure that handles a few hundred TB of traffic per month, and my traffic costs are on the order of $0.50 to $3 per TB (mostly depending on the geographical location). AWS egress costs are just nuts.
But I believe in the past Bolt used to be cheaper than Uber indeed.
Or reconfigure U-Boot to load extlinux.conf (and the kernel image, initrd, etc) entirely from other type of media. IIRC NVMe, USB and external SDs are all supported
It's not a stalemate, they're still getting new cases at a pace that allows their medical system to cope.
> In the absence of a vaccine
It's a pretty safe bet one will become available pretty soon. Meanwhile, more is being learned about how to handle infections and improve the outcome.
> the aim is to flatten the curve but still get the whole thing over and done with in about 6 months
There are 4000 ICU beds in the country in total, most of which will be in use due to other kind of cases at any one time. [1] But let's assume you can make that number available for coronavirus patients for 6 months. So you have 4k*26 = 104k ICU bed-weeks available. There's been talk of 60% of the population getting infected to build up herd immunity [2] (somehow ignoring that there seems to be a nontrivial reinfection rate [3]), so almost 40 million people. It's not very clear how many infected people end up needing intensive care. In Italy, it was 10% of the people who tested positive [4]. But only the worst cases get tested once the epidemic is widespread, so let's say maybe 0.5% of the infected people need ICU (wild guess here since no country with a large number of infections is testing people with mild symptoms, but I think I'm being conservative). 0.5% of 40 million is 200k patients. If each of them need an ICU bed for 2 weeks, that's 400k bed-weeks.
Basically we're talking about most of the 6 months period of the NHS being overwhelmed and coronavirus having a high mortality rate.
[1] https://www.bbc.com/news/health-51714498
[2] https://www.independent.co.uk/news/health/coronavirus-herd-i...
[3] https://www.reuters.com/article/us-china-health-reinfection-...
[4] https://www.statnews.com/2020/03/10/simple-math-alarming-ans...
I meant the waveform data at offset 0x700000 on the internal storage of the Kobo devices (which is similar but not the same as the .fw files in firmware/imx/). It's not clear whether distribution is allowed.
For TK1 there's a longer list of devices on Wikipedia. The additional ones are the Jetson TK1 development board, Lenovo ThinkVision 28, Xiaomi MiPad, Snail Games OBox, UTStarcom MC8718, Google Project Tango tablet, Apalis TK1 System on Module, Fuze Tomahawk F1, JXD Singularity S192.
At least the x86, x86-64 and ARM ISAs are covered by patents, so you'd need licensing even for an open independent implementation. I imagine this applies to most other commercial ISAs.