I have an iPhone VOIP app that copes with multi-multi transmit and receive (ie teleconferencing) set up using BSD sockets. I would like it to be able to respond to incoming requests when it is in the background but from what I can understand of the iOS 4 docs I can only do this on an NSStream object (or CFRead/WriteStream) by setting the property to NSStreamNetworkServiceTypeVoIP. This is a bit of a problem as my system is a UDP BSD sockets based application. Everything is received and sent on a single UDP socket.
Am I going to need to re-write my audio transmit/receive core to handle NSStreams or is there a way I can get iOS 4 to handle my BSD socket in a similar way to an NSStream? I assume this may be a problem as an NSStream is event based.
Would it be possible to detect when the application goes into the background and build a temporary NSStream object that will pass the data on to through the relevant handling and then continue as normal? Is it even possible to create a UDP NSStream?
Any ideas?
You can create a socket from a file descriptor with CFSocketCreateWithNative(), and then create a pair of streams with CFStreamCreatePairWithSocket(). It might let you use them on a UDP socket. Provided the streams don't read data unless you ask, you might be able to get away with using the FD directly.
Good luck with that though!
Related
I am writing network filter kernel extension for os x.
I want to call something like callbacks in kext.
For example in data_in function when I get a tcp packet I want to call this callback from user application. Application changes this packet and I inject it.
How to make this interaction between kext and user application?
First of all, you don't want to block the data_in callback - you should "swallow" the packet, send it to userspace, and when it comes back, re-inject it into the connection.
There are a few ways of exchanging data with userspace processes. The most convenient way for exchanging network packets is probably the kernel control mechanism, which essentially allows you to open a socket connection between a user program and your kext.
Apple used to offer sample source code, "tcplognke" that did something extremely similar, but it seems to have disappeared from their own site. Someone kindly appears to have saved it and is offering it for download - looks OK to me right now, but obviously be cautious about downloading stuff from random websites.
I am new to creating Windows applications in C++. My task is to write two cpp files, one of which will send a number (x) to the other one, the other one will evaluate f(x) and send it back to the first one. I should implement it using Messages. Couldn't get anything specific online, Could someone pls give me a clue, where to start?
Great thanx!
Are you talking about window messages? If so, the sending app could use SendMessage, which would cause the receiving app to get its window procedure executed. Of course, this means that the receiving app needs to create a window whose window handle is somehow made available to the sending app.
You can do it in several ways.
Using WM_COPYDATA message to pass the data
Allocating global memory to pass data and sending your own message, such that second program can read the data from memory
Sending a message (if two ints suit your needs to pass data)
Using named pipes
Using TCP/IP local connection (peer to peer or through a server)
Look at ZeroMQ (http://zeromq.org ; cross-platform, LGPL). It is a very simple, lightweight and powerfull library. From the very basic level you can use it to exchange UDP-style datagrams, but through reliable transport (TCP or some variants). Also you have cancelling support, time-based polling and advanced network schemes (which are non-needed in your case). I've selected it for a similar task, and it performs very well.
I would like to write a program and run it on two machines, and send some data from one machine to another in an Ethernet frame.
Typically application data is at layer 7 of the OSI model, is there anything like a kernel restriction or API restriction, that would stop me from writing a program in which I can specify a destination MAC address and have some data sent to that MAC as the Ethernet payload? Then write a program to listen for incoming frames and grab the frames from a specified source MAC address, extracting the payload of data from the frame?
(So I don't want any other overhead like IP or TCP/UDP headers, I don't want to go higher than layer 2).
Can this be done in C++, or must all communication happen at the IP layer, and can this be done on Ubuntu? Extra love for pointing or providing examples! :D
My problem is obviously I'm new to network programming in c++ and as far as I know, if I want to communicate across a network I have to use a socket() call or similar, which works at an IP layer, so can I write a c++ program to work at OSI layer 2, are there APIs for this, does the Linux kernel even allow this?
As you already mentioned sockets, probably you would just like to use a raw socket. Maybe this page with C example code is of some help.
In case you are looking for an idea for a program only using Ethernet while still being useful:
Wake on LAN in it's original form is quite simple. Note however that most current implementations actually send UDP packets (exploiting that the receiver does not parse for packet headers etc. but just a string in the packet's payload).
Also the use of raw sockets is usually restricted to privileged users. You might need to either
call your program as root
or have it owned by root and setuid bit set
or set the capability for creating raw socket using setcap CAP_NET_RAW+ep /path/to/your/program-file
The last option gives more fine grained privileges (just raw sockets, not write access to your whole file system etc.) than the other two. It is still less widely known however, since it is "only" supported from kernel 2.6.24 on (which came with Ubuntu 8.04).
Yes, actually linux has a very nice feature that makes it easy to deal with layer 2 packets. You can use a TAP device, which allows your userspace program to read/write ethernet traffic through the kernel.
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
http://en.wikipedia.org/wiki/TUN/TAP
I have a small project that I've been working on in C++, and due to the nature of what it does, I need to insert packets in to a live TCP stream. (The purpose is innocent enough, http://ee.forumify.com/viewtopic.php?id=3299 if you MUST know)
I'm creating a level editor for a game, and due to the nature of the handshakes, I can't simply establish a new connection with a high level library such as WinSock. Until now, it has relied on Winsock Packet Editor to do the dirty work, but if I were to let the application handle it all, it would make everyone happy.
So my question is this: Is there an API somewhere that will allow me to take control of a live TCP stream, and preferably one that keeps it valid after it finishes? And I would prefer to not have to inject any DLLs. Also, Detours is a no-no as I'm using GCC/Mingw.
I've toyed around with WinPCap and I have some working code (I can collect a packet, and from that generate a proper packet to send) but since it operates at such a low level, I cannot anticipate all of the potential protocols that the end user might use. Yes, chances are that they'll be using IPv4 over Ethernet, but what about those people who still use PPP, or some other obscure protocol? Also, the connection gets dropped by the client application after mine is done with it, as the latest ID values in the packets have changed and the client assumes that it has disconnected.
So, if anyone could provide a high-level TCP stream manipulator, I would be very happy. If not, I'll just continue tinkering with WinPCap and tell all the dial-up users to go get better internet.
Target platform: Microsoft Windows XP through Windows 7
Create a separate process to bind to a local port. When the initial tcp stream is created, proxy it through that process, which can then forward it on to the network. When you need to 'inject' into the stream you can have this proxy process do it. Just a thought.
you should look at the source code of ettercap http://ettercap.sourceforge.net/
or hunt, tcp hijacker http://packetstormsecurity.org/files/view/21967/hunt-1.5.tgz
Those 2 softs do what you're after.
I don't think there's any sensible API that will allow you to hijack a TCP stream. Such a thing would, inherently, be a security problem.
Can you insert your program as a proxy for the connection in question? That is, get the program that opens the connection to open it to your program, then have your program open the connection to the real target.
The idea is that if all the packets pass through your program anyway, then modifying the TCP stream becomes relatively trivial.
I am working on an very old application right now. I need to make change in this application to listen for coming icmp request and decide to reply or drop the packet (kind of access control on ICMP). The application is Winsock version 1.1 based. I tried different ways to create a socket and capture icmp packet using the socket. But none of my efforts worked.
Can anyone help me out? Or is it totally impossible?
Thank you very much for your answer.
I don't think you will be able to intercept ICMP packets at the application (Winsock) level, since this is not an application function. You will probably need to write a network filter driver for whichever version of Windows your application runs on.
You say the application is old, but nothing about the OSes you're running it on. Unless you're running it on 16-bit Windows or NT 3.x, there's no good reason you can't just migrate to Winsock 2. You can download Winsock 2 for Win95, and it comes in all later Win9x OSes, as well as in Windows NT 4 and up.
If you really must run this app on Win16, it may be possible to dig up one of the third-party Winsock stacks from that era that did offer raw sockets support, but that sounds like a huge hassle, if you want to do it legally. Easier to just specify Win98 as a minimum OS version and move on.
EDIT: I'm assuming you can do what you want with raw sockets, which requires moving to Winsock 2 if you must use the built-in Winsock in MS operating systems. Changing your program to use Winsock 2 instead of Winsock 1.1 is easy; one library change, one header file change, and a change to the WSAStartup call, and there you are. Raw ICMP sockets let you construct any ICMP packet you want, and in newer OSes you may be able to listen for ICMP packets, too. If it turns out that the stack won't let you listen for the packets you need via sockets, you can do it with packet capturing techniques instead.