I am using Core WLAN framework to switch between WiFi networks. I am facing a problem that after I switch from WiFi network 1 to WiFi 2, I have to wait for 10 seconds before I instantiate any network activity. Though the WiFi symbol shows the correct value before I put a wait for 10 seconds. Anyone has any clue as why this happens? And any remedy for this.
Core WLAN Framework link:
http://developer.apple.com/library/mac/#documentation/Networking/Reference/CoreWLANFrameworkRef/_index.html
There is no way to predict how long it will take to have a given network assign your system an IP address, for DNS resolution to begin to work, etc etc. Instead of waiting for a specific timeout, use the SCNetworkReachability API to take action when the system can access a given host or service.
Sample code: http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html
Related
I'm facing issues when communicating with devices over USB hub. When enumerating devices directly to host port, it does work, some devices over usb hub have issues.
Setup: STM32F103C8 - MAX3421E - LUFA (usb stack) (ported to MAX3421E (host) and STM32F103C8T6 (device)) - USB Full-Speed setup
Scenario:
When I attach device directly to host, I don't experience any issues enumerating almost all (some devices seems to be faulty and have weird/nonstandard behavior) devices. But when I try to enumerate over usb hub, devices starts to behave very strangely. I'm receiving much more NAK's from devices than when connected directly to host. Some devices are able to return Device Descriptor, but retrieving Configuration Descriptor fail. Some devices return Toggle Error after several NAK's, this could be remedied so far by delaying retry IN token. Also there is different behavior of devices when connected over different hubs. I.e. one device has no problems when connected to HUB1, but have issues when connected to HUB2. Then I have HUB3 (7 port) which internally acts as HUB in HUB. On this HUB3 device working fine on port behind secondary internal hub, but not on primary ports exposed over "root" hub.
I'm in suspicion that hub's TT could be somehow interfering with usb communication, but according to information I have found, TT should not be enabled under Full-Speed setup.
I have checked (many times) that I'm setting correct device address assigned during SetAddress phase (which is proved by returning Device Descriptor). When I step debug it seems that I can get Configuration Descriptor also, but while in normal system run, it isn't retrieved, but only over hub.
Does anyone has any ideas, what to look after? I've run out of ideas here after week of trying to find a root cause.
Thanks
so...
- as usual after searching for root cause, solution after days of trying comes naturally after asking on somewhere (this is hapenning to me always, but I do try prior asking always)
- when using hubs, make sure you don't suspend SOF generation during control transfers. LUFA just resume bus inside control transfer routines, so make sure you don"t stops and reenable SOF within (my fault as I'm using ported version to MAX)
- if you have tight main loop make sure you don"t reinitialize usb transfer without completion of previous try, but if you do so, check you don't owerwrite data which haven"t been processed yet fully (especially when using interrupt-driven transfer complete processing) [things seems to work when you have quite some debug output, as it delay that time critical transfers]
Enumeration over hub isuues are now second to none. Small glitches are subject for tweaking.
Unfortunately as I was in question for electrical issues, I had to unsolder usb host shield and soldered another one, which in light of new information seems unneeded. Nevermind, I have trained my soldering skills.
I encounter a problem when I'm trying to use a Ubuntu laptop computer to connect to two Sony A6000 through WiFi in the same time.
On that laptop there are two WiFi adapters, one is embedded (say, Wifi-A) and the other is an Asus USB-N13 ProN USB
dongle (say, Wifi-B).
Using Sony Camera Remote API I can successfully control these two A6000 (say, A6000-A & A6000-B)
through these two Wifi adapters, provided only one camera is connected a time. For example, either using Wifi-A to control to
A6000-A or A6000-B, or using Wifi-B to control A6000-A or A6000-B, will work.
I think this proves both the cameras and Wifi adapters hardware function correctly, and any combination of Wifi adapter and
camera works fine, too.
However, it will be different if I try to connect and control both cameras in the same time. The connection to both cameras
is OK (though sometimes not very smooth), but controlling them is not.
Here is a list of the experiment steps:
Wifi-B connects to A6000-B. Then Wifi-B gets IP address 192.168.122.166
Wifi-A connects to A6000-A. Then Wifi-A gets IP address 192.168.122.165
Send M-SEARCH request to Wifi-A and get response from A6000-A. Then get
Device Description XML file from A6000-A successfully.
Send M-SEARCH request to Wifi-B and never get response
I'm wondering if such configuration (One laptop + two Wifi adapter + two A6000) violates any design consideration
of A6000? For example, because both cameras use the same IP address 192.168.122.1 for themselves?
I'll appreciate if any one could comment on this issue.
Thanks in advance!
Xavier
After doing experiments for many days, I'm sure this symptom is caused by the IP address conflict (both of them are 192.168.122.1) of these two A6000.
As I can't find a way to change them, my optimal solution under such configuration (one laptop + two Wifi adapter + two A6000) is to make use of Linux Network Namespaces. Moving Wifi-B to a new Network Namespace does solve this issue, because every Network Namespace has its own network stack. Now I can freely access both of these A6000 from my laptop.
I hope this answer is helpful to anyone who encounters a similar problem.
There isn't any design consideration that would block this from working. Unfortunately we cannot offer any other troubleshooting suggestions.
I know there are various programs that sniff packets like WireShark, but I'm pretty sure you can only view the data. I want to know if it's possible to edit incoming packets. I'm not sure if packets are the right term. I just want to edit incoming data that is recieved through the internet and who's destination is a specific application. Let's say I am playing an online game. As it loads my computer, it is recieving information like "This person has 10 coins in their money pouch". Obviously not exactly like that but you get the point. I would like to be able to change the data so it is say 100 instead of 10. I know something like this would be possible if you were to do this: Imagine my computer is connected to the internet with an ethernet cord. There is a device attached to the ethernet cord which recieves the data and changes it and then lets it continue to my computer. I would just like to know if this is possible, and how it could be accomplished.
Thanks!
The way I do it, is one of 2 ways:
1.
If your application supports it set up a HTTP Proxy on your machine and you could software like burp / Fiddler to mess with the data
If not (the protocol is not HTTP) you could use either one of 2 options i'v tried [Both based on Hooking the API calls from the application to the OS]:
EchoMirage software that allow messing around with the packets
[Bit more advanced: ] There is a debugger named OllyDbg which has a plugin named Universal Hooker; it enables to hook any window API function and execute a python script on demend. the uHooker contains examples for how to hook WSASend and WSARecive (which are the API functions used in windows sockets).
I am trying to get a list of all IP's on a LAN network. The reason for this is I am writing an application that uses the STAR TSP100LAN receipt printer.
The process for obtaining the IP address of the printer is quite cumbersome for the end user. It involves turning the printer off, holding the paper feed button, turning the printer back on, waiting 15 seconds for the printer to obtain an IP address through DHCP and then finally spitting out a receipt with this information on it.
Seeing as the printer is not Bonjour enabled is it possible to get the IP address through other methods?
Any help is much appreciated! I hope this isn't a repeat question, but through my searching I can't seem to find a solution!
UPDATE: Ok after a bit of thinking I have come up with a pseudo-solution:
Determine the iPad's current IPAddress through NSHost.
Strip the last quadrant from the IPAddress
Using the stripped string as a prefix, iterate 1-255 for the last quadrant
Each iteration, attempt to open a port to the given address using the printer's sdk
If I get a valid response, I know that the IP is a printer
If not I exclude the IP from the available printers list.
So far this has been working, I set a timeout of 5 milleseconds for each port open attempt. But have found that this can return some null results despite there actually being a printer on the network with an IP Address assigned.
Perhaps if I get a null result the first time I should increase the timeout to 15 milleseconds for a second attempt at searching.
Your approach of polling the local /8 subnet is probably the best you can do. I can't find any API to get more detailed information about the network interface (i.e. subnet mask) in iOS. (Although using the subnet mask would be a more correct way to determine the range to iterate, if you could get it.)
As you've seen, 5ms is a pretty tight interval; In my experience, 15ms can STILL be pretty tight for a TCP connection over WiFi. As a next step, I would suggest parallelizing the polling of the range, and thereby enabling you to extend the interval you're willing to wait. The simplest way would probably be to use GCD. You could also start this polling process in the background before the user explicitly needs the printer, which might improve the user-perceived responsiveness of your app.
Alternately, you could use the CFSocket API to open all these connections (CFSocketCreate, CFSocketConnectToAddress, and friends) and get parallelism by servicing them all on the main thread with callbacks/the runloop. Then, as those callbacks come in, make a note of which addresses answer on the given port. Unless the printer isn't using TCP for some reason, this should be workable. Once you know which addresses answer on that port at all, you can iterate over that (hopefully much smaller) list connecting with the printer SDK itself. This approach will give you even more (and way more elegant) parallelism than spawning a huge number of GCD threads, but can be difficult to get your head around if you've not worked with runloops before.
Hope that helps.
You can quickly winnow the list down from 255 to a smaller number by pinging the broadcast address then looking into your arp cache.
Only works for hosts that respond to broadcast pings.
I'm trying to create an embedded outdoor display of bus arrival times at my university. I'd like the device to utilize my school's secured WiFi network to show arrival time updates determined from a server script I have running.
I was hoping to get some advice on the high-level operation of this thing -- would it be better for the display board to poll a hosted database via the WiFi network or should I have a script try to communicate with the board directly over 802.11? (Push or Pull?)
I was planning to use a Wifly or WIZnet ethernet board in combination with a wireless access hub. Mostly inspired by this project: http://www.circuitcellar.com/Wiznet/winners/001166.html Would anyone recommend something else over one of the WIZnet boards? I saw SPI/UART options and thought these boards could work with an AVR platform.
And out of curiosity -- if you were to 'cold start' this device (ie, request a bus arrival time by pushing the display's on button) you might expect it to take 10-20 seconds to get assigned an IP and successfully connect to the database, does that sound right?
I'd go pull. In fact, I'd have outdoor display make http or https requests of the server. That way the server could tell it how long to show a given set of data before polling for a new one using standard http page expiration.
I think pull would make it easier to have multiple displays, and to test your server as well. I've also got a gut feeling that this would make your display more secure. Someone would have to hack your server to hijack your display.
There's a very cool looking Arduino-targetted product called the WiShield. Seems super easy to use and he provides some source code. It uses SPI for host communication. If you're not interested in going the Arduino route, I'm sure the source code wouldn't be too hard to port to something like avr-gcc. Check it out, might save you some time and headaches for $55. Worth checking out anyway.