I have just started to work with os x and have no experience with it at all. But all I want to do now is to replace old OpenSSL code with Apple Security API. I'm using Secure Transport and I'm a bit confused about with these functions: SSLSetIOFuncs, SSLWrite, and SSLRead.
So SSLSetIOFuncs sets callbacks that perform writing/reading operations (which I should implement). And a lot of questions appear at this point:
First, I just don't understand why I should implement it (in OpenSSL it is implemented already). But ok, I just have to.
Should this implementation be encrypted? I guess no.
Also there are following 2 functions:
OSStatus
SSLWrite (SSLContextRef context,
const void * __nullable data,
size_t dataLength,
size_t *processed);
OSStatus
SSLRead (SSLContextRef context,
void * data,
size_t dataLength,
size_t *processed);
And they are "Normal application-level read/write." according to code comments. So why do I need to define those 2 callbacks for reading and writing then? And if first twos are callbacks which functions I should call for reading/writing in my code (when I really need to read some data from server)?
There are no good documentation and I got stuck with it all. May be I'm just way too dump but little help would be just perfect anyway. Please help!
SecureTransport is callback-based, unlike OpenSSL's SSL_read() and SSL_write() functions. This could require big changes to your code. If you want a read/write-style API that can use SecureTransport for encryption, look at CFNetwork and specifically CFStream
Related
I'm trying to send a relatively big string (6Kb) through libnl and generic netlink, however, I'm receiving the error -5 (NL_ENOMEM) from the function nla_put_string in this process. I've made a lot of research but I didn't find any information about these two questions:
What's the maximum string size supported by generic netlink and libnl nla_put_string function?
How to use the multipart mechanism of generic netlink to broke this string in smaller parts to send and reassemble it on the Kernel side?
If there is a place to study such subject I appreciate that.
How to use the multipart mechanism of generic netlink to broke this string in smaller parts to send and reassemble it on the Kernel side?
Netlink's Multipart feature "might" help you transmit an already fragmented string, but it won't help you with the actual string fragmentation operation. That's your job. Multipart is a means to transmit several small correlated objects through several packets, not one big object. In general, Netlink as a whole is designed with the assumption that any atomic piece of data you want to send will fit in a single packet. I would agree with the notion that 6Kbs worth of string is a bit of an oddball.
In actuality, Multipart is a rather ill-defined gimmic in my opinion. The problem is that the kernel doesn't actually handle it in any generic capacity; if you look at all the NLMSG_DONE usage instances, you will notice not only that it is very rarely read (most of them are writes), but also, it's not the Netlink code but rather some specific protocol doing it for some static (ie. private) operation. In other words, the semantics of NLMSG_DONE are given by you, not by the kernel. Linux will not save you any work if you choose to use it.
On the other hand, libnl-genl-3 does appear to perform some automatic juggling with the Multipart flags (NLMSG_DONE and NLM_F_MULTI), but that only applies when you're sending something from Kernelspace to Userspace, and on top of that, even the library itself admits that it doesn't really work.
Also, NLMSG_DONE is supposed to be placed in the "type" Netlink header field, not in the "flags" field. This is baffling to me, because Generic Netlink stores the family identifier in type, so it doesn't look like there's a way to simultaneously tell Netlink that the message belongs to you, AND that it's supposed to end some data stream. Unless I'm missing something important, Multipart and Generic Netlink are incompatible with each other.
I would therefore recommend implementing your own message control if necessary and forget about Multipart.
What's the maximum string size supported by generic netlink and libnl nla_put_string function?
It's not a constant. nlmsg_alloc() reserves
getpagesize() bytes per packet by default. You can tweak this default with nlmsg_set_default_size(), or more to the point you can override it with nlmsg_alloc_size().
Then you'd have to query the actual allocated size (because it's not guaranteed to be what you requested) and build from there. To get the available payload you'd have to subtract the Netlink header length, the Generic Header length and the Attribute Header lengths for any attributes you want to add. Also the user header length, if you have one. You would also have to align all these components because their sizeof is not necessarily their actual size (example).
All that said, the kernel will still reject packets which exceed the page size, so even if you specify a custom size you will still need to fragment your string.
So really, just forget all of the above. Just fragment the string to something like getpagesize() / 2 or whatever, and send it in separate chunks.
This is the general idea:
static void do_request(struct nl_sock *sk, int fam, char const *string)
{
struct nl_msg *msg;
msg = nlmsg_alloc();
genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, fam,
0, 0, DOC_EXMPL_C_ECHO, 1);
nla_put_string(msg, DOC_EXMPL_A_MSG, string);
nl_send_auto(sk, msg);
nlmsg_free(msg);
}
int main(int argc, char **argv)
{
struct nl_sock *sk;
int fam;
sk = nl_socket_alloc();
genl_connect(sk);
fam = genl_ctrl_resolve(sk, FAMILY_NAME);
do_request(sk, fam, "I'm sending a string.");
do_request(sk, fam, "Let's pretend I'm biiiiiig.");
do_request(sk, fam, "Look at me, I'm so big.");
do_request(sk, fam, "But I'm already fragmented, so it's ok.");
nl_close(sk);
nl_socket_free(sk);
return 0;
}
I left a full sandbox in my Dropbox. See the README. (Tested in kernel 5.4.0-37-generic.)
I have a product for macOS which uses Network Kernel Extensions to get the network data and modify the data based on some pre-defined rules.
As kexts will no longer be supported starting macOS 10.16, I have to port my solution to use Network System Extensions.
I am not able to find out what APIs to use for this purpose.
I looked into NEFilterPacketProvider under Content Filters which can provide me the packet and based on rules I can allow/deny/delay. But is it possible to perform some computation and forward the manipulated data before allowing it??
The NEFilterPacketHandler provides the packetBytes in the form of const void so even though it would be possible to cast const away? Plus there are other expectations here such as packetLength that rely on these bytes staying intact.
typedef NEFilterPacketProviderVerdict (^NEFilterPacketHandler)
(NEFilterPacketContext *context,
nw_interface_t interface,
NETrafficDirection direction,
const void *packetBytes,
const size_t packetLength);
Writing my first zeromq application so sorry about simple question.
In my financial software I receive quotes from stock exchange. Each update looks like that:
struct OrderUpdate {
uint32_t instrumentId;
uint32_t MDEntryID;
uint32_t MDUpdateAction; // 0 - New 1 - Change 2 -Delete
double /*decimal*/ MDEntryPx;
double /*decimal*/ MDEntrySize;
uint32_t RptSeq;
uint32_t MDEntryTime;
uint32_t OrigTime;
char MDEntryType;
};
I do not allocate this structures at runtime, instead i pre-allocate and then reuse (reconfigure) them.
I need to pass this structures from c++ to c# (later c++ to c++ cause will move to Linux).
What zeromq techniques should I use? As far as I understand I should:
use PUB-SUB because i have one reader and one writer
use inproc as a fasters transport (I understand limitations and OK to have them)
use zero-copy to deliver my OrderUpdate structure to zeromq publisher buffer
use ZMQ_DONTWAIT ?
Am I correct about that and probaly you can suggest more?
This guys says yes:
http://web.tiscalinet.it/giordy/midi-tech/lowmidi.htm
Same with a really old book from 1998 (Maximum MIDI).
MSDN doesn't mention it.
I'm not getting any sound.
I fill a char buffer with status|note|velocity|status|note|velocity...
Set lpData, dwBufferLength, and dwFlags of a MIDIHDR struct
call midiOutPrepareHeader (MMSYSERR_NOERROR)
call midiOutLongMsg (MMSYSERR_NOERROR)
Still no sound! Spamming midiOutShortMsg is working but will that work for slower machines? Did they change the functionality?
Thanks.
I'm an idiot! I figured it out: Microsoft GS Wavetable Synth does NOT support sending multiple short messages in midiOutLongMsg. The MIDI Mapper DOES!
midiOutShortMsg should be plenty fast, even on slow machines. MIDI interfaces themselves (hardware that is, but some software will limit themselves) run at 31,250 baud. This of course is ignoring any slow code you may have wrapped around where you call midiOutShortMsg.
Anyway, technically you should also be able to get away with one status byte, if the following notes use the same status byte. So, if you want to do note on/off (using velocity 0 for off) and those notes are on the same channel, you could do this:
status|note|velocity|note|velocity|note|velocity|note|velocity
This is called running status.
I have been using Unimotion in my application to read motion sensor values for Apple laptops, but have been unable to port the code to 10.6 64-bit. (I have also tried SMSLib and had the no luck either.)
Is there any simple 10.6 compatible
SMS API?
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace
this with new IOKit calls?
(This post did not really get me much further)
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace this with new IOKit calls?
That very document suggests replacements. What about this one?
kern_return_t
IOConnectCallStructMethod(
mach_port_t connection, // In
uint32_t selector, // In
const void *inputStruct, // In
size_t inputStructCnt, // In
void *outputStruct, // Out
size_t *outputStructCnt) // In/Out
As far as I can tell, there should be no difference except for the order of the arguments. That said, I've never used I/O Kit, so I could be missing some critical conceptual difference that will make this call not work as the old one did.
I haven't used this in 10.6, but does this work?
http://code.google.com/p/google-mac-qtz-patches/