Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Less junk from Google is actually good (Score 1) 142 142

The key annoyance of "chrome" is chrome. Opera is nothing more than a different skin on the same steaming turd. (and their devs have all but said so. They aren't happy with chromium's extreme memory consumption, but there's only so far they can go to "fix it".)

Comment: Re:802.11 is unlicensed... set up a noise generato (Score 1) 268 268

Cellphones operate in licensed bands. Thus, jammers are illegal.

Drones (RC crap) operate in unlicensed bands and must accept any interference that may exist. Jamming them is not, technically, illegal. However, jamming them would not be in anyone's best interest -- or really worth the effort. (how many jammers would it take to cover a mountain?)

Arming the DC10 is, of course, the correct answer. :-)

Comment: Re:Using Linux would prevent these Cisco mishaps! (Score 2) 112 112

There are lots of switches running linux. Of course, linux isn't the thing doing the switching.

The question to ask is can you get to the OS and/or ssh configuration to remove whatever the vendor may have installed? (i.e. remove whatever ssh backdoor keys they left there.) In most cases, the answer is "Hell. No."

Comment: Re:Not that easy to buy (Score 1) 939 939

On the other hand, if they cannot get credit, they really cannot afford to buy that house. They might be able to make the payments, otherwise, but lenders are a lot more risk averse -- and for damn good reason. Rents then naturally rise to the levels of a mortgage and *bam* the people who couldn't get financing also cannot stockpile cash to improve their ability to secure financing.

And yet, I see all the "for rent" and "space available" signs around town listing rents at basically the same rates I paid a decade ago.

Comment: Re:No support for dynamic address assignment?!? (Score 1) 287 287

RFC2131, Section 4.4.1

The client MUST include its hardware address in the 'chaddr' field, if necessary for delivery of DHCP reply messages.

The word used is SHOULD. There are still plenty of DHCP systems that request (require) a broadcast reply. Go listen to the broadcast traffic on your cablemodem.

And I'm FAR TOO well aware of systems using the wrong hardware address in their requests -- more than one nic, and it uses the MAC from the first nic in all queries no matter which nic it's asking about or using. (and this is from an ISC DHCP client!)

TL;DR chaddr [Client Hardware ADDRess] is 16 bytes of whatever the client puts there.

(Replies in my network are broadcast so the boot agent can see them.)

Comment: Re:No support for dynamic address assignment?!? (Score 1) 287 287

Stock android has no means to handle DHCPv6. It's not there. At all. You can (maybe) root your device and (maybe) add it yourself. But that's beyond 99% of android users. ("root, run custom rom downloaded from internet" - lots of people do that.)

You can call it BS all you want, but there are environments where legal accountability is a requirement. Could you side-step their tracking voodoo? Probably, but that's even more tinkering with your android device.

Comment: Re:No support for dynamic address assignment?!? (Score 1) 287 287

Using the MAC as an ID is a flawed method. Devices come and go, MACs change (because the NIC changed, etc.) Ultimately -- and here's the end of it -- you'd have to be maintaining a registry of every device's MAC within your network to know what's what, where, and who's using it. Just gleaning a "list of mac's" is simple enough, albeit a tedious pain in the ass: arp tables, cam tables, watching broadcast traffic, etc. Knowing the location of each device gets a lot more tricky; sure wired devices will be tethered somewhere off a switch port, but that's not always enough. Wireless devices, on the other hand, can be anywhere. And none of that addresses who's device it is, who's using it, and exactly what it is. (OUI's only go so far, and assume no one is forging their MAC.)

When someone carries a device into the office, does something questionable with it, and then leaves, tracking the who/what/where/when becomes much harder. When the questionable act isn't mentioned for weeks or months, it can become impossible.

Case in point, I had to trace down a "hacker box" in the network. It was a lot easier because it was ON and ACTIVE at the time. Looking through cam tables, I could only go so far as an unmanaged hub. (yes, this company still used far too many hubs. even in 2003.) Careful inspection of the hub (and unplugging one port at a time), localized it to a desk. An unoccupied cubical, in fact. By the time I got to that desk, the machine had been turned off (it was still warm), the "warez" hard drive had been removed (windows registry remembers it), and the non-company 3com nic had been removed (again, registry -- which is how I knew 100% that's the machine I'm looking for.) That was the company computer for that desk, which is the only reason it was still there. Had he used one of his own machines, it could've simply disappeared without a trace. Moral of the story: I had a MAC, and it didn't tell me shit. The "who" was only discovered because his coworkers ratted him out :-) ("Who's been using X's computer?" They didn't know he was doing anything stupid with it.) And that only worked because it was in real time; had it been brought up a month later (nothing to trace) (and there not been a hub muddying the picture), any history logs would simply have ended with "I don't know. It was something at X's desk" [X having left the company many months ago. X's computer official off since it's builtin NIC, registered in company inventory, wasn't being used.]

Comment: Re:No support for dynamic address assignment?!? (Score 1) 287 287

so you are going to need to know, in advance, who's MAC is who's. You'd need that knowledge for a DHCP server too...

One does not pre-program the DHCP server with a list of MACs, nor does every client identify itself by MAC -- the client-id can be many things, MAC being but one of them.

In order for you to get the reply back from the DHCP server, it needs your MAC address.

*sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.

Comment: Re:Static (Score 1) 287 287

*sigh* Those devices ARE BROKEN! And the entire networking world knows it. SLAAC still requires ::/64, as far as I'm aware. However, privacy extensions no longer mandate this brain damage.

Hundreds of people have warned, just as I have, that people can be (and WILL be) stupid, and thus make these blanket assumptions.

Comment: Re:Static (Score 1) 287 287

No. No sane person assumes the size of a non-local network. A lot of the world does, in fact, bow to the stupid that is SLAAC, but it's not "everywhere", nor do hardware vendors worth their salt make any such assumptions or impose restrictions -- your network can be any size you wish. Your ISP is likely to assign you a ::/64 (60, or 56) because it's the lowest common denominator. (and because they tend to use cheap trash for CPEs.) Giving you anything smaller, while technically feasible, creates hurdles for people with little to no networking expertise.

And if you have android devices, it's the only way to get the damned things on your IPv6 network.

Comment: Re:Static (Score 2) 287 287

Please stop with this 64+64 BULLSHIT. There is no "host part" and "network part" in IPv6. (there isn't, anymore, in IPv4 either.) IPv6 is 100% CLASSLESS. The only thing that (currently) demands the 64/64 split is SLAAC -- BTW, it started at 80/48 -- and a network is not REQUIRED to run SLAAC. (which is the heart of the entire roasting of Google here.)

You CANNOT make such an assumption about a non-local network. You MUST know the prefix-length to know what part is "network" and which is "host". You can look up the entire 128bit address to find the assigned block (a ::/48 or ::/32 most likely), but beyond there, you rather literally have to be there.

Comment: Re:Not Needed (Score 1) 287 287

DHCPv6 also lacks an authentication mechanism ... in fact ICMPv6 has RA guard

Neither does ICMPv6 RA. And RA Guard is a layer-2 hack to block the packets -- i.e. must be supported by your switches, unmanaged switches (99.999999999% of home hardware) by definition cannot implement it, older switches never will.

(For the record, IPv4 had the same thing: ICMP Router Advertisement. It was abandoned before most of us were even aware of "IP", as a colossally bad idea. A completely non-authenticatable system of broadcasting "hey! I'm a router, give me all your traffic"; the networking equiv of the Free Candy Van. Why not do away with routers entirely and go back to proxy-arp!)

Comment: Re:Not Needed (Score 1) 287 287

It's not so much the client OSes that are the problem (they are, but a smaller one.) The real issue is updating the routing hardware with modern compliant software. For the home user, that's a real issue because they know nothing about any of this networking IPvWhatever crap, or their ISP or vendor hasn't or isn't making any updates. In the enterprise, they turned to DHCPv6 years ago and don't give a single shit about the further convolutions of the protocol -- too little, too late. ("What? We have to throw away $mil in hardware to upgrade to IOS 16.5XT to get $New-Knob-X that Windows 11 requires?!? Screw that mess." Also, that's big (read: F'ing HUGE) reason why IPv6 adoption has been so glacial. It's a never-finished protocol that's poorly suited to the way we actually use networks. I have gear that's nearly 30 years old, and it still works perfectly fine with modern IPv4 (TCP) systems -- 30yo network stack, but windows 10 can telnet to it just fine. An IPv6 stack from just a decade ago doesn't fair so well; an original '90s stack won't work at all.)

"Can you program?" "Well, I'm literate, if that's what you mean!"

Working...