As a manufacture you know that you only need a couple of these “bad” devices before you damage the traffic for everyone, forcing everyone to upgrade all their equipment. It also benefit the Internet providers, because faster network will camouflage the problem a bit.
Is there any such law against this or any efforts in introducing such laws, either in Norway or elsewhere?
No. https://boingboing.net/2014/10/03/fcc-fines-marriott-for-jam...
>No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government.
So according to you, denying everyone usage is worse than denying everyone else usage to improve your usage?
>If we expand the definition of jamming to the protocol level like exemplified here, the law gains broad authority to interpret any online interaction that makes your experience worse as "jamming." The law should really should stick to radio frequency enforcement, and stay out of protocol-level concerns - it's just too big a can of worms.
This is a fundamental misunderstanding of how the legal system works. It's not an algorithm. Intent matters. Going back to the originally quoted text, it says "willfully or maliciously", so maxing out your WLAN to transfer files 24/7 is probably not going to get a knock on the door by the FCC. Intentionally jamming your neighbor's wifi (deauth packets or otherwise) is.
If you’re objecting to the phrasing in the boingboing article (which called it “jamming”), ok, but the law seems clear to me and the interpretation thereof I think was correct.
I posted what turned out to be a misunderstanding (or incomplete if you are more generous) understanding of spectrum rules. My comment was correctly downvoted to 0, but more importantly I got a response that simply explained where I was (utterly) wrong. No flames, no further conjecture, just references. There's a little bit of following discussion.
This is the way it's supposed to work!!
A deauth packet needs the MAC address of the AP to deauth clients connected to it and the MAC address of client you want to deauth, the latter is not required and an omission would result in the packet being treated as a "broadcast deauth" but many clients do not accept broadcast deauth requests.
"Auto Channel Selection" is done very poorly on most routers, there isn't an algorithm to do so in the spec and the vast majority of routers either to a round robin on boot up or default to channel 6 when set to auto, I can count on one hand the number of routers I've seen that run any type of spectrum analysis on the available bands before selecting a channel.
The only thing I've seen that even resembles closely to what you claim is that some ISP provided routers default to "disconnect" every 12-24 hours. Some just reset the DSL connection, but some also reset the clients. This is done primarily by cheap ISP's that want to free up IP addresses they basically reset the DSL connection and complete the handshake but does receive a lease until a client on their network attempts to connect to the internet, think of it as a standby mode. To ensure that random traffic on the network does not trigger a lease some deauth their wifi clients to reset all existing connections. However this is pretty rare as most DSL providers just reboot the router remotely....
However again random deauth MGMT frames on the same channel would not affect your own wifi network since the MAC addresses of those APs are not identical, conflicting MACs could cause issues but they could cause so many other issues as well way before anything like this could become an issue.
I really don't know why home internet connection and particularly WIFI has so many insane myths and conspiracy theories around it. The reality is simple the 2.4ghz spectrum is the most contested unlicensed spectrum in common use with everything down from your microwave to house and car alarms, wireless headsets and other wireless radio equipment using because that spectrum has been pretty much defined as unlicensed globally way before WIFI every became a thing.
As a result WIFI equipment and especially old and or cheap equipment works really poorly, and the fact that everything from your mobile phone to your toothbrush today comes with wifi and in many cases spams the spectrum even when it's not enabled only complicates the issue.
Then you have housing that outside of the US is primarily built out of reinforced concrete or bricks even for internal walls and you get the worst possible environment for a stable connection.
It's slightly better now in Europe as wood, foam and composites are becoming more and more common for housing both internally and externally but still I've seen flats in London that the wifi won't work from one room to another if the door was closed, we later figured out that the door had an old layer of lead paint and the flat was in a converted victorian town house from the late 1800's which was built from brick and still had lead piping, some of the windows can also be made out of lead glass especially if they are old and pebbled or painted if they weren't replaced recently (which if you live in a graded building they likely weren't because it would cost a small fortune), and some of the clay bricks and fire bricks may contain high levels of tin and lead naturally.
How many IP addresses can you possibly save with this tactic? If you have 1000 subscribers, are you really going to only get 990 IP addresses, and hope that your subscribers don't all come online at the same time?
That's the problem though. Even if most people are offline during the night or during holidays/weekends, you still need to provision enough IP addresses for peak demand. ISPs aren't paying for IP addresses by the hour, they're probably leasing/buying subnets on a yearly basis, if not longer.
So they would have to be not home, and not leave any IoT device on when away. Of course this happens, but is probably very rare in the evenings (and at night).
There is roaming support in management frames and for signal strengths clients usually do their own roaming if you have 2 APs on different channels for the same SSID your client would select the best on and roam if necessary as the signal strength changes.
Unless you're on ethernet, then you suffer none of wifi's many downsides.
The real the8472 would have never said that. Then again without you coming to pin your message on an actual bulletin board for everyone to see you we can neither confirm the authenticity of this message nor of it author. Implicitly its validity is questionable.
> have other options at their disposal
When I tried connecting all the phones, tablets, watches and other such devices in my house to Ethernet cables it proved to be a real hassle for my cat. Do not recommend.
There's value in convenience and it probably outweighs the drawbacks for all but a (very) few specific applications.
As for the convenience, I think the same kind of reasoning brought us endless ads and tracking.
Of course it isn't. The person making one argument against convenience chose convenience over the massive downsides of using the option with "questionable security" and that is "inherently unreliable". Hence the validity of the claim is undermined. Tomorrow your message might read that "WEP secured WiFi networks are the pinnacle of security and reliability" because dang decided it's a funny thing to do, with little recourse from your side.
The world is not only black or white. You're using the downsides of one extreme as an argument to support the other extreme. Do you realize now that they're both extremes and likely equally wrong?
There's always a balance between security and usability. A sweetspot where the system is convenient to use and still offers as much security as possible. Make it too inconvenient and it's either not used at all or people just end up circumventing all the controls to get that convenience. And this happens ad-hoc, uncontrolled, which is worse.
But it should not be the only option since it can't be relied on due to its many problems. Deauth attacks aren't the only issue.
Although if someone can think of better reasons I would love to hear it.
There are devices that act as AP like the chromecast. This is then used by a smartphone app to connect and configure the device. I don't think the chromecast in particular is the culprit but I wouldn't be surprised a similar device was sending deauth packets due to an implementation mistake.
Rehearsals are done in controlled manner.