I need to determine whether an ip packet is dhcp or not. My approach is as following
ipheader protocol is udp
upd header src and dst port is 67/68.
Is it accurate enough for determining a dhcp?
Thanks very much
Related
I made a tcpdump and captured packets, the configured MTU is 2140. I am analysing pcap files using Wireshark.
According to the configured MTU the expected maximum size of the packets should be 2154 (2140 bytes +14 ethernet header bytes). But I see packets of size greater than 2154 (ex 9010 bytes), On analyzing I found that these packets are generated on the machine where I made tcpdump (let's say A) and have the destination to another machine (let's say B). I expect a packet to be fragmented before it is sent to another host. I found some explanations online that says tcpdump captures packets before NIC breakdown, though this seems to be a valid explanation but it seems to contradict in my case because on machine A, I received packets of size greater than 2154 from B. Any thoughts, on why machine A is sending and receiving packets greater than configured MTU.
What you are seeing is most likely the result of TCP Segment Reassembly Offloading. This is a feature available on some network cards with matching drivers.
The idea is that the reassembly of many of the TCP segments is handled in the NIC itself. This turns out to be pretty effective in reducing overhead on the CPU/OS side since the network driver need only handle, perhaps, 1 "packet" out of 10, seeing just one large packet, rather than receiving and reassembling all 10.
You can read more about it here.
Updated answer
If your packet is UDP
This behaviour is normal. but there is not much you can do to see the individual packets on the end machines. The UDP packet is broken down into MTU compliant packets and reassembled at the Link layer, usually by specific hardware. This is too low to to be captured by Wireshark/pcap.
If you want to capture the individual broken down packets, you have to do this on an intermediate machine/network card, for example a gateway between the two hosts, because the original UDP packet is not reassembled until it reaches its final destination. Note : this gateway can be virtual.
See notes.shichao.io/tcpv1/ch10
Leaving this here in case someone with the same problem comes...
If your packet is TCP :
It sounds like Wireshark is reassembling packets for you. This is often the default for TCP streams. You can change this by richt-click on a stream -> Protocol Preferences -> Allow subdissectors to reassemble TCP.
Referring to Section 29.3.3.3. Managing ICMP of the FreeBSD Handbook, I see the following text with example:
One solution is to let all ICMP traffic from the local network through
while stopping all probes from outside the network:
pass inet proto icmp from $localnet to any keep state
pass inet proto icmp from any to $ext_if keep state
I read this as:
"Pass IPv4 ICMP packets which originate from $localnet to any host/port, and keep the state.
Pass IPv4 ICMP packets which originate from any host/port to $ext_if, and keep the state."
How does this stop probes from outside of the network? I have limited understanding but it is leading me to believe that the second rule is actually allowing probes from outside of the network.
Is it, and if not, how should I be reading that rule?
From what I can see (and I am most definitely not a FreeBSD or PF guy), the base pf.cfg that you create in step 29.3.3 includes block in all. If I understand correctly, this basically makes the PF filter a default-deny, and only permits traffic which is expressly allowed (using pass rules). Therefore, the pass rule will permit all outbound ICMP packets (and their replies), allow all inbound ICMP packets that have a destination IP of $ext_if only, and all other ICMP packets will be blocked by the default block in all.
This particular setup makes the most sense in a non-NATting gateway, as when NAT is in effect external nodes cannot ping internal nodes whether these rules are enabled or not.
Feel free to correct me if mistaken, as is very possible.
I would like to do a scan in a LAN network to find devices linked.
I'm developping an app in IOS for IPAD
How do I do???
Because those are mobile devices I will assume you want to find devices on a wireless network. Theoretically, since wifi uses shared medium for communication, you can passively listen for traffic flowing through the network and collect data about client without sending any packets. This is something that is commonly referred to as a promiscuous mode. In practice there is 99% chance that the network adapter driver will allow you only to get traffic destined for your MAC address. In that case you will need to resort to actively scanning the network subnet which is not 100% accurate and depending on how the network is implemented can be considered as a possible attack.
The simple way of scanning is sending ICMP requests (ping) to every IP address in the subnet and collecting data from those who send back the echo reply. This is not reliable because some hosts won't respond to ICMP echo request even if they are active. First thing you need is to find out your own IP address and the subnet mask, and calculate the range of possible addresses in your subnet. The range is obtained by using logical AND operator where operands are binary values of your IP address and subnet mask. This is an example from the program that calculates this for typical 192.168.1.1 subnet with 255.255.255.0 subnet mask (192.168.1.1/24 in CIDR notation):
Address: 192.168.1.1 11000000.10101000.00000001 .00000001
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111 .00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000 .11111111
Network: 192.168.1.0/24 11000000.10101000.00000001 .00000000
Broadcast: 192.168.1.255 11000000.10101000.00000001 .11111111
HostMin: 192.168.1.1 11000000.10101000.00000001 .00000001
HostMax: 192.168.1.254 11000000.10101000.00000001 .11111110
Then you would iterate through the range and ping every address. Another thing you can consider is listening for broadcast traffic such as ARP and collecting some of the information that way. I don't know what are you trying to make but you can't get many useful information this way, except for vendor of a host's network adapter.
Check my LAN Scan on Github. It does exactly what you want.
I recently used MMLANScan that was pretty good. It discovers IP, Hostname and MAC Address.
Bonjour have been around since 2002, have a look at it!
I mean, just look at their current tagline:
Bonjour, also known as zero-configuration networking, enables automatic discovery of devices and services on a local network using industry standard IP protocols. Bonjour makes it easy to discover, publish, and resolve network services with a sophisticated, yet easy-to-use, programming interface that is accessible from Cocoa, Ruby, Python, and other languages.
I am looking for a way to detect if any incoming or outgoing network traffic is PPP (Point to Point). Is there a way that I can sniff for this type of traffic using the pcap library?
The reason I need to know if the traffic is PPP to validate a certain condition. That condition is if the DC (Demand-Circuit) bit in the Options Field of OSPF is enabled, then PPP must be enabled for that network. Only point-to-point networks receive the full benefit of OSPF Demand-Circuits (RFC 1793).
"Point-to-point", in RFC 1793, doesn't refer to particular types of traffic, it refers to particular types of networks. All traffic on, for example, a serial line running the Point-To-Point Protocol, is "point-to-point traffic"; no traffic on an Ethernet is "point-to-point". Non-point-to-point traffic could be tunneled over a point-to-point network, and point-to-point traffic could be tunneled over a non-point-to-point network, but, in the case of a tunnel, there will often be a network interface (in the software sense, e.g. what ifconfig -a would list in most UN*X systems or ipconfig/all would list on Windows) for the tunneled traffic, in addition to a network interface for the lower-level network's adapter.
On most UN*Xes, you can use the SIOCGIFFLAGS ioctl to get the flags for a network interface, and one of those flags is the IFF_POINTOPOINT flag, which would indicate whether the network for that interface is a point-to-point network or not.
On Windows, I can't find an ioctl to get the flags for a specific interface, but the SIO_GET_INTERFACE_LIST Winsock ioctl will return an INTERFACE_INFO structure with an iiFlags member that includes the IFF_POINTOPOINT flag.
If suppose client does not listen on 68 port,when DHCP server receives the request, it can send it to the address from where it received request (with ephemeral port chosen by client at time of sending), then why does protocol specifies client to be listening on port 68?
The main reason is that the DHCP server might broadcast the "DHCP offer" on the mac level, instead of sending it unicast to the mac address it had received the request.
If the port wasn't constant, some hosts that are listening by chance to the this same random port, will accept the packet to layer 5 - the application layer.
In other words, an application will get message from completely different application, not an healthy situation.
I just had to face the same question myself, and after some research, I found the following on the RFC 2131, which describes the DHCP protocol, under section 1.6 Design Goals:
DHCP must provide service to existing BOOTP clients
Also on the RFC 951, which describe the BOOTP protocol, we can find the following:
The UDP header contains source and destination port numbers. The
BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
and 'BOOTP server' (67). The client sends requests using 'BOOTP
server' as the destination port; this is usually a broadcast. The
server sends replies using 'BOOTP client' as the destination port;
depending on the kernel or driver facilities in the server, this may
or may not be a broadcast (this is explained further in the section
titled 'Chicken/Egg issues' below). The reason TWO reserved ports
are used, is to avoid 'waking up' and scheduling the BOOTP server
daemons, when a bootreply must be broadcast to a client. Since the
server and other hosts won't be listening on the 'BOOTP client' port,
any such incoming broadcasts will be filtered out at the kernel
level. We could not simply allow the client to pick a 'random' port
number for the UDP source port field; since the server reply may be
broadcast, a randomly chosen port number could confuse other hosts
that happened to be listening on that port.
So the answer to the question comes from the above. DHCP clients need to use the UDP port 68, in order for the DHCP to be compatible with the BOOTP protocol and the BOOTP protocol requires a specific port for the client, since BOOTPREPLIES can be broadcasted, and if a random port was chosen for the client, it could result in the confusion of other hosts listening on the same port.
Because it's in the RFC (Request for Comments) that specifies how DHCP behaves. RFC 2131 is the document that specifies how a DHCP client and server must behave.
See here for more info on DHCP (section 4.1 in particular). See here for info on what the RFCs are.