Code for node1.cpp
#include "stdafx.h"
#include "DV.h"
extern int TRACE;
extern int YES;
extern int NO;
int connectcosts1[4] = { 0, 1, 3, 7};
static distance_table dt;
/* students to write the following two routines, and maybe some others */
void rtinit1()
{
struct rtpkt rtpacket;
// for all destinations y in N:
for(int j=0;j<4;j++)
for(int k=0;k<4;k++) dt.costs[j][k] = 999;
dt.costs[0][0] = connectcosts1[0];
dt.costs[0][1] = connectcosts1[1];
dt.costs[0][2] = connectcosts1[2];
dt.costs[0][3] = connectcosts1[3];
// for each neighbor source is "me" must change in other files.
rtpacket.sourceid = 1;
rtpacket.mincost[0] = dt.costs[rtpacket.sourceid][0];
rtpacket.mincost[1] = dt.costs[rtpacket.sourceid][1];
rtpacket.mincost[2] = dt.costs[rtpacket.sourceid][2];
rtpacket.mincost[3] = dt.costs[rtpacket.sourceid][3];
for(int i = 0;i<4;i++)
if ((i!=rtpacket.sourceid)&&(dt.costs[rtpacket.sourceid][i]!=999))
{
rtpacket.destid = i;
tolayer2(rtpacket);
}
}
void rtupdate1(struct rtpkt *rcvdpkt)
{
struct rtpkt rtpacket;
// the node sending me information is "from" or v in the text on page 383
int v = rcvdpkt->sourceid;
// x is "me" the node that i am at. must change in other files.
int x = 1;
//
bool DV_Changed = false;
// update the location in my cost table
dt.costs[v][0] = rcvdpkt->mincost[0];
dt.costs[v][1] = rcvdpkt->mincost[1];
dt.costs[v][2] = rcvdpkt->mincost[2];
dt.costs[v][3] = rcvdpkt->mincost[3];
// The node that sent me information is v;
// page 383
// dt.costs os c on page 383 in the text
int c_v_x = dt.costs[x][v]; // this is part of line 14
for (int y = 0;y<4;y++)
{
if (y != x)
{
int D_x_y = dt.costs[x][y];
int D_v_y = dt.costs[v][y];
int new_D_x_y = c_v_x + D_v_y;
if (new_D_x_y < D_x_y)
{
dt.costs[x][y] = new_D_x_y;
DV_Changed = true;
}
}
}
if (DV_Changed)
{
// tell my neighbors
rtpacket.sourceid = x;
rtpacket.mincost[0] = dt.costs[rtpacket.sourceid][0];
rtpacket.mincost[1] = dt.costs[rtpacket.sourceid][1];
rtpacket.mincost[2] = dt.costs[rtpacket.sourceid][2];
rtpacket.mincost[3] = dt.costs[rtpacket.sourceid][3];
for(int i = 0;i<4;i++)
if ((i!=rtpacket.sourceid)&&(dt.costs[rtpacket.sourceid][i]!=999))
{
rtpacket.destid = i;
tolayer2(rtpacket);
}
}
}
void printdt1(struct distance_table *dtptr)
{
printf(" via \n");
printf(" D0 | 1 2 3 \n");
printf(" ----|-----------------\n");
printf(" 1| %3d %3d %3d\n",dtptr->costs[1][1],
dtptr->costs[1][2],dtptr->costs[1][3]);
printf("dest 2| %3d %3d %3d\n",dtptr->costs[2][1],
dtptr->costs[2][2],dtptr->costs[2][3]);
printf(" 3| %3d %3d %3d\n",dtptr->costs[3][1],
dtptr->costs[3][2],dtptr->costs[3][3]);
}
Sunday, May 6, 2012
Tuesday, April 24, 2012
Wireshark Lab 7: DHCP
1. DHCP messages are sent over UDP.
3. 58:6d:8f:0f:dd:9f
4. The identification value seems to be the only thing that differentiates the messages.
5. The transaction ID value of the first set is: 0x868096c4
The transaction ID value of the second set is: 0x44575b0c
The purpose of the transaction ID seems to be a way for the messages to stay grouped together.
6. The value used until an IP address is assigned appears to be 0.0.0.0.
Discover: Source: 0.0.0.0 Destination: 255.255.255.255
Offer: Source: 10.33.37.126 Destination: 10.33.37.45
Request: Source: 0.0.0.0 Destination: 255.255.255.255
ACK: Source: 10.33.37.126 Destination: 10.33.37.45
7. 10.40.4.45
8. 10.33.37.45. The DHCP offer message contains it.
9. The fact that the relay agent's address in the screenshot is 0.0.0.0 indicates that there isn't one. My experiment does contain a relay agent. The address of it is: 10.33.37.126.
10. The subnet mask and router lines in the frame are necessary to correctly route the data to my computer.
11. The same thing happens. The IP address is requested.
12. The "lease time" refers to how long you can use that particular IP address. The lease time on my current IP address is one day.
13. The release packet signifies that the host wants to stop using that particular IP address. There is no acknowledgement for a release packet. If the packet wasn't received, you would just continue using your existing IP address.
14. There was a large amount of ARP packets present.
3. 58:6d:8f:0f:dd:9f
4. The identification value seems to be the only thing that differentiates the messages.
5. The transaction ID value of the first set is: 0x868096c4
The transaction ID value of the second set is: 0x44575b0c
The purpose of the transaction ID seems to be a way for the messages to stay grouped together.
6. The value used until an IP address is assigned appears to be 0.0.0.0.
Discover: Source: 0.0.0.0 Destination: 255.255.255.255
Offer: Source: 10.33.37.126 Destination: 10.33.37.45
Request: Source: 0.0.0.0 Destination: 255.255.255.255
ACK: Source: 10.33.37.126 Destination: 10.33.37.45
7. 10.40.4.45
8. 10.33.37.45. The DHCP offer message contains it.
9. The fact that the relay agent's address in the screenshot is 0.0.0.0 indicates that there isn't one. My experiment does contain a relay agent. The address of it is: 10.33.37.126.
10. The subnet mask and router lines in the frame are necessary to correctly route the data to my computer.
11. The same thing happens. The IP address is requested.
12. The "lease time" refers to how long you can use that particular IP address. The lease time on my current IP address is one day.
13. The release packet signifies that the host wants to stop using that particular IP address. There is no acknowledgement for a release packet. If the packet wasn't received, you would just continue using your existing IP address.
14. There was a large amount of ARP packets present.
Wireshark Lab 6: Ethernet and ARP
(Like the last few assignments, I've completed this one using the capture file provided by the book's authors)
1. 00:d0:59:a9:3d:68
2. 00:06:25:da:af:73.
3-5. I can't seem to find the information required to answer these questions.
6. 00:06:25:da:af:73.
7. 00:d0:59:a9:3d:68. I can't tell if it's my computer's ethernet address as I'm using the premade capture file.
8-10. Like above; I cannot seem to find the info required to answer these questions.
11. Screenshot of ARP cache: http://img801.imageshack.us/img801/1988/arpcache.png
12. Source: 00:d0:59:a9:3d:68 Destination: ff:ff:ff:ff:ff:ff
14.
c. Yes, the IP address is present in the ARP message.
16: Source: 00:06:25:da:af:73 Destination: 00:d0:59:a9:3d:68
1. 00:d0:59:a9:3d:68
2. 00:06:25:da:af:73.
3-5. I can't seem to find the information required to answer these questions.
6. 00:06:25:da:af:73.
7. 00:d0:59:a9:3d:68. I can't tell if it's my computer's ethernet address as I'm using the premade capture file.
8-10. Like above; I cannot seem to find the info required to answer these questions.
11. Screenshot of ARP cache: http://img801.imageshack.us/img801/1988/arpcache.png
12. Source: 00:d0:59:a9:3d:68 Destination: ff:ff:ff:ff:ff:ff
14.
c. Yes, the IP address is present in the ARP message.
16: Source: 00:06:25:da:af:73 Destination: 00:d0:59:a9:3d:68
Monday, April 23, 2012
Wireshark Lab 5: ICMP
(The ping command doesn't seem to be working. Every site I try to ping just returns "Request Timed Out". Here's a screenshot of a ping on Google timing out:
http://img706.imageshack.us/img706/7663/googletimeout.png )
1. Host IP: 149.152.37.45
Destination IP: 143.89.14.34
2. IMCP is a session-less protocol, therefore it doesn't use ports.
3. The ping request packet has "type: 8" and "code: 0". The other fields are: checksum(be), checksum(le), sequence number(le) and sequence number(be).
4. I can't answer this question since I wasn't able to get a response from any of the hosts I pinged.
(These questions were answered with the capture file provided by the book's authors.)
5. Host IP: 192.168.1.101
Destination IP: 138.96.146.2
6. Yes, it would.
7. No. They're the same.
8. The extra fields in the error packets seem to be extra copies of the IPv4 header.
9. They contain less information, and have different Time To Live values and identification values. They're different because the ICMP packets were actually received, and didn't get an error.
10. I can't answer this question, as tracert also causes a time out when I try to use it, like ping.
http://img706.imageshack.us/img706/7663/googletimeout.png )
1. Host IP: 149.152.37.45
Destination IP: 143.89.14.34
2. IMCP is a session-less protocol, therefore it doesn't use ports.
3. The ping request packet has "type: 8" and "code: 0". The other fields are: checksum(be), checksum(le), sequence number(le) and sequence number(be).
4. I can't answer this question since I wasn't able to get a response from any of the hosts I pinged.
(These questions were answered with the capture file provided by the book's authors.)
5. Host IP: 192.168.1.101
Destination IP: 138.96.146.2
6. Yes, it would.
7. No. They're the same.
8. The extra fields in the error packets seem to be extra copies of the IPv4 header.
9. They contain less information, and have different Time To Live values and identification values. They're different because the ICMP packets were actually received, and didn't get an error.
10. I can't answer this question, as tracert also causes a time out when I try to use it, like ping.
Wireshark Lab 4: IP
(NOTE: I'm using the capture file provided by the book's authors because the traceroute program wasn't working as it should)
1. 192.168.1.102
2. ICMP (1)
3. There are 20 bytes in the IP header. There should be 36 bytes in the payload, since the packet size was 56 bytes and the header size is 20 bytes.
4. They do appear to be fragmented, as there are many IPv4 packet fragments in the capture window.
5. The TTL (Time To Live) is different in each one. The identification field also changes.
6. The host, destination, header size and fragment offset fields all stay the same.
7. The identification field changes by one for each new packet.
8. The TTL is 254, and the identification field is 0.
9. Yes, the values stay constant for all the TTL exceeded replies from that particular router.
10. Yes, it has been fragmented across more than one IP datagram.
11. I know this packet is fragmented because there is a field that says "Reassembled IPv4 in frame 100", which implies that it is a fragment. This datagram fragment is 1480 bytes.
12. There doesn't seem to be anything in the header that indicates that it is not the first fragment. There are more fragments, I can tell by looking in the capture window.
13. Identification and Time To Live are the fields that get changed between fragments.
14. Two fragments were created from the original datagram.
15. The Time To Live, header checksum and fragment offset fields all change between the fragments.
1. 192.168.1.102
2. ICMP (1)
3. There are 20 bytes in the IP header. There should be 36 bytes in the payload, since the packet size was 56 bytes and the header size is 20 bytes.
4. They do appear to be fragmented, as there are many IPv4 packet fragments in the capture window.
5. The TTL (Time To Live) is different in each one. The identification field also changes.
6. The host, destination, header size and fragment offset fields all stay the same.
7. The identification field changes by one for each new packet.
8. The TTL is 254, and the identification field is 0.
9. Yes, the values stay constant for all the TTL exceeded replies from that particular router.
10. Yes, it has been fragmented across more than one IP datagram.
11. I know this packet is fragmented because there is a field that says "Reassembled IPv4 in frame 100", which implies that it is a fragment. This datagram fragment is 1480 bytes.
12. There doesn't seem to be anything in the header that indicates that it is not the first fragment. There are more fragments, I can tell by looking in the capture window.
13. Identification and Time To Live are the fields that get changed between fragments.
14. Two fragments were created from the original datagram.
15. The Time To Live, header checksum and fragment offset fields all change between the fragments.
Monday, March 12, 2012
Wireshark Lab 3: DNS
Part 1: nslookup
1. nslookup 2chan.net
Server: ecsu-sv26.easternct.edu
Address: 10.40.4.44
2. nslookup -type=ns ox.ac.uk
Authoritive:
ns2.ja.net 193.63.105.17
3. This particular question caused a time out each time.
Part 3: Tracing DNS with Wireshark
4. They are both sent over UDP.
5. The destination port for the query is 53. The source port is also 53.
6. The DNS request is sent to 10.40.4.44. This is the same as my local DNS server.
7. It is a "standard query". There is no "answer" in the request.
8. There is one answer. It contains the site's hostname, IP address, time to live, and a few other things.
9. Yes, they are sent to the IP that is in the DNS query response.
10. Yes, there is a new DNS query for each image.
11. The destination port for the query is 53. The response port is also 53.
12. The query was sent to 10.40.4.44, which is the same as my local DNS server.
13. It is a standard DNS query. There are no "answers" in the DNS query.
14. The query response contains one answer, which has the same info as the other one. Hostname, IP address, time to live and other things.
15. Screenshot: http://img205.imageshack.us/img205/3815/wiresharkscreenshotq15.png
16. The DNS query is sent to 10.40.4.44, same as the others. Yes, this is my local DNS server.
17. It is a standard query, and doesn't contain any "answers"
18. The MIT nameservers it contains are: bitsy.mit.edu, strawb.mit.edu and w20ns.mit.edu. Yes, the IP addresses are also included.
19.Screenshot: http://img28.imageshack.us/img28/581/wiresharkscreenshotq19.png
20. As with the others before, the query is sent to 10.40.4.44, which is my local DNS server.
21. It is a standard query. It contains no answers.
22. The response contains one answer. The info in the answer is the same as all the other answers: Hostname, IP address, time to live and others.
23. Screenshot: http://img269.imageshack.us/img269/728/wiresharkscreenshotq23.png
1. nslookup 2chan.net
Server: ecsu-sv26.easternct.edu
Address: 10.40.4.44
2. nslookup -type=ns ox.ac.uk
Authoritive:
ns2.ja.net 193.63.105.17
3. This particular question caused a time out each time.
Part 3: Tracing DNS with Wireshark
4. They are both sent over UDP.
5. The destination port for the query is 53. The source port is also 53.
6. The DNS request is sent to 10.40.4.44. This is the same as my local DNS server.
7. It is a "standard query". There is no "answer" in the request.
8. There is one answer. It contains the site's hostname, IP address, time to live, and a few other things.
9. Yes, they are sent to the IP that is in the DNS query response.
10. Yes, there is a new DNS query for each image.
11. The destination port for the query is 53. The response port is also 53.
12. The query was sent to 10.40.4.44, which is the same as my local DNS server.
13. It is a standard DNS query. There are no "answers" in the DNS query.
14. The query response contains one answer, which has the same info as the other one. Hostname, IP address, time to live and other things.
15. Screenshot: http://img205.imageshack.us/img205/3815/wiresharkscreenshotq15.png
16. The DNS query is sent to 10.40.4.44, same as the others. Yes, this is my local DNS server.
17. It is a standard query, and doesn't contain any "answers"
18. The MIT nameservers it contains are: bitsy.mit.edu, strawb.mit.edu and w20ns.mit.edu. Yes, the IP addresses are also included.
19.Screenshot: http://img28.imageshack.us/img28/581/wiresharkscreenshotq19.png
20. As with the others before, the query is sent to 10.40.4.44, which is my local DNS server.
21. It is a standard query. It contains no answers.
22. The response contains one answer. The info in the answer is the same as all the other answers: Hostname, IP address, time to live and others.
23. Screenshot: http://img269.imageshack.us/img269/728/wiresharkscreenshotq23.png
Sunday, March 11, 2012
Wireshark Lab 2: HTTP
Part 1: The Basic HTTP GET/response interaction
1. My browser is running HTTP 1.1. (GET /wireshark-labs/HTTP-wireshark-file1.html HTTP/1.1\r\n). The server is running HTTP 1.1. (HTTP/1.1 200 OK\r\n)
2. My web browser accepts HTML, XHTML and XML.
(Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n)
3. My IP is 10.33.37.39, and the server's IP address is 128.119.245.12.
4. That status code returned by the server is 200, meaning connection is OK.
5. The file was last modified Sunday, March 11th, 2012 at 8:03 PM GMT. (Last-Modified: Sun, 11 Mar 2012 20:03:01 GMT\r\n)
6. 482 Bytes are being returned to my browser. (Frame 14: 482 bytes on wire (3856 bits), 482 bytes captured (3856 bits))
7. I do not see any differing headers in the packet content window and the packet listing window.
Part 2: The HTTP CONDITIONAL GET/response interaction
8. I do not see an "If Modified since" line.
9. The server doesn't appear to have explicitly returned the contents of the file.
10. There is an IF-MODIFIED-SINCE line. It is as follows: If-Modified-Since: Sun, 11 Mar 2012 20:22:02 GMT\r\n.
11. The response code is 304 Not Modified (HTTP/1.1 304 Not Modified\r\n). Once again, the server does not appear to have explicitly returned the contents of the file.
Part 3: Retrieving Long Documents
12. There were two HTTP GET request messages sent by my browser.
13. There were four TCP segments. (4 Reassembled TCP Segments (4803 bytes): #19(1460), #20(1460), #22(1460), #23(423))
14. The response was 200 OK for the first GET message, and 404 NOT FOUND for the second GET message.
15. There doesn't seem to be any HTTP response messages in the data transmission associated with a TCP induced "continuation"
Part 4: HTML documents with embedded objects
16. There were three GET messages sent out by my browser. One was sent to the gaia.umass server. One was sent to the aw-bc.com site, and the last one was sent to manic.cs.umass.edu.
17. I assume they were downloaded in parallel, as the time on the response messages for both images is identical.
Part 5: HTTP Authentication
18. The response to the first GET message is 401 Authentication Required.
19. The new field in the second GET message is a field called "Authorization" that appears to contain the username and password I used to log in.
1. My browser is running HTTP 1.1. (GET /wireshark-labs/HTTP-wireshark-file1.html HTTP/1.1\r\n). The server is running HTTP 1.1. (HTTP/1.1 200 OK\r\n)
2. My web browser accepts HTML, XHTML and XML.
(Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n)
3. My IP is 10.33.37.39, and the server's IP address is 128.119.245.12.
4. That status code returned by the server is 200, meaning connection is OK.
5. The file was last modified Sunday, March 11th, 2012 at 8:03 PM GMT. (Last-Modified: Sun, 11 Mar 2012 20:03:01 GMT\r\n)
6. 482 Bytes are being returned to my browser. (Frame 14: 482 bytes on wire (3856 bits), 482 bytes captured (3856 bits))
7. I do not see any differing headers in the packet content window and the packet listing window.
Part 2: The HTTP CONDITIONAL GET/response interaction
8. I do not see an "If Modified since" line.
9. The server doesn't appear to have explicitly returned the contents of the file.
10. There is an IF-MODIFIED-SINCE line. It is as follows: If-Modified-Since: Sun, 11 Mar 2012 20:22:02 GMT\r\n.
11. The response code is 304 Not Modified (HTTP/1.1 304 Not Modified\r\n). Once again, the server does not appear to have explicitly returned the contents of the file.
Part 3: Retrieving Long Documents
12. There were two HTTP GET request messages sent by my browser.
13. There were four TCP segments. (4 Reassembled TCP Segments (4803 bytes): #19(1460), #20(1460), #22(1460), #23(423))
14. The response was 200 OK for the first GET message, and 404 NOT FOUND for the second GET message.
15. There doesn't seem to be any HTTP response messages in the data transmission associated with a TCP induced "continuation"
Part 4: HTML documents with embedded objects
16. There were three GET messages sent out by my browser. One was sent to the gaia.umass server. One was sent to the aw-bc.com site, and the last one was sent to manic.cs.umass.edu.
17. I assume they were downloaded in parallel, as the time on the response messages for both images is identical.
Part 5: HTTP Authentication
18. The response to the first GET message is 401 Authentication Required.
19. The new field in the second GET message is a field called "Authorization" that appears to contain the username and password I used to log in.
Subscribe to:
Posts (Atom)