I'm writing a PMTUD app for both IPv4 and v6. I am doing this on Ubuntu 12.04, but I would like to make it as OS-independent as possible, and that's where I stumbled upon a problem.
IPv6 packets get fragmented by the sender by default, and I do not know how to turn this behaviour off. I found some socket options like IPV6_MTU_DISCOVER and IPV6_DONTFRAG, but I found these under linux/in6.h, which does not help as I'm using the netinet header family and neither of those is under netinet/in.h - although IPV6_MTU_DISCOVER should be there according to this. Am I missing something?
EDIT: Let me clarify a bit then.
I have a socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6) through which I wish to send an ICMPv6 packet of such size that I will receive a reply telling me it's too big, and from that reply I will get the path MTU.
However, to truly get the MTU along the whole path I also have to factor in the outgoing device's MTU.
I am using miredo to tunnel IPv6, which has a set MTU of minimal size, e.g. 1280. Sending a packet bigger that 1280 will result in fragmentation of said packet (this behaviour I observed in Wireshark), but I need the socket to REFUSE to send the packet and inform me about it rather than fragment it.
You do not need to do this yourself. MTU discovery is supposed to happen automatically. As a side effect of this, all devices along the path MUST allow ICMP V6 packets to pass.
IPv6 packets get fragmented by the sender by default
No. TCP packets get fragmented by the sender and intermediate routers by default.
, and I do not know how to turn this behaviour off.
You cannot turn it off. You can certainly try, but the only result will be non-delivery. If a router needs to fragment a packet and you don't permit it, it will drop it instead. However the sending host also needs to fragment, to fit inside the path MTU, and you cannot stop that. If you write the receiver correctly, i.e. in the expectation that it is reading a byte stream rather than discrete messages, it should make no difference to you whether the packets got fragmented in transit or not.
Related
I have found many code examples for sniffing packets through the network, but I am wondering if there is a way to sniff a specific local connection without having to filter by ip or port number. Assuming it will be lighter with less computation.
I thought of a hypothetical solution, forward the the packet to a socket that read the packet then transfer it to it destination by an other socket, like an internal middel man, witch is a heavy and less dynamic solution it will need an interaction with the kernel, :/
Recently we ran into what looked like a connectivity issue when a particular customer of ours installed our product. We ultimately traced it to a low MTU (~1300 bytes) being configured on one of the devices in the network. In this particular deployment, we had two Windows machines running our application communicating with one another, and their link MTUs were set at 1500.
One thing that made this particularly difficult to troubleshoot, was that our application would work fine during the handshake phase (where only small requests are sent), but would sometimes fail sending a specific request of size ~4KB across the network. If it makes a difference, the application is written in C# and these are WCF messages.
What could account for this indeterminism? I would have expected this to always fail, as the message size we were sending was always larger than the link MTU perceived by the Windows client, which would lead to at least one full 1500-byte packet, which would lead to problems. Is there something in TCP that could make it prefer smaller packets, but only sometimes?
Some other things that we thought might be related:
1) The sockets were constantly being set up and torn down (as the application received what it interpreted as a network failure), so this doesn't appear to be related to TCP slow start.
2) I'm assuming that WCF "quickly" pushes the entire 4KB message to the socket, so there's always something to send that's larger than 1500 bytes.
3) Using WireShark, I didn't spot any TCP retransmissions which might explain why only subsets of the buffer were being sent.
4) Using WireShark, I saw a single 4KB IP packet being sent, which perhaps indicates that TCP Segment Offloading is being implemented by the NIC? (I'm not sure how TSO would look on WireShark). I didn't see in WireShark the 4KB request being broken down to multiple IP packets, in either successful or unsuccessful instances.
5) The customer claims that there's no route between the two Windows machines that circumvents the "problematic" device with the small MTU.
Any thoughts on this would be appreciated.
I use wireshark to capture the packets of my computer. I want to get the packets of 219.231.143.116(source ip) ,and my ip is 219.231.143.220(destination ip).
In fact,I got what i wanted, but to my surprise,I got some others' packets.Those packets' source IP and destination IP were not 219.231.143.116 or 219.231.143.220.
As I know,tcp is a 3rd layer in TCP/IP protocol,the switch would not send those packets that don't belong to me. So,the problem is why could i capture them on my computer? Is this the issue of wireshark or the switch?
（Due to my level is too low,so the image is here,i'm sorry!）
http://mysource.lofter.com/post/1cfd51e8_55d5972
The switch decides which packets to send you. You can't change this. You can only filter out (in Wireshark) the packets you don't want to work with.
Wireshark will show you all the packets you actually receive (in promiscuous mode).
All the additional packets you highlight in your image are TCP Retransmission packets. The switch may be casting the packets wider because retransmissions are occuring, so something is timing out. Or, there may be a broadcast or multicast flag set in the packet, as the source attempts to get it's retransmissions heard.
You won't get a lot of packets destined for other computers, and you won't get a complete sequence of sent & received packets belonging to another device (unless you configure the switch to do so with port mirror)
If you really really don't want to see or leak those packets to a particular device, you could use a physical firewall like pfsense or a router between you and the switch, to absolutely filter out multicast traffic originating in your network. This would be an usual use case.
I have an Arduino Uno R3 with an Arduino WiFi shield. The WiFi shield has the most current firmware (V1.1.0). I am trying to send a packet to the router that is about 900 bytes (the packet is for setting up a UPnP port map). This packet is stored in program memory to conserve SRAM. Using strcat_P, I can pull the packet from memory into a buffer and send it using the WiFiClient library (TCP).
The problem is that I can't send the whole packet. For testing, I just send the packet to my computer located on the same LAN where I use a packet sniffer to view the packet. Using WiFiClient.write(), I get differing performance depending on the size of the buffer I use. I seem to get the best performance calling WiFiClient.write() with a buffer size of 80 repeatedly until the whole packet has been "sent". Anything greater than about 80 will cause blank packets on the other end. However, with 80, I usually only see about 500 bytes get transmitted. The packet always gets cut off at an arbitrary point. Does anyone know what could be causing this?
I've did a lot of Googling, and I see others having similar problems. I have never ran across a solution, though.
I know this is old, but I recently found this article which addresses the issue you are describing.
tl;dr - You can only write 90 bytes at a time to the wifi shield's buffer
Is it possible to have libpcap remove a packet instead of just sniff it as it passes through? I'm wanting to intercept each packet and encapsulate it into a new packet along with measurement data, but both packets (mine and the original) both reach the destination.
It's not possible. You need to write a driver (for your operating system) to make the networking stack filter out packets.
The only way you could do this is by being the only physical path between the sender and receiver and turning off packet forwarding on the interceptor.
If you're capturing wireless traffic, there's nothing you can do. No software library can remove radio waves from the ambient air.
No, libpcap cannot "remove a packet".
It's not quite clear what you want to achieve, but it looks like you want to receive data, add some additional information to it, and republish it. If you are working with a datagram protocol such as UDP, then you might be able to simply resend your augmented data to a different UDP port.
In response to Ben S, you can't remove packets off the air, but you can stop them reaching their destination - using ARP cache poisoning etc.
As others mentioned, you can not use libpcap. libpcap is a passive listener. If you are on Linux, you can use a netfilter, which hooks into iptables. Here is an example of how to do that.
http://www.linuxjournal.com/article/7184