Interface is set to AP mode.
When turning on ap it is giving "Operation not supported".
[iwd]# ap wlan0 start "start_wpa2" password
Operation not supported
Output of iwd -d:
src/netdev.c:netdev_link_notify() event 16 on ifindex 5
src/scan.c:scan_notify() Scan notification Trigger Scan(33)
src/scan.c:scan_notify() Scan notification New Scan Results(34)
src/netdev.c:netdev_link_notify() event 16 on ifindex 5
Could not register frame watch type 0000: -22
Could not register frame watch type 0020: -22
Could not register frame watch type 00a0: -22
Could not register frame watch type 00c0: -22
START_AP failed: -95
Using WPA_Supplicant, same AP is able to start.
Using a different device driver solves the problem, it is problem in the driver, not in IWD. By adding debug prints in cfg80211 and Netlink helps which is making problem.
Related
I am doing some iPhone automation and want to observe call states of ongoing calls. I implemented a listener to read the idevicesyslog and fetch log output of com.apple.accessibility.heard, which is printing each state change similar to the following lines (stat=Sending and stat=Active):
ay 13 02:14:02 heard(HearingUtilities)[11392] <Notice>: -[HUComfortSoundsController callStatusDidChange:]:415 Phone call holding 0 [pending = 1, active = 0, avc = 0, endpoint = 1] - NSConcreteNotification 0x102f173f0 {name = TUCallCenterCallStatusChangedNotification: object = <TUProxyCall 0x102f47080 p=com.apple.coretelephony aPI=(null) svc=Telephony hdl=<TUHandle 0x103407870 type=PhoneNumber, value=+4912345, normalizedValue=+4912345, isoCountryCode=de> isoCC=de stat=Sending tStat=0 dR=0 fR=0 supportsR=1 uPI=57FCA1D2-D09F-4E23-A08A-3AD4B18B570D grp=(null) lSIUUID=00000000-0000-0000-0000-000000000001 lSIAccountUUID=AA1FC9E6-068E-4D86-B3B9-C1074658AFB2 hosted=1 endpt=1 callerNFN=(null) srcID=(null) aC=(null) aM=(null) iUB=1 vm=0 connStat=00 nMICS=0 sR=0 iSA=0 iSV=0 iSS=0 wHM=0 hSI=0 vST=0 iapST=0 oapST=0 vCA=<TUVideoCallAttributes 0x102f17330 remoteCameraOrientation=0 localVideoContextSlotIdentifier=0 remoteVideoContextSlotIdentifier=0> model=<TUCallModel 0x102f3e380 hold=1 grp=1 ungrp=1 DTMF=1 uMPS=1 aC=1 sTV=0> em=0 iFE=0 sos=0 sSR=1 sSUI=0 mX=0<\M-b\M^#\M-&>
May 13 02:14:14 heard(HearingUtilities)[11392] <Notice>: -[HUComfortSoundsController callStatusDidChange:]:415 Phone call holding 0 [pending = 0, active = 1, avc = 1, endpoint = 1] - NSConcreteNotification 0x10321ab80 {name = TUCallCenterCallStatusChangedNotification: object = <TUProxyCall 0x102f47080 p=com.apple.coretelephony aPI=(null) svc=Telephony hdl=<TUHandle 0x103330670 type=PhoneNumber, value=+4912345, normalizedValue=+4912345, isoCountryCode=de> isoCC=de stat=Active tStat=0 dR=0 fR=0 supportsR=1 uPI=57FCA1D2-D09F-4E23-A08A-3AD4B18B570D grp=(null) lSIUUID=00000000-0000-0000-0000-000000000001 lSIAccountUUID=AA1FC9E6-068E-4D86-B3B9-C1074658AFB2 hosted=1 endpt=1 callerNFN=(null) srcID=(null) aC=AVAudioSessionCategoryPhoneCall aM=(null) iUB=1 vm=0 connStat=11 nMICS=0 sR=0 iSA=0 iSV=0 iSS=0 wHM=0 hSI=1 vST=0 iapST=0 oapST=0 vCA=<TUVideoCallAttributes 0x102f17330 remoteCameraOrientation=0 localVideoContextSlotIdentifier=0 remoteVideoContextSlotIdentifier=0> model=<TUCallModel 0x1032596b0 hold=1 grp=1 ungrp=1 DTMF=1 uMPS=1 aC=1 sTV=1> em=0 iFE=0<\M-b\M^#\M-&>
Unfortunately, starting from newer iOS versions (maybe 15.4 or 15.x already, don't know exactly), the heard service is killing itself after 3 minutes:
May 13 02:28:03 heard(Accounts)[11501] <Notice>: "The connection to ACDAccountStore was invalidated."
May 13 02:28:03 heard(Accounts)[11501] <Notice>: "The connection to ACDAccountStore was invalidated."
May 13 02:30:21 heard(HearingUtilities)[11501] <Notice>: -[AXHeardController shutdownIfPossible]:355 heard still shouldn't be running. Shutting down.
It is restarting after i am opening the settings-> accessibility settings via phone menu. Does anybody have an idea what I can do about this? I thought about following things:
Include heard service / accessibility in an own app, so that it will stay online when app is active
Get call states in another way? I tried an observer inside an app, but when it is running in background, it will not react anymore.
Some iOS setting to enable it permanently
Will this be fixed in an upcoming version?
The com.apple.accessibility.heard seems to be an internal service, does anybody know how to deal with it now?
Otherwise i would also be happy for a hint how to solve this without observing logs. As I said, CallObserver in my swift app is problematic, as it is not working in background.
I am executing the unit test cases using XCTest but the test cases are failed without running the method call.
The below error is displayed in the test log.
Test session exited(45) without completing.
Below are the log file contents.
10:13:51.477 Xcode[27399:424996] <IDETestOperationCoordinator: 0x7fec86f3a2d0>: parseConsoleOutputFromOriginalOutput: called, 78 bytes written out to StandardOutputAndStandardError
10:13:51.581 Xcode[27399:463189] Lost connection to the test daemon.
10:13:51.581 Xcode[27399:462510] Closing socket 69 to testmanagerd for Sim iPhone 5
10:13:51.582 Xcode[27399:462503] Closing socket 58 to testmanagerd for Sim iPhone 5
10:13:51.585 Xcode[27399:424996] Got death notice for pid 31596, removing from SimulatorSessionMap
10:13:51.585 Xcode[27399:424996] Checking to see if pid 31476 is valid: kill(pid, 0) = 0 (YES, it's still running)
10:13:51.585 Xcode[27399:424996] <IDETestOperationCoordinator: 0x7fec86f3a2d0>: parseConsoleOutputFromOriginalOutput: called, 0 bytes written out to StandardOutputAndStandardError
10:13:51.585 Xcode[27399:424996] <IDETestOperationCoordinator: 0x7fec86f3a2d0> is flushing delegate queue, count: 1
10:13:51.592 Xcode[27399:424996] Launch session LaunchSessionClaim_0x7fec86ee5630 relinquised claim on simulator 8678C2A5-960D-4E64-A1CC-9F485D7A1DFC
10:13:51.592 Xcode[27399:424996] Launch session LaunchSessionClaim_0x7fec86ee5630 relinquised claim on simulator 8678C2A5-960D-4E64-A1CC-9F485D7A1DFC
10:13:51.840 Xcode[27399:424996] <IDETestOperationCoordinator: 0x7fec86f3a2d0> finished receiving data from <IDEConsoleAdaptor: 0x7fec86a9fe30 'target' stdin: (null) 0 stdout: (null) 0 stderr: (null) 0>
10:13:51.840 Xcode[27399:424996] <IDETestOperationCoordinator: 0x7fec86f3a2d0>: _considerFlushingDelegateBlockQueue - nothing to flush
10:13:53.785 Xcode[27399:424996] Test operation failure: Test session exited(45) without completing.
10:13:53.785 Xcode[27399:424996] _finishWithError:Error Domain=IDETestOperationsObserverErrorDomain Code=5 "Test session exited(45) without completing." UserInfo={NSLocalizedDescription=Test session exited(45) without completing.}
Need to know the reason for this error.
Subject: Unable to reset the can error using CAN bus error recovery sequence. As when the can bus is not connected to other node .
Description:
We are using infineon XE164 micro-controller and keil uvsion4 for compile the code.
BACKGROUND AND THE HARDWARE SETUP
Our product setup is as below:
We are using XE164 micro-controller to control peripherals . In peripherals it basically control the servo motor , stepper motor , lcd and keypad.
We want to transmit data from infenion XE164 node to PIC18f2480 node.
PROBLEM
There is no issue to transmit and receive data from both node on can bus.
When bus is not connected and data is transmitted by XE164 board our can bus goes in error state.what is recovery sequence to change the can bus mode in error state to idle state.
How to avoid this without hardware reset of micro controller.
In CAN protocol, ACK is a must!
If there is no other node on the bus, CAN Transmission will not work and it's a correct behaviour that it goes in error state.
Only way to get rid of that error state is re-initializing your CAN module (like calling CANInit() again), because even after error recovery sequence, CAN controller retries to transmit the data and again gets stuck into Error state and this will go on... Re-initialization will stop its attempts and CAN module will be in normal state.
EDIT after comment from OP:
If you want to poll whether there is a device on bus or not, you can set a Timer interrupt of say X msec and in Timer ISR:
1. Initialize CAN
2. Send a CAN Message
3. If no error interrupt is generated and message is successfully transmitted, stop timer otherwise keep it going.
You can also try different baud rates too.
I'm trying to implement the websocket protocol and for some reason the iPad isn't cooperating with me. The iPad runs the Hybi-00 specification and the problem lies somewhere in the handshake. I'm getting as far as reading the request and the following magic bytes and responding with what I believe is the correct reply. The iPad isn't agreeing with me and shuts down the connection.
The protocol handler is working for Hybi-06, which is run by most modern browsers.
I'd really like some way to make the iPad tell my why it has decided to shut down the websocket connection so that I can fix the issue. Either that or getting chrome or some other browser to downgrade their websocket version to the same version that iPad supports so that I can get some sort of clue as to what is actually going on.
Is there any way to obtain this information?
Ok, so, even though it would be nice to have the actual error explained, here's the handshake:
GET /myurl HTTP/1.1
Upgrade:WebSocket
Connection:Upgrade
Host:my-host.com
Origin:https://my-host.com
Sec-WebSocket-Key1:1 QB 9 , $169780#8A`#4
Sec-WebSocket-Key2:3 160RhGi7mu 97*66br9
The following eight bytes is the key:
{byte[8]}
[0]: 105
[1]: 199
[2]: 161
[3]: 204
[4]: 5
[5]: 176
[6]: 104
[7]: 199
The server replies with this
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade:WebSocket
Connection:Upgrade
Sec-WebSocket-Origin:https://my-host.com
Sec-WebSocket-Location:ws://my-host.com/
And the key
{byte[16]}
[0]: 100
[1]: 132
[2]: 37
[3]: 58
[4]: 243
[5]: 195
[6]: 173
[7]: 26
[8]: 180
[9]: 239
[10]: 33
[11]: 56
[12]: 40
[13]: 192
[14]: 123
[15]: 255
This is run over a HTTPS connection, so it's basically data from my debugger since I can't get wireshark properly configured to extract this for the life of me. As far as I can tell, the handshake keys are correct as well.
Look at this thread.
As Cybear points out, I would recommend upgrading to iOS6. Current statistics show around 60% of overall iOS users are on iOS6.
Hybi-06 is an version of the protocol that was just a specification, if i'm not wrong there was not any browser in fact implementing that version. I think the most of the browsers went to Hybi-10 then for Hybi-17 ( Rfc6455), as you say iOS uses Hybi00 at the moment. There are couple of servers supporting that particular handshake. I also know that there are a few supporting every single version of the drafts.
I run XSockets.NET, we chosen to support Hybi-00 and the RFC6455 version, as those are the protocols implemented in the browsers. (Safari still on Hybi00)
As in RFC6455 there is a sections regarding supporting Multiple Protocols ;
https://www.rfc-editor.org/rfc/rfc6455#page-26
If you are implementing somthing, my recomendation is to do the RFC6455
can anyone explain the meaning/reason of this adsheet warning please?
Nov 23 09:24:06 unknown AdSheet[256] <Warning>: AdSheet running for 59.992 seconds with 1 clients and 1 assertions [banner:1]: info.company.app (State: Foreground Running) (Background: 0, no timer) has 1 banners: 0xee74b00:EDFD972C-2C31-45A6-A57C-F129F8D0CB97 (created 2011-11-23 17:23:44 +0000) [Visible: never] [In Window: YES]
it repeats every 20 seconds (in the log) and increments the "running for xx.xx seconds" with 20 seconds each time.
It comes up in the log with my iAd supported application and regardless whether the Test Advertisement is loaded or not.
after I kill the application it continues two or three times with:
Nov 23 09:33:06 unknown AdSheet[256] <Warning>: AdSheet running for 599.993 seconds with 0 clients and 0 assertions []:
and then it stops
thank you
I'm pretty sure the [Visible: never] has to do with the warning. Are you sure your AdSheet is visible and entirely on the screen? Did you by any chance accidently add a copy of the AdSheet to your viewController in IB that you don't know of? You should keep in mind that Ads should appear in the foreground.