I want to capture UDP packets which are destined to a local port, the filtering expression is like udp port 20000. I notice if there are IP fragmentation on a UDP packet, libpcap can only capture the first IP fragment. I guess the reason is the second IP fragment are not with UDP header(I think it is the same for TCP), so libpcap can't capture them using the filter express udp port 20000.
are there any workaround for this? or any other libraries which can capture packets destined to a specific local port?
thanks!
I guess the reason is the second IP fragment are not with UDP header(I think it is the same for TCP), so libpcap can't capture them using the filter express udp port 20000.
Yes, that is correct.
You might try udp port 20000 or (ip[6:2] & 0x1fff) != 0, which will capture packets to or from port 20000 and IP fragments other than the first fragment; that's not ideal, but it's all you can do with libpcap filters, given that the filter mechanism it uses (which is part of the OS kernel) does not maintain any history between packets, and therefore has no way of knowing that a packet with a given IP ID happens to be part of the same fragment as another packet with the same IP ID, a fragment offset of 0, and a UDP header with port 20000.
(Note also that at least some versions of Linux would transmit fragments of an IP datagram in reverse order - in order to allow the recipient to see the last fragment first, and thus to be able to more often correctly estimate the size of the reassembled packet. That would make it even more difficult to capture all the fragments of IP packets with a filter that checks fields in the TCP or UDP header.)
Related
my question as follows Why do we need port when there’s protocol ,- that’s exactly defining what are the terms of transferring or receiving data
Did not actually get it, i am new to web processes:)
A protocol is a specification for how two devices should exchange data in a way that they can both understand. A port is kind of a numbered 'tag' that helps a computer decide who should receive an incoming piece of data.
Many protocols have a port that they run on by default; this makes it easier to discover them or configure applications that use them. But that's not a hard rule; they could always listen on a different port, as long as anyone contacting them knew about the change.
A protocol is an agreement on how to interpret data and how to respond to messages. They generally specify message formats and legal messages. Examples of protocols include:
TCP/IP
HTTP
SSH
A port is part of socket end point in TCP and UDP. They allow the operating system to distinguish which TCP or UDP service on the host should receive incoming messages.
The confusion generally arises because, a number of ports are reserved (eg. port 80) and are generally listened to by severs expecting a particular protocol (HTTP in the case of port 80). While messages send to port 80 are generally expected to be HTTP messages, there is nothing stopping an non-HTTP server from listening on port 80 or an HTTP server from listening on an alternative port (for example 8080 or 8088).
I had written a code for micro-controller in which HTML text is sent on a LAN to browser via Ethernet,the code works fine until the Ethernet frame size exceed to 1500 bytes.
Is there any way of sending HTML text to browser successfully in a fragments via Ethernet?
CASE: If text is fragmented prior sending!
The Browser in this case only display's first part of text fragment. While the rest fragments aren't updated on the browser.
Any support in this regard would be appreciated!
I'm assuming you are using a TCP stack and have not attempted to write the TCP/IP headers directly with your own code on the device. Then your problem most likely has to do with the Ethernet MTU (maximum transmission unit).
MTU is the maximum payload that can be transmitted (and received) by all devices on the network. Typical MTU size is 1500 bytes, but unfortunately it is common to have networks that require a lower MTU (e.g. when PPPoE or VLAN headers get added at some point). Usually it is just a configuration problem. Most Ethernet hardware supports MTUs well over 1500 bytes.
What usually happens is that as soon as TCP attempts to send a packet that is too large, it gets dropped at some point (sender, receiver, switch or router). A packet sniffer like Wireshark will do TCP analysis and tell you about suspected packet loss and TCP retransmission attempts.
It's TCP that is is splitting a stream into packets, so the TCP stack needs to know what the MTU is. On Linux the TCP stack it will get this setting from the network interface. You can see the current value with ip link or ifconfig. It needs to be configured on both sides of TCP the connection, but your problem should go away by just setting a lower MTU in the TCP stack of the embedded device.
In addition to that, IP fragmentation can happen when a router wants to forward a frame from a network with high MTU to a network with lower MTU (or if it has added another Ethernet header, and the frame is now too large). Unless you are using a very poorly implemented IP stack that doesn't support fragmentation, this should not be a problem. (But it's wasting bandwidth.) Depending on the flags, the router may then send an ICMP message to notify the sender about the problem. But if there is a firewall in-between that drops ICMP packets this will not work, and result in retransmission attempts without lowering the MTU.
I want to make multiplayer game, and I want it to use UDP sockets. Because of that, I want to use DatagramSocket. The problem is that DatagramSocket needs to be bound to a port on both sides. Is there a way to create a server - client program with UDP that does not need the client to portforward? (Like Serversocket and Socket).
Remember that UDP is connectionless. You send a packet of data to some IP address and hope it knows what to do with it once it gets to the targeted machine. But actually once it's on the machine it has no idea where to go from there, is there an application that's interested in these packets? And this is precisely why you need to specify a port number that is registered to forward packets to specific application on the machine.
Send a packet to myself to the application running on port 7000: 127.0.0.1 : 7000
I've looked through posts with no real answer to this question: is the address 127.0.0.1 a hardware set address much like promiscuous mode is a hardware setting on devices? I've tried to set my address to 127.0.0.1 on eth0, disable the lo, and even change the lo address, to make packets go out the eth0 port with address 127.0.0.1. The packets always end up on the lo port when I use sniffing tools like wireshark. Is there a way to do this, is this hardware or hardcoded into the drivers?
The loopback address is controlled by software (e.g. in the kernel). It is never associated with any hardware.
You don't specify your operating system, but unless it's very unusual, there really isn't a way to do what you ask (have packets addressed to 127.0.0.1 appear on an external interface).
Update:
Here's the spec:
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
I know the ICMP request contains the IP address. Is the client MAC address included in an ICMP request? What other info (if any) is included in a ping request?
An ICMP request is a layered packet which is sent over the internet. It contains the Ether layer, which has the target and source MAC address in it. It also contains the IP layer, which has the source and target IP and also a couple of flags included. And at last it contains the ICMP data. This contains a type, a subtype, then a checksum and the rest of the header, which can vary from type and subtype (E.g. The code for echo is 8 and reply is 0).
There is a lot of information in a network packet. Also note that ICMP is an part of the IPv4 protocol, so it cannot officially be carried by other protocols. Although the IP protocol can be carried on a different protocol than the ethernet protocol.
The MAC address will be changed after each passing of a router. So this is never the MAC address of the source IP address on the internet. But the IP address is definitely included and on a local network, the mac address of the client is still in the packet in the Ether layer.
Wikipedia has some readable article about ICMP packets: icmp message and different protocols with readable diagrams.
If you want to see some live requests, you can install wireshark, which will show and dissect all network traffic for you. It is a very convenient and cool tool.
The ICMP 'ping' packet, officially known as 'echo request', contains whatever the originating ping executable wants to have echoed back to it. In the Bad Old Days when the internet was first getting started up, the routers they had (and all computers, really) were subject to random memory failures. In order to detect that the path between two systems was clear, they would send echo request packets and compare the contents of the request with the reply. If the contents differed, they knew that there was a problem with either of the machines involved, or the routers in between.
It's impossible to state here categorically exactly what's in any given ping packet because it changes between implementations of ping.
It is usually not possible for a person to get the MAC address of a computer from its IP address alone. These two addresses originate from different sources. Simply stated, a computer's own hardware configuration determines its MAC address while the configuration of the network it is connected to determines its IP address.
However, computers connected to the same TCP/IP local network can determine each other's MAC addresses.
Look RFC 792 for full ICMP fields.