according to some references Class C for example can provide 2^8 hosts (mask /24), according to others it can provide 2^16 hosts (mask /16).?
so what is the real mask of C class ??
from the Protocol IPv4 Specification in RFC 791 publication:
Address Formats:
High Order Bits Format Class
--------------- ------------------------------- -----
0 7 bits of net, 24 bits of host a
10 14 bits of net, 16 bits of host b
110 21 bits of net, 8 bits of host c
111 escape to extended addressing mode
-- RFC 791 - Addressing
so, for class C
address | N.N.N.H (N network bit, H hosts bit)
mask | 11111111.11111111.11111111.0000000 (/24)
# of address | 256 (2^8)
# of hosts | 256 (2^8 – 2)
Update
after rechecking the image that was associated with the OP post, I noticed that his confusion comes from Reserved IP addresses notion, and precisely the 192.168.0.0/16address block. and my accepted answer wasn't explaining that properly ^^"
TL;DR:
192.168.0.0/16 isn't a single C class network number with a /16 host mask, but a set of 256 class C network numbers
Explanation
given the my original answer.
C class addresses form:
110xxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
+------------------------+.+------+
net host
C class addresses range
net host
+-------------------------+.+------+
from: 110 00000.00000000.00000000.00000000 (192.0.0.0)
to : 110 11111.11111111.11111111.11111111 (223.0.0.0)
+++ -----.--------.--------.--------
form this whole range, there are reserved IP addresses blocks, for various propose. cf. reserved IP addresses blocks
among this reserved blocks there is:
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
reserved for Private Network according to RFC 1918, and defined as: "a set of 256 contiguous class C network numbers.".So:
192.168/16
192.168.0.0/24 (254 host)
...
192.168.255.0/24 (254 host)
You can visualize it as:
net host
+-------------------------+.+------+
+++ -----.--------.--------.-------- <- C class
from: 110 00000.10101000.00000000.00000000 (192.168.0.0)
to : 110 11111.10101000.11111111.11111111 (192.168.255.255)
+++ +++++.++++++++.--------.-------- <- /16 mask
Related
Through an accidental typo I've realized that when you try to reach the ip address 127.0.01 it will successfully route to 127.0.0.1.
Playing around with this, I've noticed that there seems to be some kind of translation happening. Some examples:
127.001 -> 127.0.0.1
127.002 -> 127.0.0.2
127.011 -> 127.0.0.9
127.111 -> 127.0.0.111
127.1111 -> 127.0.4.87
127.9999 -> 127.0.39.15
What's the logic behind these translations? I've tried and replicated this on MacOS, Linux and Windows.
From wikipedia:
When fewer than four numbers are specified in the address in dotted notation, the last value is treated as an integer of as many bytes as are required to fill out the address to four octets. Thus, the address 127.65530 is equivalent to 127.0.255.250.
You can do the calculation yourself to check.
Example:
127.9999 = 01111111. 00000000 00100111 00001111
= 127.0. 39. 15
In Operating Systems Design and Implementation by Andrew S. Tanenbaum and Albert S. Woodhull, there's the following fragment:
In MINIX 3 every file has an 11-bit mode used for protection. Nine of these bits are the read-
write-execute bits for the owner, group, and others.
And then, a few lines after, they write:
The other two protection bits, 02000 [octal 200] and 04000 [octal 400], are the SETGID (set-group-id) and SETUID (set-
user-id) bits, respectively.
But Python shows that octal 400 is a 12-bit long mask:
>>> len(str(bin(0o4000))) - len('0b')
12
How can a 12-bit long mask be applied on a 11-bit field?
01000 is the "sticky" bit in Unix, and Minix didn't support it at the time the book was released. It didn't add support until 2010 (the book was released in 2005).
This is with respect to a Wireshark Packet Capture Filter.
IP packets whose IP version is not 4
Solution :
Filter:
ip[0] & 0xF0 != 0x40
ip[0] & 1111 0000 != 64
Could anyone please provide clarity on how the above solution could be inferred?
Thanks in advance,
Adam
According to the IPv4 packet structure:
You have the version in the first octet, in the upper nibble. Version for IPv4 packets is "4" as you can see in the picture, but remember it has to be in the upper nibble, hence the 0x40 in the filter (64 in decimal base).
So what your filter do is grab the first byte of the IP header and AND it with 0xF0 to be sure it's keeping the version part (upper nibble) and then check if it is different from 0x40 (IPv4 packet).
What you could also have done is:
ip[0] & 0xf0 == 0x60
Which is the same as saying, keep only IPv6 packets. Version in a IPv6 packet is equal to 6. The position of the version information is the same as for a IPv4 header:
I used ethereal to capture some packets and I'm trying to make sense of the data. This is the output of 1 of the frames.
0x0000: 4500 003a 4564 4000 4006 df05 0a01 012b E..:Ed#.#......+
0x0010: 0a01 0128 bfcf 3a98 e938 b9c8 e8a0 761f ...(..:..8....v.
0x0020: 8018 05b4 ef33 0000 0101 080a 0005 ff31 .....3.........1
0x0030: 0005 2c31 6865 6c6c 6f0a ..,1hello.
The characters on the right is the ascii representation of the info on the left (Which is hex). The message being sent is "hello" and the rest of the information (or atleast some of it) is the header, right? What's the format of the header? I did some googling and found that this image: http://electronicdesign.com/site-files/electronicdesign.com/files/archive/electronicdesign.com/files/29/2099/figure_03.gif. Is this correct? According to the image, bytes 27-30 (761f 8018) are the destination IP but converting the hex to decimal doesn't end up being my ip. Am I missing something or am I completely wrong? Also how would I find the protocol number?
Are your source ip 10.1.1.43 and destination ip 10.1.1.40?
I believe the info shown is not the ethernet frame, it is an IP package. The first octet is already the IP header.
To get a quick reference to the IP and TCP headers, you can use wiki
http://en.wikipedia.org/wiki/IPv4#Header
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure
But if you want more details and reliable information, you should check the RFC directly.
https://www.rfc-editor.org/rfc/rfc791#section-3.1
https://www.rfc-editor.org/rfc/rfc793#section-3.1
If I rearrange your data in a 4 octets per row format
4500 003a total length
4564 4000 fragment
4006 df05 header checksum
0a01 012b source IP
0a01 0128 destination IP
bfcf 3a98 ports
e938 b9c8 seq
e8a0 761f ack
8018 05b4 windows
ef33 0000 checksum
0101 080a
0005 ff31
0005 2c31
6865 6c6c
6f0a
The first octet is 4 so you should be using IPv4. On the 3rd row, the second octet is 6. This is the protocol number for TCP. From these two hints i guess this is IP package not ethernet package.
And about ethereal, Remy is right, Use Wireshare https://www.wireshark.org/
I need to work out the algorithm regarding how you calculate the network and host portion of an IP address.
Is the host ID the public part? Is the network ID the private part for locating the computer within the local network?
If the subnet mask is a value smaller than 255 the corresponding octet in the IP address must be broken down into binary to determine which part of the number is the host ID and which portion is the network ID. Is the result binary number always split in two?
(e.g. An IP address of 192.168.33.22 with a subnet mask of 255.255.224.0 means that the octet holding 33 be broken down as follows: 0010|0001 indicating that 0010 is the network ID portion and 0001 is the host ID portion?)
Thank you in advance for any help.
You're over-complicating things.
IPv4 addresses (and subnet masks) are merely displayed in dot-decimal notation simply as a means of making them more readable to humans. Within the computer, they are simply 4 bytes of contiguous memory (often stored, for example, within a long int):
Stored in computer: 11000000 10101000 00100001 00010110
Displayed for human: 192. 168. 33. 22
Stored in computer: 11111111 11111111 11100000 00000000
Displayed for human: 255. 255. 224. 0
The 1s in the mask indicate bits that identify the network, thus one merely need use a bitwise AND operation to extract the "network number":
address 11000000 10101000 00100001 00010110 192.168.33.22
mask 11111111 11111111 11100000 00000000 255.255.224.0
(AND) ----------------------------------- -------------
network 11000000 10101000 00100000 00000000 192.168.32.0
Since the introduction of CIDR (prior to which the address's class indicated the network/host boundary), hosts usually only know the mask of their own network and are therefore unable to divide arbitrary addresses (e.g. that of a datagram's destination) into network and host numbers.
So what's the point? Well, a source host can still take the bitwise AND of the destination's address and its (the source's) own network mask. Whilst the result of that operation will not necessarily produce a meaningful network number, it will match the source's network number if and only if they are on the same network:
if they match, the destination should be reachable at the link layer (e.g. by looking up its MAC address, perhaps via broadcasting an ARP request, and then encapsulating the datagram in a frame that is addressed to that MAC);
if they differ, the source must send the datagram to a router that is on its own network (using the above process to reach that router); the router will see that the frame is addressed to it, but that the datagram is not, and should then forward the datagram (encapsulated in a different frame) towards the destination. Many hosts only know of one router, their "default gateway", although other configurations are possible.
Those address bits that don't identify the source's network, evidently indicated by 0s in its network mask, can be considered to form its "host number"—although it's really neither meaningful nor useful to extract it in the same way as was done above: even when communicating with a host on one's own network, its full address is used for identification, never the host number alone.
That said, as a purely academic exercise it is of course possible to perform a bitwise AND with the complement of the mask:
address 11000000 10101000 00100001 00010110 192.168.33.22
~mask 00000000 00000000 00011111 11111111 0.0.31.255
(AND) ----------------------------------- -------------
host 00000000 00000000 00000001 00010110 0.0.1.22
So, to address your questions:
Is the host ID the public part? Is the network ID the private part for locating the computer within the local network?
The entire address is "public"; there are no "private" parts. Lookup protocols like ARP (which uses the full address) are used to locate computers within the local network.
If the subnet mask is a value smaller than 255 the corresponding octet in the IP address must be broken down into binary to determine which part of the number is the host ID and which portion is the network ID. Is the result binary number always split in two?
Nothing is "split in two". It only appears that way because dot-decimal notation was intended to make IPv4 addresses more readable to humans (albeit that decision was taken prior to the invention of CIDR, when network numbers were always aligned to byte boundaries and thus never caused the apparent "split" of a decimal number).
Is the host ID the public part? Is the network ID the private part for locating the computer within the local network?
The host and network portions of an ip address have nothing to do with public and private.
If the subnet mask is a value smaller than 255 the corresponding octet in the IP address must be broken down into binary to determine which part of the number is the host ID and which portion is the network ID. Is the result binary number always split in two? ...a subnet mask of 255.255.224.0 means that the octet holding 33 be broken down as follows: 0010|0001...
Your example is wrong. Specifically, you assume that 224 has four consecutive binary bits in it when you spit the 33 octet as 0010|0001 (where | is the division between network and host)...
The octet in the subnet mask containing 224 has three consecutive binary 1s in it: 11100000. Therefore the "network portion" of the whole IP address is: 192.168.32.0. The "host portion" of the ip address is 0.0.1.22. Using your notation, the third octet of ip 192.168.33.22 (mask 255.255.224.0) is: 001|00001.
To get the network portion of an IP address, you must perform a binary AND of the ip address and its netmask. The host portion is a binary AND of the inverted netmask (bits flipped between 0 and 1).
EDIT
Let's make another example to address your comment:
IP Address 192.168.255.22, NetMask 255.255.224.0
The network portion of this address is 192.168.224.0 and the host portion of the address is 0.0.31.22. I intentionally chose the numbers in the example to make the math as obvious as possible. Please convert 224 and 31 to binary, it should make things clear. If not, please reference the wikipedia article on subnetting
Host address portion and network address portion can be easily identified.
Use this trick.
Class A: N.H.H.H
Class B: N.N.H.H
Class C: N.N.N.H
(N= network H=Host)
Class A network range: 1-127
Class B network range: 128-191
Class C network range: 192-223
Reference: https://www.youtube.com/watch?v=ddodZeXUS0w
You can use the following script:
#!/bin/sh
GetNumericIP()
{
ipbin=0
for part in `echo $1 | awk -F'.' '{print $1 " " $2 " " $3 " " $4}'`
do
ipbin=`expr $ipbin \* 256`
ipbin=`expr $ipbin + $part`
done
echo "$ipbin"
}
GetSrtingIP()
{
ipbin=$1
count=0
while [ $count -le 3 ]
do
rem=`expr $ipbin % 256`
ipbin=`expr $ipbin / 256`
if [ -z "$ipstr" ]
then
ipstr=$rem
else
ipstr=`echo ${rem}.${ipstr}`
fi
count=`expr $count + 1`
done
echo $ipstr
}
mask=$2
maskbin=`GetNumericIP $mask`
ip=$1
ipbin=`GetNumericIP $ip`
networkid=$(( $maskbin & $ipbin ))
networkid=`GetSrtingIP $networkid`
echo "networkid = $networkid"