I have a created two different virtual interfaces by using iw utility commands "iw wlan0 interface add p2p0 type managed", i can able to create and configured as SoftAP using hostapd. We can make it that interfaces up and we can able to get the beacon frame also. if do manual hardware reboot sometime the SoftAP name is not discovering in the WIFI scan list but the beacon frame data received in sniffer logs.
If you guys have an idea please suggest to solve this issue.
Related
I have a program written in Visual Basic (.NET Framework 3.0) that communicates with a power supply via a D2XX driver (over COM3) and a pump via a VCP driver (over COM2). Currently, if both USB devices are plugged in when I start the program, it tries to communicate with the pump, (COM2) when trying to communicate with the power supply (COM3). I found a temporary solution to this issue by only have the power supply connected when starting the program. Then I initialize communication with the power supply, and afterwards plug in the pump; this allows the program to communicate with both separately for the rest of the time running the program. But this process is tedious and I am hoping there is an alternative solution where I can keep both units connected via USB and the computer communicates separately. What is confusing is that this communication issue was not always the case, a week ago it worked without having to disconnect the pump (all drivers are updated, and on the device manager they are listed as their respective COM ports as well) ; I am struggling to find some correlation between what is the underlying issue.
I tried to delete other hidden additional COM ports. I made sure all drivers were updated. When the pump is communicating via the same port as the power supply, and then I try to communicate with the pump, I receive this error:
System.UnauthorizedAccessException
HResult=0x80070005
Message=Access to the port 'COM2' is denied.
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
But again, If I start the program with only the power supply plugged in and initialize communication with the power supply, and THEN plug in the pump, this issue is evaded. I hope someone can give some sort of direction at all troubleshooting this issue because I am completely stumped. Thank you!
Most likely your program implicitly relied on the correct enumeration order. If you use devices with an FTDI product with internal flash or with dedicated eeprom, you may be lucky: Many can configured via FT_PROG to be visible only for D2XX and not as VCP. This way you can avoid the problem. Alternatively, you can try to modify your program so that it accesses D2XX first. Make sure to filter out the correct device using device informations. E.g. the serial number or the VID:PID if the device manufacturer has made the effort to aquire its own IDs. Check 3.4 FT_GetDeviceInfoList of D2XX Programmer's Guide for details.
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 am trying to implement a monitoring system using ONOS. I am able to collect the port delta statistics from them using port_stat_changed listener.
In the flow statistics, I get the flow entry, which has selection criterion. This criterion only has only Ethernet information. Is there any way to identify the Source and Destination IP address and Port using ONOS. Any suggestion would be very helpful.
The source and destination IP and MAC if they are not in the Switch's rules can be accessed by the application by taking this information from the packets. If your application does not have access to the packages, I do not think the Switches store this kind of information. In case, then, you're going to have to develop a solution by putting a rule in the Switch to pick up that data.
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'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.