Hacker News new | past | comments | ask | show | jobs | submit | lipnitsk's comments login

> The tipped minimum wage is so small that it is basically zero

That depends on the state. For example, all west coast states have the same minimum wage regardless of tipped or non-tipped. See https://en.wikipedia.org/wiki/Tipped_wage

> In the state of Alaska, California, Minnesota, Montana, Nevada, Oregon, Washington, same minimum wage are applied for both tipped and non-tipped employees. Tips collected by employees in these states will not offset employer's obligation to pay the wage, and tips is the additional income beyond the wage paid by employer.


Why not make it configurable by advanced users though?


Probably the expected market for advanced users who would need this particular feature is tiny. Like, for the Tor relay usecase, there are something like 6000 relays worldwide, most of them probably provided by various organizations (where a single operator runs many relays) instead of hobbyists, most of them outside USA, and the vast majority of them using some entirely different network connection not affected by this particular device model in any way. The described scenario ("10000s of concurrent TCP sessions") is literally an edge case for residental use; the article does follow up with "What about BitTorrent or cryptocurrency and Web 3.0 apps?" but none of those have network behavior like that.

Like, perhaps this problem is also affecting other kinds of usage, but the original article does not attempt to claim that, and purely from their example it would be generous to assume that literally dozens of individuals would need this feature and, well, it's not worth to make and test features (even if they're just a configuration option) in this case.


Honestly, for various structural reasons, hobbyists are sort of actively discouraged from running Tor relays. It's less of an issue with middle relays than guard or exit but in practice Tor has a strong reliance on trust in relay operators, so small-bandwidth relays popping up onesy-twosy is much less desirable than institutional operators with significant resources.

Which is all just one reason that, of the set of people running Tor relays on residential internet connections, I'd wager a solid 99% shouldn't be.


A symmetric gigabit with unlimited transit isn't terribly small though. And the super-awesome side tail of residential service continues to march forward. My own home connection is symmetric 10 gbps.


The problem with this logic is that ordinary users don't become the target of a denial of service attack either. If it should exist at all, the default should be off. And if then no one would turn it on, it could just as well not exist.


Ordinary users become a target of DDoS way more often than you would think. These days it tends to be related to competitive multiplayer video games, but I'm sure there's still some IRC drama and small-time Minecraft hosting driving it.

In general it's extremely unlikely unless you are engaging in "high risk behavior," but at the scale of an ISP there are enough users doing that kind of thing (Twitch streaming, etc) that it becomes an appreciable frustration for your network operations.


> These days it tends to be related to competitive multiplayer video games, but I'm sure there's still some IRC drama and small-time Minecraft hosting driving it.

This sounds like the sort of thing with similar prevalence to things like running a Tor node. This might even be an example the other way, when your game server or what have you has thousands of peer connections and this thing breaks it by misinterprets that as a denial of service too.


I might be misunderstanding but doesn't the feature also help prevent home users' devices becoming part of a DDOS effort (high number of outbound connections)? There's stories here on HN about IoT devices and infected PCs/phones participating in DDOS on command. So I can see an argument that a home gateway device should try and help prevent participation by devices behind it.


In cases like that the correct answer is to detect weird behavior and call the customer on the phone to ask what's going on. If they say they know what it is because they're running Tor or hosting Ubuntu ISOs or playing P2P games or whatever, you don't have to do anything.

If they say they have no idea what you're talking about, you get to tell them they're infected, so they actually fix it instead of typing their bank password into the infected box the next week because you automatically removed the "huh, internet's slow" that might have led them to investigate it otherwise.


I like your idea and agree that implementing it would improve outcomes for customers. However, the ISP would be on the hook for additional customer support; it's a lot more involved to outfit your call center staff with playbooks for explaining exploited devices to an average customer than it is to toss in a semi-autonomous blocker. This does make things worse for "power users", but ISPs may have also found that said users are more willing to pay for special service agreements (a small business account for example).


> The problem with this logic is that ordinary users don't become the target of a denial of service attack either

I suspect the concern is not that ordinary users would be targets, but that ordinary users would be sources of ddoses (by being part of botnet)


FWIW I'm also on CenturyLink FTTH and just a week or two ago noticed latency spikes and packet loss which magically went away after 15 minutes. Good to read this analysis for future reference. I really wish end users had more control over ONT boxes similar to how we can use own modems for cable/DSL. A DOCSIS-like provisioning by ISP should be possible.

Off topic, but CenturyLink Fiber still uses PPPoE and 6rd instead of native dual stack in many markets and are unwilling to upgrade to more modern configurations.

EDIT: I do not use Tor at all.


> A DOCSIS-like provisioning by ISP should be possible

GSM solved provisioning 30 years ago with SIM cards, any reason why ONTs couldn't employ similar system?


AT&T has replaced the ONT+gateway (communicating over RJ45) by a SFP directly integrated in the gateway. According to some people I've talked to, they are no longer issuing the old hardware, and instead deploying exclusively this. It may make sense, as upgrading would just require swapping the SFP.

I wonder how hard it would be to connect the Nokia 3fe4960ac SFP to a linux server and initiate a DHCP on their 802.11q vlan, or PPPoE, or whatever else they may use?


I am not with at&t but with a very large Canadian provider that provides the same setup (Bell).

Yes, you can do just that. You can also use a commercial firewall with an sfp port.

SFP ports can be a little troublesome. There are a few standards (SFP/SFP+) and different link speeds.

The you need to know your ISP's specific info to configure your hardware. Bell uses pppoe on VLAN 35. You need your username/password for pppoe, which is not a given since the technician will usually do the initial config for you.

Another option is to use a media converter. They are very cheap and "dumb" devices, that simply converts the fiber to copper ethernet. You then connect using just about any router that supports vlans and pppoe.

If you also get bundled TV or Phone subscription on your fiber link, these will be on another VLAN and connection is much more obscure. Usually the logic is embedded in the all-in-one router they provide.


Good suggestion and question. Another challenge for bring-your-own-ONT is making a clean fiber connection without expensive tools, but I would imagine that's also solvable.


My ONT has a standard single SC connector. The only custom splicework on the install is the run from the street to the service entrance. From there it's an off the shelf single mode SC-SC cable to the ONT.

Knowing little about the GPON protocol, what does the ONT actually contain to authenticate to the network? With some quick web research, it seems like it's a serial number and/or a static password Would it be possible to replace the ONT with a well documented model that you have flashed with the appropriate identifiers?

You might have to figure out how to take the ISP's provisioning profile and make your own device use those parameters? Then again if the ISP didn't want dodgy devices on their TDM network they should remove the motivation by deploying non-broken gear in the first place.


I tried connecting a Ubiquiti ONT to a Calix OLT once, but couldn't get any combination of settings to make it work. The OLT saw the ONT, but we couldn't get packets to flow. (This was a test network, so no permissions issues or passwords to guess or anything. Just couldn't make a usable profile for the device. I will admit that I really didn't know what I was doing, I just saw one of the ONTs floating around on a Friday afternoon and poked it a bit.)


CenturyLink uses customer-specific authenticated PPPoE at the router. I don't know if the ONT is authenticated at all.


Wat? If PPPoE is running on the router, then how is the ONT meddling with TCP connections? Is PPPoE being run on the ONT rather than the router? I guess PPPoE isn't encrypted and the ONT could be deencapsulating and reencapsulating frames, but that seems unlikely?


I don't know what the ONT is doing. PPPoE is definitely running on the router, not the ONT. The ONT could be doing some sort of DPI.


That's weird! I don't know much about PPPoE but I wonder if it would be possible to mess with the framing so that the specific DPI/modification wouldn't work. Like add some nonstandard options to the header, and hope the ONT used fixed offsets for getting addresses.

Given that ONTs probably aren't subject to too much hardware security research, maybe it would be possible to hook up a debugger and NOP out the connection tracking hooks.



Won't the server need to accept a TCP connection to receive the cert? If so, the port will show as open. I suppose with UDP it is possible.


I believe the recommended configuration is to run OpenVPN via UDP and only accept connections from trusted certificates. If you're running it on TCP then a scanner would be able to see that you have an open port but still can't see what's running on it.


It does, but what you see is not a portscan, it is a lookup from the Shodan database and they store information about known services on the public Internet.


Shodan does something like a portscan of the entire Internet, albeit fewer ports than if you did nmap -p-


It's a bit ironic that the author works for VMWare, since VMWare Workstation is completely unusable[0] with Linux 5.8 with no ETA to fix in sight.

[0]: https://communities.vmware.com/thread/638457


The innovation coming from big name players in the VM space, namely VMware and Parallels, is all but non-existent. It’s no surprise they were caught off guard when the requirements to update their product to a new OS version was anything other than replacing a couple lines of version number text.


I read in the Russian news[1] that the removed companies were run by Gusev's namesakes. The name is common and the removed companies were registered in cities far away from Moscow.

1. https://meduza.io/news/2019/12/13/minfin-ssha-isklyuchil-iz-...


Another group did a talk on this at DEF CON 26 last year: https://research.kudelskisecurity.com/2018/08/16/breaking-an...

They analyzed over 340 million keys from the web.

> As part of the presentation given at DEF CON 26, one of the outputs was Kudelski Security’s Keylookup application. On this site, you can submit your own public keys and have them tested against our dataset. We will let you know if your key is vulnerable to Batch GCD and ROCA attacks. If your key is in our database, we will be able to give you an answer immediately, if it is not, you may have to wait a bit until the tests complete.

> https://keylookup.kudelskisecurity.com/


I don't think ROCA is related to the vulnerability in the article?


Correct, but the main point of their talk and research was focused on Batch GCD processing of hundreds of millions of keys, with ROCA analysis done in addition.


500,000,000*160bits/(8bits/byte)=10,000,000,000 bytes=9,536MB=9.313GB


There are also protocol buffers libraries for and in C code, such as the protobuf-c library: https://github.com/protobuf-c/protobuf-c


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: