For reasons I can't go into, our system uses a very small MTU (128 bytes). These embedded devices are on a completely separate network so no internet access or interaction with other devices.
Obviously, TCP takes up 66 bytes per packet leaving not very much for payload.
After some googling, I came across IPCOMP which looks like it may help in reducing the amount of traffic on the network.
My question is how can I enable this? Is there a setsockopt, or do I need a special driver?
The only example I've seen is:
socket(PF_INET, SOCK_RAW, IPPROTO_COMP)
but this means I need to create the IP/TCP/payload manually.
Anyone have experience with this.
EDIT: Perhaps a better method would be to enable cslip or ppp on this connection. I can find tutorials on enabling PPP on a serial port (for dial-up modem), but nothing on enabling PPP on ethernet.
I've seen articles on PPPoE, but this seems to add MORE to the payload rather than reducing it.
Can anyone help with this?
I've played around with IP xfrm in the past but I've never tried the comp option. If you want all outgoing traffic compressed, something like this would work.
ip xfrm policy add dev eth0 dir out tmpl proto comp
Related
I investigated a lot about this topic but most of the guides just teach how to exchange data between devices on the same network and, regarding exchanging data between devices on different networks, no source was totally clear to me. I hope with this question somebody can give me (and other users) a good overview. If you have any guide or book about it I’d be super interested (for Java would also be fine).
First of all I’m interested in the difference between programs that
need to exchange data quickly (it may be an online videogame) versus
programs that need to exchange data accurately (it may be a message
app). My understanding is that the difference between the two is the
protocol used: in the first case is UDP (where no checks are done to
ensure there is no packets loss), in the second case is TCP (where
checks are done and data is exchanged more slowly). Is this correct?
So in an hypothetical Python script in the first case the socket
created would look like this:
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
While in the second case would look like this:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
My understanding is that to exchange data between different networks
you have to use port forwarding (very good explanation here),
concept that is clear to me. However, do you have any source that
suggests how to do it in Python? Also, is port forwarding
everything you need to do in order to exchange data between
different networks? Finally, I’m not sure I understand the role UPnP
plays in port forwarding. Based on this question it seems UPnP
is a way to automatically port forwarding. Is it correct? Can I use
miniupnpc library to do it automatically?
Finally, if I switch off and on my router, the private IP addresses
assigned to the devices connected to the network change (so the
private IP of my phone connected to my home WiFi could change, for
example, from 192.168.1.2 to 192.168.1.11). Does this represent a
problem in networking programming? If I set on the router a certain
port and the traffic that comes to that port is directed to a
certain private IP address and then this IP changes I suppose there is a
problem. Is this correct? If it is what is the solution?
Your understanding of use cases for UDP and TCP seem roughly
accurate. UDP ensure lower latency (not always) so for apps that
require lowest latency possible while also not caring about missed
packets, UDP is used. So if you think about video streaming, once a
packet is missed, it makes no sense to hold up every future packet
for that one old packet. This is because a small amount of data that
is missed doesn't really affect a user's watching experience. For
gaming, we want the newest data as soon as possible, so waiting for
old data also doesn't matter. But if you're implementing a protocol
or something that requires all data to be transmitted, TCP makes
sense since its absolutely vital that all information gets to the
receiver and in order.
There are a few methods to exchange data between two private networks. Port forwarding is certainly one method, and both machines on either network would have to have port forwarding. I don't know anything about automated port forwarding like you mention, but you can go into your router settings and set it up pretty easily. Another method of talking across networks is something like webRTC. Its a protocol that uses the STUN TURN and ICE protocols to perform something called NAT traversal. Short story shorter, it tricks your routers into letting your machines talk to each other(analogous to temporary port forwarding).
You're right that this could be an issue. However you should be able to setup static IP addresses in your router. So you can assign one machine to have a static IP address, setup port forwarding, and bam you have a permanent(hopefully) open connection.
I have been experimenting with ARP spoofing on my local LAN.
Now, I would like to try to write in C a simple sniffer, but I have some questions:
If the ARP spoofing has been a success my NIC will receive and not drop packets that have my MAC ADDRESS (Layer 2) but a DST IP (Layer 3) which is not mine. What kind of sockets can I use to take those packets? I think some sort of RAW sockets, but an example or a good reference would be appreciated.
Is there a way (throw C) to put my NIC in promiscuous mode in order to force it to pick up packets with different MAC?
After some investigation I think the best way is to use libcap http://man7.org/linux/man-pages/man3/libcap.3.html, which comes with good routine to call.
Problem
I have just started to scratch the surface of this topic so excuse me if I'm formulating the question a bit strange and novice. Let's say I'm on a wireless network which I am right now, and I want to see all the data that is flowing in and out of this network from other clients connected to the network. I remember reading a book about someone doing this while being connected to the Tor network and it got me thinking about how this is done.
Questions
A: what is this process called?
B: How is it done?
Wireshark can do this:
http://www.wireshark.org/
It sniffs packets in "promiscuous mode":
http://en.wikipedia.org/wiki/Promiscuous_mode
That lets you see all the packets routed through a specified network interface, not just the packets targeted to a particular client.
A: It's call packet analyzing / packet sniffing.
B: In an unswitched network (e.g. a wifi network or hub), all you need is a network card that supports promiscuous mode and some software, as mentioned by sdanzig.
In a switched environment (e.g. most modern wired networks), you need to use a Layer 3 switch and set it up to mirror the traffic you're interested in to the port to which you are connected. (Otherwise your network adapter won't 'see' the other traffic.)
Some tools:
http://www.dmoz.org/Computers/Software/Networking/Network_Performance/Protocol_Analyzers/
Related topics on SO:
https://stackoverflow.com/questions/tagged/packet-sniffers
https://stackoverflow.com/questions/tagged/packet-capture
I have a Linux router on which I use CONFIG_IP_NF_QUEUE, iptables userland and Perl module IPTables::IPv4::IPQueue to examine H323 - H.225 packets and pass or drop then. I have need to not only accept or drop the packet but to modify it, to be more specific I would like to change the IP address of the MCU (in the packet) returned from the H323 gatekeeper to the client.
This would require me to examine the TCP packet body and change the IP address in the packet body. Anyone know how can I accomplish this? Is there any open source layer 7 router capable of doing this?
In the old days I've used "ip masquerade" to do something similar to what you are describing.
http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/supported-client-software.html
But the best solution is to place a gatekeeper as a proxy. In that way you are not fooling the protocol, you are actually remaking the call.
I would look for gnugk routed mode here:
http://www.gnugk.org/h323-proxy.html
If you have already got the IP packet, which from your statement you have succeeded in doing so, I don't see the problem to change the IP address of the packet before passing it on.
Just do some bits manipulation to change the IP address in IP header (also update the IP checksum). Also note that you have to update the TCP header checksum as its calculation involves a pseudo-header that includes IP addresses.
Just read RFC 791 and RFC 793 would give you an idea on how to do this. It's pretty straightforward.
I was wondering if there is any way to tune (on a linux system), the MTU for a given socket. (To make IP layer fragmenting into chunks smaller that the actual device MTU).
When I say for a given socket, I don't mean programatically in the code of the application owning the socket but rather externally, for example via a sysfs entry.
If there is currently no way do that, do you have any ideas about where to hook/patch in linux kernel to implement such a possibility ?
Thanks.
EDIT: why the hell do I want to do that ?
I'm doing some Layer3-in-Layer4 (eg: tunneling IP and above through TCP tunnel) tunneling. Unlike VPN-like solutions, I'm not using a virtual interface to achieve that. I'm capturing packets using iptables, dropping them for their normal way and writing them to the tunnel socket.
Think about the case of a big file transfer, all packets are filled up to MTU size. When I tunnel them, I add some overhead, leading in every original packet to produce two tunneled packets, it's under-optimal.
If the socket is created such that DF set on outgoing packets you might have some luck in spoofing (injecting) an ICMP fragmentation needed message back at yourself until you end up with the desired MTU. Rather ugly, but depending on how desperate you are it might be appropriate.
You could for example generate these packets with iptables rules, so the matching and sending is simple and external to your application. It looks like the REJECT target for iptables doesn't have a reject-with of fragmentation needed though, it probably wouldn't be too tricky to add one.
The other approach, if it's only TCP packets you care about is you might have some luck with the socket option TCP_MAXSEG or the TCPMSS target if that's appropriate to your problem.
For UDP or raw you're free to send() packets as small as you fancy!
Update:
Based on the "why would I want to do that?" answer, it seems like fragmenting packets if DF isn't set or raising ICMP "fragmentation needed" and dropping would actually be the correct solution.
It's what a more "normal" router would do and provided firewalls don't eat the ICMP packet then it will behave sanely in all scenarios, whereas retrospectively changing things is a recipe for odd behaviour.
The iptables clamp mss is quite a good fix for TCP over this "VPN" though, especially as you're already making extensive use of iptables it seems.
MTU is a property of a link, not socket. They belong to different layers of the stack. That said TCP performs Path MTU discovery during the three-way handshake and tries very hard to avoid fragmentation. You'll have hard time making TCP send fragments. With UDP the easiest is to force some smallish MTU on an interface with ifconfig(8) and then send packets larger then that value.