There are free projects/examples of wol (wake on LAN) for iOS?
I've found this one [openwol][1] but it's old and has no signs of recents updates.
Also I've been digging on it and it's not working as expected, the main purpose of it is wake a computer but it's not working. I've spent some time on it and still no work.
Maybe there are other examples or someone else may join on me and solve/update this code to work?
Wake-on-LAN generally doesn't work for machines on wireless networks, as the wireless hardware is typically powered down when the machine is off or asleep -- it's usually only supported for wired Ethernet. As such, wake-on-LAN is unlikely to give acceptable results on an iOS device, as it'll only work for some specific network configurations (i.e, networks where the wireless segment is bridged to a wired segment that the target system is connected to).
Related
I plan to extend the range of my Wifi with my Notebook. - My question to this, is it possible to build a wireless repeater with only one NIC? or do I really need at least two NICs, one for being logged in and receiving the packets and the other for extending the WiFi/Signal. - Actually, what I wanna do is, using my laptop as a WiFi-Repeater, but only with the built-in NIC, no second one.
I've searched the net already but found nothing about the functionality of a WiFi-Repeater and if they have two NICs integrated.
Hope you guys can enlight me ;)
EDIT(added schemes):
Possibility A
Possibility B
What can be achieved with an AP capable Chip/Firmware, for instance, the Ath9k.
You can't turn laptop's WiFi into range extender, since I believe it requires a special WiFi chip firmware and a special configuration of antenna(s).
However, you might try to look on the internet if WiFi chip you have supports AP mode in firmware (not all manufacturers provides that), and if yes, you can set up the access point with the same SSID. In this case your WiFi clients will roam from one AP to another. Of course, this kind of setup requires Ethernet cable attached to your laptop.
We are in the process of developing an method of caching so that our app can continue to operate in an area with very little/no signal.
Obviously users will try to continue to use functions that require data and we need to handle the inevitable failure of these requests appropriately.
Essentially we are sat in the office, switching airplane mode on and off to simulate entering/exiting signal then adjusting our app to fix any issues this may arise.
What I'd like to know is, is using airplane mode going to give us a reasonable simulation of entering/exiting an area with no data or are there other implications?
I've seen questions raising the issue that the 3G/EDGE connection may not always wake up after airplane mode is switched on - while I appreciate this method is no way as good as actually being out in the field testing, if we can get a reasonable simulation and account for the majority of the problems that arise then I think this is an acceptable tradeoff.
I apologise if this has been asked before, I did do a search on here & on google but couldn't find any appropriate results.
You should try the Network Link Conditioner
There is a WWDC 2012 session called Networking Best Practices that mentions it (but he does not explain how to use it there).
To get it, you have to go to XCode/Open Developer Tool/More Developer Tools.. and download the latest Hardware IO Tools for XCode.
Once you install it from the IO Tools pkg, "Network Link Conditioner" will appear in System Preferences
You can then do something like 100% packet loss to simulate one of those routers that pretends you are connected but actually doesn't work.
On iOS, the network link conditioner is under Settings / Developer (you must have enabled Developer mode in XCode first to see it)
The main problem is that in the Airplane Mode the networking operations fail fast, while spotty mobile signal will lead to timeouts and a-few-bytes-an-hour speeds. This is usually a significant difference from the UI viewpoint. (It might be worth a try to use some bandwidth throttle to starve the testing machine and see how it behaves when the network starts to break?)
A few years back, when testing remote devices which used the cell network to communicate with the 'home base', we did things like move them into a shielded room (make shift), place large shields on three of four sides to force them to connect to a certain tower (and therefore, network), etc. Brute force physical methods. Since this actually cuts off the signal, it may be a more realistic approach.
You may also want to try this through your wlan-router. First, disable data roaming on your iPhone. Then, let the iPhone be connected to the internet through your wlan network. Then, disconnect the gateway on your wlan router while your iPhone is still connected to the wlan network.
This depends on what failure modes you are trying to test.
I use Airplane mode as a first pass check to make sure an app submission isn't quickly rejected.
Other network failure handling checks might include:
3G only (no wifi).
WIFI only (in Airplane mode).
Pulling the power cord on the WIFI access point.
Pulling the network cable from the back of the WIFI access point after connecting to it (Reachability may falsely say yes).
Walking in and out of a basement
elevator (or other Faraday cage) in the middle of a transfer.
Driving between 2 cell towers during a data transfer.
Walking between 2 enabled WIFI access points between connection and data transfer.
Starting the app after more than 30 minutes of device inactivity (radios may be idle).
Running the app while another app (Safari, Mail) is downloading in the background.
etc.
I need a product to simulate network latency for testing mobile applications (in particular iphone and android). I plan to set up a wifi router connected to a linux box, and write a number of scripts to approximate different types of connectivity issues.
So far, I've taken a cursory look at Netem and ns-2 (or its offspring ns-3). Netem looks very easy to deploy and configure, but they both look like they'll require some in-depth investigation.
Does anyone have positive/negative experiences with either of those solutions that they could share? Or maybe used a different solution for this problem?
If anyone comes here looking for tips, I've found a solution that seems to work well.
Ubuntu comes with Netem installed, so I went ahead and just made use of that. Basically, I got a computer with two ethernet ports, forwarded one to the other and applied Netem latency settings to the connection. Then I attached a wireless router to one, and LAN to the other. Netem lets me play with all kinds of latency and packet loss settings.
Btw, I also tried to use a few different laptops and set the internal wireless card up as an ad-hoc wireless router. I got it working for the most part, but finding a laptop with an internal wireless card that plays nice with ad-hoc in Linux is tricky at best... can't recommend it.
Am I missing something glaringly obvious or is there no way to debug an iOS app which uses an external accessory that's connected via the 30-pin dock without using a bucket load of logs etc. I want to be able to use things such as breakpoints and Instruments.
Is there a way to remote debug perhaps, over Wi-Fi, Bluetooth?
Note: Yes, I asked this very recently and I deleted it because I thought I found the answer.. but the answer was only Instruments has support over Wi-Fi.. not Xcode debugging. So the question still remains...
And so...: Given that I've had no real luck finding the answer, and no one has given me an answer as yet - I take it that it is a big fat NO. :(
Makes me wonder are we just expected to magically guess where bugs occur, or log the crap out of everything while wearing out our dock connectors by continuously moving it back and forth between the device and accessory?
Time to file a bug report I guess.
At CES today, I talked to a developer from Wahoo Fitness that makes an ANT+ accessory for iPhone. They had this same problem, but found a solution.
They found a pass-through dock extender that has a mini-USB port. They used the mini-USB port for debugging while the accessory was connected.
The product they were using is http://www.cablejive.com/products/dockStubz.html
This blog talks about remote debugging iOS with a dock accessory attached
You could connect the external accessory to another iOS device (not the one tethered to the Mac running the Xcode debugger). Then tunnel all your EA framework messages from the accessory connected device to the device running the app being debugged over a pair of wifi sockets. Look at the code for tunneling accelerometer messages from a device to the iOS Simulator (a common trick for debugging game code on the Simulator) for one example of how this could be done.
After further researching, and having seen that people had to do sending strings over Wi-Fi to get around this, I'm concluding the answer is no.
I have filed a bug request for this.
In the mean time, it seems like the Wi-Fi logging, and on-device text logging will be the way to go for now.
Here's my understanding for why just the USB protocol works for some external accessories and doesn't for other external accessories. Looks like a fundamental problem, without an arbitrator, two masters can't talk to a single slave over USB, a serial Master/Slave protocol. So XCode is one master, the iPhone is the slave device. If the external accessory is a master too, one won't be able to connect the iPhone (Xcode slave) to the second master (the external accessory).
Probably the Wahoo Key for iPhone" is a slave device and that's why the dockStubz solution works for such an external accessory.
I have tested the dockStubz. It doesn't work for my external accessory. As suspected, the USB protocol can't be used to have two Master devices controlling a single slave device. Trying to hook up a Mac (Master) (via the mini USB ) & an external accessory (Master) (via the 30 pin connector) to the iPhone 4 (Slave) causes the iPhone to go in loop of connect & re-connect.
Following looks promising too, though expensive: digi.com/support/kbase/kbaseresultdetl.jsp?id=485.
Has any one tried to use USB to Ethernet connectors and use a router to route requests from two masters (XCode & External Accessory) to the slave (iPhone)? I am off to Best Buy to purchase USB to Ethernet cables and hook all three on to my IP router. Will report if it works.
This is what will be needed :
http://www.bestbuy.com/site/IOGEAR+-+USB+Ethernet+Extender/9614781.p?id=1218131339965&skuId=9614781&st=USB%20to%20Ethernet&cp=1&lp=1
http://www.frys.com/product/6103339
So connect XCode mac using the male end into the USB slot of your computer. . Use a ethernet cable to connect this to a router.
Connect the iPhone to the female part of the IO gear connector. Connect it to the router via ethernet cable.
Connect the external accessory with the male connector (Sabrent USB to Fast Ethernet Network Adapter.) Connect it to router.
I am still researching if this will work. Just ordered the parts. Will get it by Friday & will report back then.
Update:
The IOGear male end draws too much current when connected to router. Also, the female end can't charge iPhone when connected to the router even when 5V USB current supplied.
So tried to directly connect the iPhone to the USB slot of the router (used for printers). It does charge the iPhone. Also used USB to Fast Ethernet Network Adapter (BestBuy had one to connect Wii via USB) to connect the Mac to the router. It did connect to internet but couldn't find the iPhone. In the router client list I don't see any login entires for the iPhone. So this experiment was a failure unless someone have other pointers.
I have developed an application for iPhone, which is continuously interacting with database ... I have observed that it is running fine in 3G environment but in wifi its performance is not good.
Can someone suggest what can be the reason for it? or can I do anything to resolve it?
I'd rather expect the contrary, given that 3G cellular signal may fluctuate wildly, while WIFI signal should stay almost the same even if you move within the room served by the access point.
The reason may be the particular wireless connection you are using for testing purposes. Try using a different WIFI network and see if the behavior you are experiencing changes.