Computing desk
< July 30	<< Jun \| July \| Aug >>	August 1 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 31

Java: generate parameterless Constructor<> as wrapper?

In Java, is there any way to obtain an instance of `java.lang.reflect.Constructor` that accepts `newInstance()` without parameters, from a class that doesn't declare a parameterless constructor, while still allowing the class's code to initialize the instance (unlike crafting a serialized instance or using one of the backdoors that Objenesis uses)? One example might be binding parameter values to a constructor with parameters; another might be wrapping a static factory method. Neon Merlin 00:37, 31 July 2017 (UTC)[reply]

Odd time zone in emergency alert

Not sure this is really a computing question per se, but close enough. It can be seen as a followup to Wikipedia:Reference desk/Archives/Computing/2017 July 24#Wireless Presidential Alerts.

I live in Los Angeles (well, technically unincorporated LA County), but for some reason I not infrequently get Emergency Alert System messages about dust storms somewhere in the Mountain Time zone.

The screenshot is of a message I received on July 29, at 18:27 PDT. You'll note that the time zone is given as "MST", which means Mountain Standard Time; that is, specifically not Mountain Daylight Time.

Now, this is not impossible; Arizona uses standard time all year, except for the Navajo Nation I think. On the other hand, there is a distressingly large contingent of people who say "Pacific Standard Time" when they just mean Pacific Time, even in summer.

So, questions:

Where was this dust storm? Was it in Arizona, and if not, did the National Weather Service really make the inexcusable blunder of writing MST when they meant MDT?
Why the @#$@ did I get the alert in Los Angeles?

Insights welcome. --Trovatore (talk) 09:25, 31 July 2017 (UTC)[reply]

@Trovatore: Geolocation APIs are not perfect. Maybe the geolocation service they're using does not know the correct location of your IP address. (((The Quixotic Potato))) (talk) 11:34, 31 July 2017 (UTC)[reply]

I didn't think these alerts go out over ip.

According to the FCC, they're required to pinpoint these alerts to the nearest county. I can't imagine a phone in LA is connecting to cell-phone towers in mountain-time counties! Something strange is happening. ApLundell (talk) 14:52, 31 July 2017 (UTC)[reply]

(EC) Seems unlikely this has anything to do with IP address geolocation accuracy since AFAICT, no component of the EAS uses IP geolocation. Well at least not of the end user. As I said below, assuming this is WEA I'm not really sure how the targeting happens but I find it unlikely they are relying on IP geolocation of the cell tower either. The provider should have some identifier for their cell towers and also coordinates for each tower, so most likely there is a database of which towers and this is used to automatically select which towers broadcast the alert. If I had to guess either the database is flawed (I don't think this is as uncommon as you may think) or whoever implemented the geographical targetting screwed up in selecting the area somehow or there's some flawed interaction between the selection of towers and their area. Either way, unless the federal government is even more screwed up than I imagine, I suspect this is the sort of thing for which it wouldn't be that hard to find someone who will take an interest if it's happening regularly. Nil Einne (talk) 14:57, 31 July 2017 (UTC)[reply]

(EC) I suspect this was probably somewhere in Arizona maybe Southwest Maricopa County and northwest Pinal County, definitely there seems to have been one around there at that time with the ending time of 7 PM MST e.g. [1]/[2] (dead but hopefully still available here [3]). When you say EAS do you mean WEA sent to your phone? If so, AFAICT this works based on cell broadcast or some related technology see e.g. [4] [5] [6]. This would most likely mean that whatever cell tower you were connected to for some reason broadcast this alert. Since it's unlikely your cell tower is anywhere close to the target region I would guess this is an error. I'm not really sure how precisely the geographical targetting is implemented, but if it annoys you I'd suggest contact your provider, the NWS and the FCC. Not only is it likely that one of them are the cause but it's likely at least one of them (particularly the government agencies) will take an interest, not least because such inaccurate targetting is likely to cause people to disable alerts. Nil Einne (talk) 14:57, 31 July 2017 (UTC)[reply]

More important, if you are getting alerts meant for another area, maybe you aren't getting the ones meant for your area. Or not all of them. --69.159.60.147 (talk) 06:27, 1 August 2017 (UTC)[reply]

P.S. My searches suggest probably most Dust Storm Warnings in the US are for Arizona. Nil Einne (talk) 15:00, 31 July 2017 (UTC)[reply]

Thanks, Nil! Great work! --Trovatore (talk) 19:39, 31 July 2017 (UTC)[reply]

This is a complex issue: [7]. 92.8.219.206 (talk) 19:49, 3 August 2017 (UTC)[reply]

Well, it's not all that complex. Just complex enough that a lot of people get it wrong, which means you have to double-check what someone else means.

My preferred solution would be for us all to switch to TAI (not UTC; leap seconds are a terrible idea and the sooner they go away the better). But I suppose it's unlikely. --Trovatore (talk) 20:04, 3 August 2017 (UTC)[reply]

Spoofing IP Addresses

Our computer guy is out and I can't find a good explanation for how IP spoofing works. I think it best if I explain what I know. It is limited. Then, correct my understanding please. Assume there is a server A and two computers B and C. B is allowed to use A because the IP address for B is authorized on A. C is not allowed to use A because the IP address for C is not authorized on A. I understand that C can build a message that looks like it came from B and send it to A. A will think it is from B and respond, but won't that response go to B? It won't go back to C. So, that spoofing doesn't help much if you want a response. I also know that messages on the Internet are like envelopes. You can put one inside another inside another inside another. So, C can make a message from B to A and put it in a bigger message from C and send it to A. If done correctly, A will get the fake message from B. However, there is no reason for it to respond to C. Once again, it is working on a message from B so it will respond to B. I figure there is some kind of rule to make it wrap the response in a response to C since that is how it showed up. I understand that routers work that way. The server responds to the router and the router responds to the computer. But, that is different. The server doesn't really notice the end address for the computer. It is working with the address of the router. In the spoofing case, the server needs to use B's address, not C's. So, this isn't like a router at all. What am I getting completely wrong? How does C pretend to be B and get A to send the response to C? 209.149.113.5 (talk) 14:41, 31 July 2017 (UTC)[reply]

Our article IP address spoofing says "The protocol requires the receiving computer to send back a response to the source address, so that spoofing is mainly used when the sender can anticipate the network response or does not care about the response." CodeTalker (talk) 20:37, 31 July 2017 (UTC)[reply]

If it was combined with ARP poisoning or false route injection, an intruder may cause the response to be routed to their spoofing box. Graeme Bartlett (talk) 22:04, 31 July 2017 (UTC)[reply]

I answered her in person and I think it is good to have a brief answer here. In the movies and on television, IP spoofing is not real in any way. The IT wizard says "let me spoof the IP" and then suddenly they have access to the CIA's top secret database. In reality, IP spoofing is of limited use. It bypasses IP authentication, which is rarely used. This is a scenario that I use in class: Assume you are setting up a billboard for a gas station. The billboard is a good 10 miles away from the gas station, off the highway. The purpose of the billboard is to show the price of gas as the station before potential customers reach the gas station. If done correctly, you get customers to skip your competition's station because you have cheaper gas. How do you update the price on the billboard? Assume both the billboard and the gas station's computer are connected to the Internet. You can send an "update price" message packet to the billboard. To make sure it came from the gas station, the billboard checks the IP address of the update. If it came from the gas station's computer, based on the IP address, the billboard updates the price according to the message. What happens if the competition creates a packet with the gas station's IP address (IP spoofing) and sends a high price to the billboard? The billboard will see that the IP address came from the gas station's computer and update the price. In this rare case, a response from the billboard is not used, so IP spoofing is a threat. 209.149.113.5 (talk) 12:19, 1 August 2017 (UTC)[reply]

There are "envelopes" but in general they are different protocols, so not terribly germane. VPNs do (almost always) have IP inside IP, but the virtual network is at a different conceptual level from the physical one.

There are a number of scenarios that are relevant:

You want to send data:
- If there is no handshaking you can fake the origin, this is a field in the header. The routers will deliver the packets to the target machine, job done!
- If there is handshaking, you need to be able to:
  - predict it. SYN/ACK is the normal method, and I doubt there are significantly vulnerable implementations any more, but you never know.
  - intercept the response. You can do this by the methods Graeme Bartlett lists, or simply by packet sniffing a suitable part of the network.
You want to see the response - See the last method above.
You want to commit a denial of service attack (or maybe some kind of network test?). For this you may want the replies to go to your target. See for example smurf attack.

All the best: Rich Farmbrough, 18:22, 4 August 2017 (UTC).[reply]

I have Windows 10 and want to be able to dual-boot in Windows XP

In order to still work with an old capture card, I need Windows XP. I've tried it with a VirtualBox VM of XP within Windows 10, but while in the VM I'm able to at least run the Edius 6.0 setup (something I can't do in Windows 10), the VM fails to even just recognize the card in the device manager. Within Windows 10, I can install Edius 8 and the semi-official legacy drivers for the card for Windows 10 so the card appears in the Windows 10 device manager and can be found in a list of abritrarily configurable devices within Edius 8, but Edius 8 is too new to communicate with the card. I have it confirmed from other users that it all works fine with Edius 6 in a genuine XP rather than a VM. So since this doesn't work in Windows 10 nor in an XP Virtual Machine, I need a dual boot.

I've been googling some and with https://www.groovypost.com/howto/dual-boot-windows-10-other-versions-windows/ and https://www.groovypost.com/howto/dual-boot-windows-8-windows-7/ , I've already been able to create a USB system image backup of my Windows 10 (by ways of https://www.groovypost.com/howto/create-windows-10-usb-recovery-drive/ ) and mount and format a new 20GB NTFS partition for XP by shrinking my existing C: drive, but then I read on and found those tutorials were actually to install Windows 7 next to an already existing Windows 10 or Windows 10 next to an already existing XP, not XP next to an already existing Windows 10. So then I've googled some more and found stuff like https://www.tenforums.com/installation-upgrade/25724-dual-boot-xp-top-windows-10-a.html telling me that it can be dangerous because the booting procedure for XP can actually damage my Windows 10 boot. That latter link gives a workaround at the point I'm at now:

"Now restart your computer and boot from Windows XP CD-ROM. Proceed to install Windows XP. You can now boot into Windows XP but not Windows 10 because the legacy boot loader has replaced the modern boot loader. Boot your computer with a Windows 7 or 8 or 10 DVD-ROM. When you see the setup screen you [...] click on Repair this computer [...]. Now you can boot to Windows 10 but not XP. Download and install EasyBCD. Run it and add a boot entry for Windows XP. Now you can dual-boot between the two."

So once only XP will work, will I be able to repair my Windows 10 boot sequence by just plugging in that USB stick I've made this way: [8]? I think it'd be safer to use the stick I've just created rather than the Windows 10 DVD because my recovery backup USB is newer and by using the DVD instead, I could maybe use a lot of system data (installed programs and all the stuff in my earlier VM that I've created before to still be able to work with my bitmap editor and scanner), is that right? Will I have to use some key command upon boot to make it boot from that stick rather than right into XP? Why can't I prevent all this trouble by using EasyBCD right away before I even install XP? Or maybe by partitioning another drive than C: for XP and that way keep my original Windows 10 boot sequence on C: intact? --79.242.203.134 (talk) 21:49, 31 July 2017 (UTC)[reply]

If you have another physically separate drive you can use, this will be a much easier process. You can install XP on the second drive and then use the BIOS/UEFI boot menu to choose which disk to boot from during the power-on sequence (typically accessed by pressing F9 when you first power on the computer, but which key you must press varies by motherboard). This way you don't have to worry about conflicting boot managers as neither boot manager will know about the other.

If you go this route, I am not sure if this is a necessary step, but I would recommend temporarily disconnecting your Win10 drive before installing XP on the second drive just to be sure there is no chance that the XP installer will be able to interact with your Win10 drive. Someone else might be able to verify if that's an unnecessary step or not. --Amordea (talk) 23:32, 1 August 2017 (UTC)[reply]