I need help with this:
Assume that you have been assigned the 200.35.1.0 /24 network block
Define an extended network prefix that allows the creation of 20 hosts on each subnet.
I've written the addresses in binary form:
IP: 1100 1000 . 0010 0011 . 0000 0001 . 0000 0000
Mask: 1111 1111 . 1111 1111 . 1111 1111 . 0000 0000
extended network prefix must be:
New Mask: 1111 1111 . 1111 1111 . 1111 1111 . xxxx xxxx
I know that 2^value - 2 = subnets
But how do you know how many it requires? The subnets are not given.. Help?
The next largest power of 2 from the required 20 hosts is 32.
32 is 2^5.
There are 32 bits in an address or mask.
32 bits for the mask size - 5 bits for the subnet size = 27 bits for the mask length
A 27-bit mask is 11111111.11111111.11111111.11100000
Take the original subnet, AND it with your mask to get the first subnet
Add 32 for each successive subnet
Convert the binaries back to decimal
Related
We are using Erlang version 22. We rebuild the Beam file multiple times. Inside the Beam file, we found out that the last 4 bytes in "FunT" and before "LitT" are always changing (different between each build). Is there any explanation on how the last 4 bytes are generated? Because of those changing 4 bytes, the checksums of the Beam image are always different build after build.
00000260: 4675 6e54 0000 001c 0000 0001 0000 0013 FunT............
00000270: 0000 0001 0000 0011 0000 0000 0000 0001 ................
00000280: 0432 95c1 4c69 7454 0000 00c3 0000 00f6 .2..LitT........
The best reference for the BEAM file format that I know of is this one. Those four bytes are the "old unique" value for each lambda function. It's being generated here, using part of the MD5 sum of the module.
It's odd that this bit would change if nothing else in the module changes. My best guess would be to pass the deterministic option to the compiler and hope that fixes things.
"If a computer handles data in 8-bit sizes and uses a 16-bit address to store and retrieve data in memory, its address space contains 2^16 (65536) bytes or 64k bytes"
My text book has this statement that I'm confused by. Where are they getting 2^16 from? If a computer uses a 16-bit address why isn't that just a 2 byte address space? The textbook hasn't explained how memory is stored in microcomputers and has this statement in the intro chapter. Am I missing something?
If an address is 16 bits, it means that you have 16 bits when referring to a location in memory. The address space is the range of valid addresses, not the physical size of an address.
These addresses start at address 0 (binary 0000 0000 0000 0000) and go up to address 216−1 (binary 1111 1111 1111 1111). That's total of 216 addresses that can be referenced. And if each address refers to 8 bits (i.e. a byte), the total amount of memory that you can refer to with those addresses is 216 × 8 bits, or 216 bytes.
As a smaller example, consider a system with 3-bit addresses, each referring to 4 bits (a nibble).
Address | 0 1 2 3 4 5 6 7
Memory | 0000 0000 0000 0000 0000 0000 0000 0000
Binary |
address | 000 001 010 011 100 101 110 111
The 3-bit addresses can have 23 values, from 0 to 7, and each refers to 4 bits of memory, so this system has a total of 23 = 8 nibbles of memory.
In this system, the only valid address are 0, 1, 2, 3, 4, 5, 6, and 7, so the address space is the set {0, 1, 2, 3, 4, 5, 6, 7}.
As an important point, don't forget that the address space is not necessarily the actual amount of memory available—computers use some handy tricks to use addresses spaces much larger than the memory they actual have available (for example, a 64-bit system can theoretically address 264 bytes of memory, but you don't even have a fraction of that in your computer).
Analogies for address spaces
Here are two analogies that might help you understand the difference between an address space, an address, and a pointer:
The web address space is the set of all URLs, basically the set of strings of the form https://[domain]/[path]. So https://example.com/page is an address, and this link is a pointer to that address.
The United States street address space is (approximately) the set of strings of this form:
[First name] [Last name]
[number] [Street name]
[Town], [STATE] [zip code]
In the same analogy, this is an address:
John Doe
10 Main St.
Faketown, NY 20164
Finally, a pointer is then analagous to the writing on the front of an envelope that the postal service uses to deliver letters.
I have a .bin saved with a VB program, the .bin format is:
String bytes | String
06 00 | C0 E1 E0 E8 F1 E0
The problem is I don't know how the string is encoded. I know what the string is supposed to be: Abaira
Can anyone recognize the encoding used?
I'm not aware of any standard character encoding for this. It is neither ASCII nor EBCDIC.
It seems to be some trivial sort of 8-bit (non-Unicode) ASCII (perhaps ANSI) encryption. Compare your unknown encoding with ASCII:
Unknown ASCII
Hex MSB LSB Hex MSB LSB
A CO 1100 0000 41 0100 0001
b E1 1110 0001 62 0110 0010
a E0 1110 0000 61 0110 0001
i E8 1110 1000 69 0110 1001
r F1 1111 0001 72 0111 0010
a E0 1110 0000 61 0110 0001
Let's define:
MSB: First nibble = most significant 4 bits
LSB: Second nibble = least significant 4 bits
_U: of Unknown
_A: of ASCII
Then you find:
MSB_U = MSB_A Xor 0x80 (maybe MSB_A Or 0x80)
LSB_U = LSB_A + 1 (to tell how overflow is handled I need to see ASCII char 'O' or 'o')
Then U is the concatenation MSB_U & LSB_U.
Further example ASCII to Unknown:
ASCII Hex MSB LSB MSB Xor 0x80 LSB - 1 Concatenated Hex
H 48 0100 1000 1100 1001 1100 0111 C7
e 65 0110 1001 1110 1010 1110 1000 E8
r 72 0111 0010 1111 0011 1111 0001 F1 (as you have shown)
b 62 0110 0010 1110 0011 1110 0001 E1 (do.)
I have a question about calculating memory addresses:
I am given 3 Memory blocks:
- 1x 1KByte (IC1) - 2^10 Byte
- 2x 4KByte (IC2 + IC3) 2^12 Byte
So far I calculated these memory addresses:
IC1:
0000 0000 0000 0000 (Starting adress)
0000 0011 1111 1111 (Ending adress, I got this from inverting the last 10 digits)
IC2:
0000 0100 0000 0000 (Starting adress)- Last ending adress +1
0000 1011 1111 1111 (Ending adress, I got this from inverting the last 12 digits)
However, at IC3 there has to be some method to get a carry bit into my first 0000-block, as I am running out of space when only using 3 the last 3 hex digits:
IC2:
0000 1100 0000 0000 (Starting adress)- Last ending adress +1
What is the ending address now? If I would invert the last 12 digits again, I would get a hex address which is already in use. It's pretty obvious that the next hex digit has to be increased to 1, but I can't find a rule to do this.
Any advice?
I'm not sure why you're using bit flipping for this, it looks like it should be a very efficient implementation if it works, but it doesn't seem to:
Your IC2 block starting address (in Hex) is 400 (which is 1K from the start of memory, all good so far), but the ending address in hex is BFF when it should be 13FF (1k+4k = 5k) in binary that is 0001 0011 1111 1111
Is there a reason why you cannot calculate these addresses using addition instead of bit-flipping?
I have a question regarding how the Internet checksum is calculated. I couldn't find any good explanation from the book, so I ask it here.
Have a look at the following example.
The following two messages are sent: 10101001 and 00111001. The checksum is calculated with 1's complement. So far I understand. But how is the sum calculated? At first I thought it maybe is XOR, but it seems not to be the case.
10101001
00111001
--------
Sum 11100010
Checksum: 00011101
And then when they calculate if the message arrived OK. And once again how is the sum calculated?
10101001
00111001
00011101
--------
Sum 11111111
Complement 00000000 means that the pattern is O.K.
It uses addition, hence the name "sum". 10101001 + 00111001 = 11100010.
For example:
+------------+-----+----+----+----+---+---+---+---+--------+
| bin value | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | result |
+------------+-----+----+----+----+---+---+---+---+--------+
| value 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 169 |
| value 2 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 57 |
| sum/result | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 226 |
+------------+-----+----+----+----+---+---+---+---+--------+
If by internet checksum you mean TCP Checksum there's a good explanation here and even some code.
When you're calculating the checksum remember that it's not just a function of the data but also of the "pseudo header" which puts the source IP, dest IP, protocol, and length of the TCP packet into the data to be checksummed. This ties the TCP meta data to some data in the IP header.
TCP/IP Illustrated Vol 1 is a good reference for this and explains it all in detail.
The calculation of the internet checksum uses ones complement arithmetic. Consider the data being checksummed is a sequence of 8 bit integers. First you need to add them using ones complement arithmetic and take the ones complement of the result.
NOTE: When adding numbers ones complement arithmetic, a carryover from the MSB needs to be added to the result. Consider for eg., the addition of 3(0011) and 5(0101).
3'->1100
5'->1010
0110 with a carry of 1
Thus we have, 0111(1's complement representation of -8).
The checksum is the 1's complement of the result obtained int he previous step. Hence we have 1000. If no carry exists, we just complement the result obtained in the summing stage.
The UDP checksum is created on the sending side by summing all the 16-bit words in the segment, with any overflow being wrapped around and then the 1's complement is performed and the result is added to the checksum field inside the segment.
at the receiver side, all words inside the packet are added and the checksum is added upon them if the result is 1111 1111 1111 1111 then the segment is valid else the segment has an error.
exmaple:
0110 0110 0110 0000
0101 0101 0101 0101
1000 1111 0000 1100
--------------------
1 0100 1010 1100 0001 //there is an overflow so we wrap it up, means add it to the sum
the sum = 0100 1010 1100 0010
now let's take the 1's complement
checksum = 1011 0101 0011 1101
at the receiver the sum is calculated and then added to the checksum
0100 1010 1100 0010
1011 0101 0011 1101
----------------------
1111 1111 1111 1111 //clearly this should be the answer, if it isn't then there is an error
references:Computer networking a top-down approach[Ross-kurose]
Here's a complete example with a real header of an IPv4 packet.
In the following example, I use bc, printf and here strings to calculate the header checksum and verify it. Consequently, it should be easy to reproduce the results on Linux by copy-pasting the commands.
These are the twenty bytes of our example packet header:
45 00 00 34 5F 7C 40 00 40 06 [00 00] C0 A8 B2 14 C6 FC CE 19
The sender hasn't calculated the checksum yet. The two bytes in square brackets is where the checksum will go. The checksum's value is initially set to zero.
We can mentally split up this header as a sequence of ten 16-bit values: 0x4500, 0x0034, 0x5F7C, etc.
Let's see how the sender of the packet calculates the header checksum:
Add all 16-bit values to get 0x42C87: bc <<< 'obase=16;ibase=16;4500 + 0034 + 5F7C + 4000 + 4006 + 0000 + C0A8 + B214 + C6FC + CE19'
The leading digit 4 is the carry count, we add this to the rest of the number to get 0x2C8B: bc <<< 'obase=16;ibase=16;2C87 + 4'
Invert¹ 0x2C8B to get the checksum: 0xD374
Finally, insert the checksum into the header:
45 00 00 34 5F 7C 40 00 40 06 [D3 74] C0 A8 B2 14 C6 FC CE 19
Now the header is ready to be sent.
The recipient of the IPv4 packet then creates the checksum of the received header in the same way:
Add all 16-bit values to get 0x4FFFB: bc <<< 'obase=16;ibase=16;4500 + 0034 + 5F7C + 4000 + 4006 + D374 + C0A8 + B214 + C6FC + CE19'
Again, there's a carry count so we add that to the rest to get 0xFFFF: bc <<< 'obase=16;ibase=16;FFFB + 4'
If the checksum is 0xFFFF, as in our case, the IPv4 header is intact.
See the Wikipedia entry for more information.
¹Inverting the hexadecimal number means converting it to binary, flipping the bits, and converting it to hexadecimal again. You can do this online or with Bash: hex_nr=0x2C8B; hex_len=$(( ${#hex_nr} - 2 )); inverted=$(printf '%X' "$(( ~ hex_nr ))"); trunc_inverted=${inverted: -hex_len}; echo $trunc_inverted