ACME

Hi, This is the code snippet in my driver for an usb uart device. I am trying to call standard cdc-acm command to set the Line Coding in the device, but fails with this error: USBSendSetLineCoding - Failed : 0xe0005000, bytes transferred: 0 I guess the USB device is returning this error due to incorrect buffer or format. There is no proper documentation on how to use IOMemoryDescriptor when the data has to be passed down in a buffer to the usb stack. (IOUSBHostInterface->DeviceRequest()) Can anyone please point out what is wrong with this code and suggest a right method? void MyDriver::USBSendSetLineCoding(uint32_t BaudRate, uint8_t StopBits, uint8_t TX_Parity, uint8_t CharLength) { kern_return_t ret = kIOReturnSuccess; LineCoding *lineParms; uint16_t lcLen = sizeof(LineCoding)-1; lineParms = (LineCoding *)IOMalloc(lcLen); if (!lineParms) { MyDebugLog(USBSendSetLineCoding - allocate lineParms failed); return; } bzero(lineParms, lcLen); lineParms->bCharFormat = StopBits - 2; lineParms->bParit

We are a UK-based company who are in the process of renewing an iOS Distribution certificate using the Member Center. We are using 'Keychain Access' to generate a Certificate Signing Request, and submitting that CSR to the Member Center. We intend to use the resulting certificate to provision apps using 'Enterprise' distribution.The CSR generated by Keychain Access contains the 'GB' country code in the 'Subject' field of the CSR. However, the certificate we receive back from Member Center appears to have the 'Country' field set to 'US'. The same behaviour is observed with both 'Development' and 'Production' certificates. The machine used to generate the CSR is correctly configured in System Preferences to use the 'English' language and 'United Kingdom' region. We have replicated this issue on multiple machines.Since our old certificate (the one we're trying to renew) has the 'Country' code set to 'GB', we are concerned that the change of country code might affect our ability to provision apps correctly using

I often get questions about disabling the HTTPS default server trust evaluation done by NSURLSession. My general advice is “Don’t do that!” However, there is one case where you have to do that, namely when dealing with a hardware accessory on the local network. This post contains my advice on how to deal with that situation. IMPORTANT If you found your way here and you’re not developing a network-based accessory, I have two suggestions for you: If you’re trying to override HTTPS server trust evaluation for testing purposes, see QA1948 HTTPS and Test Servers. If not, post a question here on DevForums and we’ll try to get you heading in the right direction. Tag it with Security, and either CFNetwork or Network depending on which API you’re using. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com TLS For Accessory Developers Communicating securely with a network-based accessory is tricky because the standard network security protocol, TLS, was de