I am trying to implement a VPN service on Android. I am provided raw IP packets (TUN interface which works on layer-3) and not sure how I am supposed to send the packets. I know I can parse the IP packets to pull out the transport layer data (TCP or UDP) and then send it, but I was hoping there was a way I can just simply send the whole IP packet.
Initially, I tried using a raw socket (https://man7.org/linux/man-pages/man7/raw.7.html) and send it that way but learned that this was not possible due to permission issues. To open a raw socket you need root permissions and Android applications cannot run as root.
I found a project called LWIP (https://www.nongnu.org/lwip/2_1_x/index.html) which says that it is a TCP/IP stack implementation library, but after reading the documentation, I can't figure out how to do this.
LWIP has their raw APIs (https://www.nongnu.org/lwip/2_1_x/raw_8h.html#a17edd059f34f45a770fe2fa458ecf4dd) which looks promising but I am not sure if this is what I need. Basically, I just need a way to send the raw IP packet and then get the response, and write it back to the TUN interface -- essentially a pass-through proxy.
Any help would be greatly appreciated. Thanks!
You're trying to reinvent the wheel. There are several appropriate encapsulation methods like GRE or IP-in-IP.
Sending a raw IP packet requires the use of an IP protocol number in any case, so your receiver can get the packets after registering that number.
For starters, it might be easier to use UDP encapsulation.
Related
I'm essentially trying to take a stream of UDP packets created on my local network, and get an android phone to receive them whether on that network, or cellular data as if it was on the source's local network.
I don't have tons of network experience so bear with me.. I have spent the last week researching this problem and found bits and pieces of ideas to make it happen, but I have no idea how to implement any of it.
It seems a sort of multicast with PIM sparse mode seems to be the best option. If I can have the packets routed to the rendezvous point and the phones subscribe I should be set. Looked at VPN a bit too, however Android apis would make it an annoyance to the user.
So I guess my questions in a nutshell for anyone will to put me on the right path would be:
1:How do I route local UDP packets to a rendezvous point? A special router and a port forward?
2:How can I make Android subscribe to a rendezvous point
3:Lastly, when the phone is subscribed does it act as if those packets are from its local network? Or is there more required?
Multicast is not a good solution for your problem. Multicast packets do not usually get past routers. This post's answer explains why multicasting is not a good choice.
Instead write your own client/server application using standard sockets (not multicast) where the server streams the data to each client individually.
In ToyVpnService they read IP packets and then forward them to a remote VPN server.
Why do they use DatagramChannel? Isn't DatagramChannel used with UDP only?
Why do they forward packages with their IP and TCP headers? There are a lot of examples of writing arbitrary data to sockets (for example, here) without headers.
From what I can tell the ToyVpnService is either an experiment or in a very early stage of development.
Yes, it's only used for UDP. They either don't care about lost packets at this stage or they plan to implement a control mechanism later.
In the messenger example that you provide, the apps exchange strings. They don't need to send any other info because they only want to display them. When you communicate with a VPN you have to send the headers so the VPN can forward any data it receives.
In my application, I want to send some data(say, "Hello") from my app to my PC over WIFI network. In PC, a service will listen to that data. But i don't have any idea of sending data over WIFI. I didn't get any proper references too. can someone help me.
Thanks in advance.
What you need is a propper protocol which both, your server and your phone can easily deal with.
If you don't send sensitive data, I think easiest would be HTTP
This depends on what you want the service on the PC to do with the received data, really. For all I know, you might find some off-the-shelf software that can help you set up this service. However, as others mention here, http is definetely the easiest way to do this. If you cannot find any existing software for the "listening pc", you'll need to write a program that listens at a predetermined port for http traffic (I wouldn't use the standard http port, 80, since you might run into conflicts with existing http software). You can do this quite easily in java, using Serversocket and/or Socket (as Tobias Rizau mentions above). Personally, I'd write a C/C++ program, since imo. that makes a better service, but that's absolutely not necessary (especially if you only know Java).
I am writing a flashcard program and would like to see the question on my android phone and at the same time want the answer to pop up on my PC. So the phone needs to push the answer to the PC, which is listening. The entire thing would go through wifi.
My current plan is to build an http server on the PC as a separate java application and use HTTP requests from the phone to push the flashcard answer. Is this a good idea or is there an easier way to do this, without HTTP? I just need to send single strings.
You can use HTTP, just create a TCP Listener on Port 80 and filter header messages out, the android part would be easier, because there are several api functions for http requests.On the other side, a simple TCP Listener on any other Port would be better, because Skype is using for example port 80, and the performance would be a little bit better. The android part isnt much harder, you only have to set up a client on your port, and then send your message to your pc.So i would suggest to use a custom port and a TCP Server on your PC and a TCP listener on android.
I am implementing a real time - multi user voice transfer application for Android.
I have read that, as a standard - RTP packets are encapsulated into SIP and then sent to destination(s). What is the advantage of doing so?
my idea was to use a server, just to receive control messages from nodes and open sockets. All these nodes would be in 1 group. THen, I send out the IP addresses of each of these nodes, so that a single sender can multicast its packets directly to the destination.
is there a fatal flaw here? ( iam not concerned about the power consumption)
How does SIP do better? or does it ?
Thanks
RTP isn't "encapsulated into SIP packets". SIP is a signalling protocol. RTP is a media stream protocol. SIP is used to negotiate and set up (and tear down) media streams.
TCP is a horrible choice for media (RTP) packets; it's not clear from your writing if you're suggesting that.
Multicast is unlikely to work for many network paths/recipients.
routers play merry hell with incoming data; you'll need more than just SIP to deal with users on the open net. See STUN, TURN, ICE, UPnP, etc.
SIP or Session Initiation Protocol is a protocol that was designed specifically to address the problem you're trying to solve. Generally, the reason you should reuse (rather than reinvent the wheel) is because other people have studied the same problem and presumably have come up with a better solution as a collective group than you could as an individual. Of course that's not always true, but generally speaking it holds!
If you want to learn about SIP you could study the RFC 3261 specification, or start with the Wikipedia entry if you want a quick overview.
That being said, if you don't need the overhead of a complete and carefully tested protocol you could roll your own but make sure that when you're making that decision you know what you're foregoing and have a good reason to do so.
SIP is a signaling protocol that usually runs over TCP (although not required) and if you look at it closely you will see it is very similar to HTTP in many respects. Just like HTTP it can transport a great deal of payloads and it does so with text headers, much like HTTP can be used to transport HTML, XML, plain text or any arbitrary binary payload.
In the most simple system, you could just use Voice packets over RTP over UDP.
But you'd have no way to turn audio off, and would have to know IP addresses, port numbers, they type of codec and its characteristics beforehand.
In an overly simple view, SIP is a way to:
1. find the ip address of another endpoint from a URL. (May need STUN, TURN, ICE, etc)
2. agree on which codec to use and its options
There's a lot more to SIP than that, you may want to investigate SIP's conferencing features based on what you wrote.
You may write your own signaling protocol, and if this is for a school project, that will work just fine.
But if you are doing a commercial project, bear in mind that there is a lot more to telephony than meets the eye. The original SIP spec was greatly revised and is now a cluster of RFCs which are still being modified and added to. I recommend that you take advantage of this work rather than possibly reinventing the mistakes others have made.