Subject: Assignment 1 (This message is being sent to all CPSC 826 students) Assignment 1 is now available. See assn1.s00 in the usual directory. mw Subject: Backups... (This message is being sent to all CPSC 826 students) In case you were not aware, the filesystems on ALL linux machines (e.g. glint2) used in the course are NEVER BACKED UP. Furthermore, other research projects are in process on these machines and might well lead to system crashes. System crashes can and have led to UNRECOVERABLE file system damage!!! If this unfortunate turn of events should occur and your submitted program be destroyed you will have to provldide a replacement. On the plus side this CPSC 826 machines have never suffered such a nasty fate before. On the minus side it is inevitable that one day they will. So.. unless you feel confident that this is your lucky semester. I recommend that you backup regularly. To do this: log in to glint2 (or other linux machine if appropriate) then ftp to yoda and offload your source. (The linux machines on which you work will generally NOT accept incoming ftps). mw Subject: Assn1 problem determination (This message is being sent to all CPSC 826 students) (With any luck) tcpdump is now functional on glint2 along with its man page. If you are having difficulty diagnosing what (if anything) you are actually transmitting tcpdump can help you out. Subject: Assn1 (This message is being sent to all CPSC 826 students) In order to avoid a nasty self-inflicted loss of numerical significance you should perform all computations in microsecond units using double precision floats. If you start by truncating times returned by gettimeofday() to millisecs you are guaranteed to have troubles. mw Subject: Assn2 ... now unprotected (This message is being sent to all CPSC 826 students) I have now unprotected assn2.s00.. sorry 'bout that. mw Subject: Assn 2 Q & A >> 1) Will a user read / write ever give a size < 1024? Yes.. any size write <= 1024 bytes is allowable. You MAY assume that the receiver always specify a receive length of at least whatever size the sender is sending. >> 2) If so, do we buffer on the sender side until we reach 1024? No you are building a reliable message stream. Thus you MUST preserve message boundaries. >> If we don't buffer, we need to send the amount of data sent in the >> header information, but there is no room. Should we include an 'amount of >> data sent' field? You don't need and must not include an explicit length in the header field. The recvfrom() function will return you the size of whatever was sent. >> 3) In the specification, there is no way to send ACKs and data together. >> Should we change this so ACKs can be sent with data? Since the header contains both seq and ack numbers when you send a packet of type data, you can already to this now. Thus there is nothing that should be changed. =========== You SHOULD however make the following changes to the packet header: Add an offered window and a packet id number (useful for debugging.) struct pkttype { int magic; /* Magic # */ int pkt; /* Packet type */ int seq; /* Sequence number */ int ack; /* Ack number */ int window; /* Offered window in Packets */ int id; /* Packet id. */ char data[1024]; /* Max 1024 bytes */ }; Finally just to make things more interesting and hopefully to minimize the possibility of dumping huge amts of UDP junk onto the internet, mMake your sequence number space size be 64. (i.e. after 63 both seq and ack should wrap back to 0). Subject: Assn 1 grades (This message is being sent to all CPSC 826 students) I am sending out assn1 evaluations. They are being sent to the owner of the directory into which they were submitted. If you receive one and worked on a team, please send it on to your teammate. Evaluating these assignments takes a LONG time and I hope to finish tomorrow.. So if you did not receive a report today please wait until Monday before inquiring as to its status. If you receive an evalutation stating that your program was broken in a major way, please do NOT send me a request asking that I point out your bug. I have looked over all source code and IF I see a bug I report it... but I just can't debug all broken programs. Please DO feel free to come to my office after class and I will be glad to show you WHAT went wrong... but I won't necessarily be able to show you the source of the problem. Subject: Assn 1 and 2 (This message is being sent to all CPSC 826 students) I've now finished sending out assn1 grades. I have recorded grades for all students, but I only sent the report to the owner of the directory into which the program was submitted. Assn2 directories have now been created. If working as a TEAM please SUBMIT ONLY ONE COPY. It doesn't matter which directory UNLESS you provided me a userid different from your departmental userid (Arvind and Mandar for example) in that case please submit in the OTHER persons directory so that I don't have to run finger searches to figure out where to send the report. thanks Subject: Next quiz (This message is being sent to all CPSC 826 students) I have decided just to eliminate this week's quiz. The next quiz will be on 3 March and will cover the 5 preceding classes mw Subject: Assignment 2 (This message is being sent to all CPSC 826 students) I'll be sending assn2 reports out shortly. As usual if you don't understand what went wrong, stop by and I'll be glad to demo the problem. Also if you care to identify, describe, and fix the problem I will be happy to consider giving you additional points. Here is the driver used to test this version: NO packets were intentionally dropped during these tests. 3 char buf[65]; 4 5 main( 6 int argc, 7 char **argv) 8 { 9 int conn; 10 int len; 11 12 conn = xudpconnect(argv[1], atoi(argv[2])); 13 14 while (len = read(0, buf, sizeof(buf))) 15 { 16 xudpsend(conn, buf, len); 17 sleep(1); 18 } 19 xudpclose(conn); 20 21 22 } 3 char buf[1024]; 4 5 main( 6 int argc, 7 char **argv) 8 { 9 int sock; 10 int len; 11 12 sock = xudpaccept("jmw2", atoi(argv[1])); 13 while ((len = xudprecv(sock, buf, sizeof(buf))) > 0) 14 write(1, buf, len) ; 15 } Subject: Hack attack Linux machines in the dept are under a MAJOR hack attack from outside. It is therefore necessary that our firewall be running on glint2. This means that you will not be able to access glint2 from an ISP. It also means that if the firewall must be reinstalled each time the system is rebooted. This is done via: /sbin/insmod /usr/local/bin/fw.o Subject: Also for friday Check out http://www.merit.edu/ipma/reports (and subordinate pages). Subject: glint2 Due to use in ACM conference, glint2 will be unavailable for approx the next 24 hours... starting more or less immediately!! jmw Subject: A3 logs.. I've now distributed A3 grade logs. Please share with your teammate. Since I was so far behind in getting these things evaluated I didn't really torture test them.. which led to lots of 100's! On the downside that doesn't shake out bugs too thoroughly so don't get too complacent about the final version if this one appeared to work. I only transferred a 64K file and I didn't force any intentional drops. Subject: glint2 Apparently the load recently inflicted on the ethernet adapter in glint2 was too much for it and it has died. Thus, until I can get it replaced, glint2 is out of business. You may of course continue your reliable protocol assignment on dept workstations. mw Subject: glint2 now back (more/less) ... or how I wasted a day! Here is a description of the mess that remains: I was having a what appeared to be a hardware problem on glint2 today (link light flashing on/off on external tranceiver and a zillion framing errors.) To try to isolate the problem I swapped tranceivers with jmw3 and swapped cables with glint3. That seemed to solve the glint2 problem, but now I am having a problem similar to one Wayne said you had. Namely glint3 can apparently access all systems EXCEPT glint and glint2. If I try to ping glint from glint3 here is what happens: Running tcpdump on glint I see the normal arp request and arp response: 15:47:28.438147 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 15:47:28.438194 arp reply glint.cs.clemson.edu is-at 0:60:97:1a:6d:39 15:47:29.438091 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 15:47:29.438134 arp reply glint.cs.clemson.edu is-at 0:60:97:1a:6d:39 15:47:30.438073 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 15:47:30.438109 arp reply glint.cs.clemson.edu is-at 0:60:97:1a:6d:39 Running tcpdump on glint3 I see only the arp request and not the arp response: 13:29:51.327375 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 13:29:52.327417 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 13:29:53.327373 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu 13:29:54.327375 arp who-has glint.cs.clemson.edu tell glint3.cs.clemson.edu All of my firewalling is OFF, and perversely I can ping any other system from glint3 and glint3 from any other systems. Here is from jmw2 /home/westall ==> ping glint3 PING glint3.cs.clemson.edu (130.127.48.243): 56 data bytes 64 bytes from 130.127.48.243: icmp_seq=0 ttl=255 time=0.6 ms 64 bytes from 130.127.48.243: icmp_seq=1 ttl=255 time=0.5 ms 64 bytes from 130.127.48.243: icmp_seq=2 ttl=255 time=0.5 ms 64 bytes from 130.127.48.243: icmp_seq=3 ttl=255 time=0.5 ms 64 bytes from 130.127.48.243: icmp_seq=4 ttl=255 time=0.5 ms Here is from jmw3 PING glint3.cs.clemson.edu (130.127.48.243): 56 data bytes 64 bytes from 130.127.48.243: icmp_seq=0 ttl=255 time=1.3 ms 64 bytes from 130.127.48.243: icmp_seq=1 ttl=255 time=0.8 ms 64 bytes from 130.127.48.243: icmp_seq=2 ttl=255 time=0.7 ms 64 bytes from 130.127.48.243: icmp_seq=3 ttl=255 time=0.7 ms Here is from glint3 to glint and then to atm2 /home/westall ==> ping glint PING glint.cs.clemson.edu (130.127.48.143): 56 data bytes --- glint.cs.clemson.edu ping statistics --- 518 packets transmitted, 0 packets received, 100% packet loss /home/westall ==> ping atm2 PING atm2.cs.clemson.edu (130.127.56.30): 56 data bytes 64 bytes from 130.127.56.30: icmp_seq=0 ttl=254 time=3.0 ms 64 bytes from 130.127.56.30: icmp_seq=1 ttl=254 time=0.7 ms 64 bytes from 130.127.56.30: icmp_seq=2 ttl=254 time=0.7 ms 64 bytes from 130.127.56.30: icmp_seq=3 ttl=254 time=0.7 ms 64 bytes from 130.127.56.30: icmp_seq=4 ttl=254 time=0.7 ms --- atm2.cs.clemson.edu ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.7/1.1/3.0 ms /home/westall ==> Here are all routing tables: /home/westall ==> /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 130.127.48.243 * 255.255.255.255 UH 0 0 0 eth0 130.127.48.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 130.127.48.1 0.0.0.0 UG 0 0 0 eth0 /home/westall ==> ==> /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 130.127.48.190 * 255.255.255.255 UH 0 0 0 eth0 130.127.48.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 130.127.48.1 0.0.0.0 UG 0 0 0 eth0 ==> [root@glint westall]# /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 130.127.48.143 * 255.255.255.255 UH 0 0 0 eth0 130.127.48.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 130.127.48.1 0.0.0.0 UG 0 0 0 eth0 [root@glint westall]# Finally here is ifconfig on glint3 indicating that there aren't a gezillion errors going on: /home/westall ==> /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:B0:D0:11:91:C4 inet addr:130.127.48.243 Bcast:130.127.48.255 Mask:255.255.255.0 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:28911 errors:0 dropped:0 overruns:0 frame:0 TX packets:4067 errors:0 dropped:0 overruns:0 carrier:2 collisions:7 txqueuelen:100 Interrupt:19 Base address:0xdc00 As a final test I have now swapped the cables to glint2 and glint3 back to their original configuration. The "ping" problem followed the cable. Now glint and glint3 can ping each other fine but neither can ping glint2. Meanwhile glint2 can't ping glint or glint3 but it CAN reach the rest of the world. This is beginning to look to me that the resolution resides in the wiring closet. So maybe you should just pass this on to CCR and crew. Mike Subject: Last assignment See assn5.s00 Subject: SNMP assn.. A question has been asked about the presence of 0x82's in response fields. That is an alternative way to encode lengths. See the following code: 64 /* Lengths are encoded in an oddball way.. If the byte is */ 65 /* 0x7f or smaller then then byte is an actual length.. */ 66 /* If the high order bit is on then the low order 7 bits */ 67 /* contain the length of the following length field in */ 68 /* network byte order .. */ 69 70 if (*loc & 0x80) /* Extended length format */ 71 { 72 size = *loc & 0x7f; 73 loc += 1; 74 len = getval(loc, size); 75 loc += size; 76 *where = loc; 77 } 78 else /* Regular length format */ 79 { 80 len = *loc; 81 loc += 1; 82 *where = loc; 83 } Subject: Assignment 5 clarification... I received a message indicating that at least one team was making this harder than it is. The assignment requires not data digestion at all. That is, you don't have to worry at all about non unicast packets, error's etc. It requires only that you retrieve and report the following mib values from the specified host / interface: (These values are taken from glint3 which has 3 interfaces your program would only retrieve the values from the interface specified on the command line.) 1 interfaces.ifTable.ifEntry.ifInOctets.1 = 17864 2 interfaces.ifTable.ifEntry.ifInOctets.2 = 355756940 3 interfaces.ifTable.ifEntry.ifInOctets.3 = 10119648 4 interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 58 5 interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 1155058 6 interfaces.ifTable.ifEntry.ifInUcastPkts.3 = 32856 7 interfaces.ifTable.ifEntry.ifOutOctets.1 = 17864 8 interfaces.ifTable.ifEntry.ifOutOctets.2 = 2770768 9 interfaces.ifTable.ifEntry.ifOutOctets.3 = 10120572 10 interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 58 11 interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 8999 12 interfaces.ifTable.ifEntry.ifOutUcastPkts.3 = 32859 Subject: Assn5 clarification... The proper approach here is again multithreaded. You should have a sender thread that uses pthread_cond_timedwait(&t_cond, &t_mtx, &timeout); to ensure that packets are sent out at precisely the correct "ticks". You should have a receiver thread that receives, decodes, and logs packets. Dropped packets may occur and will be indicated in your output by a skip in the sequence numbering. Error conditions should not occur unless you are sending broken requests!! mw Subject: "Resubmissions.." I have tried to be as liberal as possible in regard to permitting resubmissions. However, all good things including both this class and the resubmission policy must come to an end in order for me to get final grades prepared in a timely manner. Thus, there will be ONLY ONE submission of Assn 4 and Assn 5 permitted. Subject: grade file problems.. Jay was able to recover the file from a backup made Sunday. Thus I will need the Quiz B papers returned (but nothing else). mw Subject: Assn 5 clarification... There should be NO TIMEOUT related code AT ALL in assn 5. It should contain 2 indepentently operating threads: one to send and another to receive. The sender should encode the sequence # of the packet (which is equal to the time in seconds since startup that the packet was sent). The sender should use: pthread_cond_timedwait(&t_cond, &t_mtx, &timeout) to ensure that it clocks out requests at even 1 second intervals So... basic logic should be: sender: while (more) { wait_til_next_second send_request } receiver: while (more) { receive WITH NO TIMEOUT!!!!!!!!!! decode and print } Subject: Clarification to the clarification The orginal assignment said to report sequence number not time in seconds since the sample was sent. In my last message I was thinking in terms of 1 sample per second.. In general it should be SEQUENCE NUMBER not elapsed time that is printed. Sorry about the confusion. mw Subject: Exemptions... I have now graded the makeup quizzes and all assn5 submissions that were turned in by 2:30 pm saturday. The following are exempt from the final with the grade of "A". As I said earlier, even if you are not exempt, the final will not reduce your present grade. Based upon makeup quiz scores, I would say some serious studying is in order for those who plan to take it though! Shivashankaraia Vina Poliboyina Vijaya K Zaroo Chitranjan Kekre Swapneel Ajit Narendra Hosahalli N Gokhale Mandar V Balaji Rayadurgam T Li Shineng Dai Jinze Ramasubramaniam Vaia Kotwani Mukul G Vadhanam Suresh Hamrick Cameron T Swaminathan Arvind Nagapraveen Veeraven Whisonant Timothy S Sekhar Vishnu Subject: 826 grades.. I now have grades for all students for all assignments. There is only one individual with a realistic chance of converting a "B" to an "A". (He needs about 94 on the exam.) There is only one individual who needs to take the exam in order to avoid making a "C". I will contact those two people personally. Thus if you aren't on the list and you don't hear from me, then your present average is somewhere between 80 and 85.8. Even the holder of the 85.8 would need 98/100 on the final for A... Possible but unlikely. The exempt with A list is now: Nimmagadda Prashanth Zaroo Chitranjan Kekre Swapneel Ajit Shivashankaraia Vina Narendra Hosahalli N Sunkesula Pawan R.K. Gokhale Mandar V Poliboyina Vijaya K Balaji Rayadurgam T Bharadwaj Manjunath Li Shineng Dai Jinze Ramasubramaniam Vaia Kotwani Mukul G Vadhanam Suresh Hamrick Cameron T Swaminathan Arvind Nagapraveen Veeraven Whisonant Timothy S Sekhar Vishnu