Subject: First quiz / first assignment and milestone This is the message I tried to send Tuesday: This message is being sent to you because you are thought to be a student in CPSC 881 Section 2. It contains a request and a couple of informational items. Requests: (1) Please let me know if you plan to be working in a team and if so who your teammate will be. Informational items: (1) The first quiz will be this Thursday. It will cover material discussed in class through the netinit and ipinit sections. It will NOT cover the sk_buff material discussed today. It will be fully open book and and open notes, but please be aware that without proper review of the material you may well run out of time. Example quizzes are in the oldquiz subdirectory (2) The first assignment and the first two milestones are now available in the assn directory. Subject: Notes and Lab update (This message is being sent to all CPSC 881/2 students) The next sections of the notes to be covered will be (in order). 1 - udpsock 2 - udpbind 3 - udpsend Please read over udpsock before class monday: ---------------------------------------------------- Machine assignments: machine name is pasted on its side venkat moe prabu/tanuja curly ayoob/george shemp jay robert brett andrew jeff darryl rahul larry mike david ---------------------------------------------------- Before using the machine you <> you are running the 881 Red Hat 9 system. You may log in with root with the password I gave in class last time. If the system is running Mandrake linux you need to reboot!!!! The reboot procedure is a two phase lilo. On the first menu select 881 and on the second select linux (your only choice at the moment.) As currently configured X will not run. However, if your userid is vyalla and you do something like: scp vyalla@torpedo1:/home/westall/XF86Config /etc/X11 X windows should work OK. ------------------------------------------------------ Even if you develop on another machine you will need to DEMO on the lab machines. So I recommend that you create a reasonable test environment there ASAP. I recommend that you NOT WORK AS ROOT. Create a user id and chmod a+s insmod/rmmod/lsmod to make module management easy. Remember: NO SOURCE CODE is to be left unattended on these machines UNLESS it is tarred/zipped up and encrypted. Subject: Sample makefile (This message is being sent to all CPSC 881-2 students) I recommend using a multiple source module approach to building this system. That approach is especially useful for teams... Here is a sample makefile that can be used to do that. Here the main object tcpmon.c (MOBJECT) is the file that contains the module_init() and module_exit() functions. CC = gcc TRUEROOT = /usr/src/linux-2.4 WORKROOT = /usr/src/linux-2.4 INCLS = -I. -I$(WORKROOT)/include DEFS = -D__KERNEL__ -DCPU=586 OPTIONS = -O2 -fomit-frame-pointer \ -fno-strength-reduce \ -fvolatile -Wall \ -fvolatile-global \ -pipe -mcpu=i686 -falign-loops=2 \ -falign-jumps=4 -falign-functions=4 EFLAGS = $(INCLS) $(DEFS) $(OPTIONS) CFLAGS = $(EFLAGS) -c UFLAGS = $(INCLS) -DAPP_MODE MFLAGS = -DMODULE -DMODVERSION $(CFLAGS) # This section makes the driver.. It assumes that the kernel # has been configured to support MODULES and MODVERSIONS SOBJECTS = tcpioctl.o MOBJECT = tcpmon.o MODULE = tcp.o $(MODULE): $(MOBJECT) $(SOBJECTS) ld -Map tcp.map -r -o $(MODULE) $(MOBJECT) $(SOBJECTS) ##- >/var/log/messages # - /sbin/rmmod tcp # - /sbin/insmod tcp.o $(MOBJECT): $(INCLUDE) tcpmon.c $(CC) $(MFLAGS) tcpmon.c 2> tcpmon.err $(SOBJECTS): $(INCLUDE) .c.o: $< $(CC) $(CFLAGS) $< 2> $(@:.o=.err) Subject: Milestone 2 (This message is being sent to all CPSC 881-2 students) Milestone 2 demos will done on 9 Feb. Subject: Internship opportunity (This message is being sent to all CPSC 881-2 students) Harmeet Sahni (a CU grad from about 5 years ago has openings for interns at Juniper this summer.) (The 881 he refers to here is now CPSC 826). If interested, contact Harmeet directly at hsahni@juniper.net Dear Dr. Westall, I hope you remember me from the CPSC 881 class I took in Spring 1999. That was one of the most valuable courses I ever took. After graduation I joined Marconi Communications (old FORE systems). Currently I am at Juniper networks. I am contacting you since we are looking to hire some interns for this summer. It would be great if you suggest the names of some bright students who would be interested in doing an internship at Juniper Networks. Thanks, Harmeet Subject: Reminders (This message is being sent to all CPSC 881-2 students) There will be a quiz tomorrow on sk_buffs, udpsock, and udpbind. The second milestone (socket creation binding and connecting) will be demo'ed on Wednesday. Subject: Milestone 2 (This message is being sent to all CPSC 881-2 students) Venkat has (correctly) pointed out that Milestone 2 says: " For this milestone your connect, disconnect, sendmsg, and recvmsg can be stubs.... For example: Therefore it will NOT be necessary to demonstrate a working connect tomorrow. If you can do it that will be good because it must be done eventually -- but tommorow you need only support bind(). In supporting bind you do NOT have to provide any ttp_bind() function but you will need to provide a working get_port() with sock hasher and unhasher. Subject: Quiz 3 and Milestone 2 and Material for this week (This message is being sent to all CPSC 881-2 students) We will have a quiz on Tuesday that will cover the entire Tx path from sys_sendto through the generic device driver. --- For the milestone Wednesday you should be able to demonstrate that you can send packets of the proper format and their arrival can be seen at another machine with TCP dump. They should also be able to be received correctly with my receive program. --- After we complete the devrecv material, we will pass over the iprecv files and do udpdeliver and udprecv. The next milestone will be receiving packets.. It will be quite short and will be due March 2 or 9. Subject: Next milestone and project (This message is being sent to all CPSC 881-2 students) We will demo the final milestone (receiving packets and delivery to the application) of the first project, send and receive un unacknowledged datagrams, on next Wednesday, March 2. The second project, token bucket admission control, is described in assn2.s05 in the class assignments directory. We will target a demo of that one on 16 March. Subject: Submission of best effort ttp (This message is being sent to all CPSC 881-2 students) Please place your submission in your directory in jmw:/local/jmw2/881/p1 If working in a team only submit in ONE directory. If working in a team please remember each function MUST have a designated author/maintainer documented in the code. ---------------------------------------------------- Subject: ttp open routine (This message is being sent to all CPSC 881-2 students) I may have caused confusion with my description of a "ttp_open" handler in which the ttp_opt structure was created. The struct proto element to which the "open" handler should be connected is the "init" element of the structure. Subject: Next update to ttp (This message is being sent to all CPSC 881-2 students) See assn3.s05 Subject: Next update to ttp (This message is being sent to all CPSC 881-2 students) There are places in ttp where mutex between the front end (application send thread of control) and the back end (soft irq upcall thread of control) may be necessary. The best (and most general way) is to use spin_lock_irqsave() and spin_unlock_irqrestore(). On a UP system there will be no actual spinlock used but interrupts will be enabled allowing the send logic complete without anything changing "out from under it". ------------------------------------------------------------- It was also reported today that my TTP returned a window of 255 packets. This turned out to be true (and something I should defend against) but I think it is most likely caused by an error in the sender. The offered window is set as follows: tth->win = tto->maxrxqlen - skb_queue_len(&sk->receive_queue); My receiver "trusts" the sender not to send more that it is authorized to send, but if the sender should do that anyway,tth->win would become -1 which is effectively 255. So if you should see very large offered windows, check to make sure that your usable window computation is on the mark. Subject: Arrrghh (This message is being sent to all CPSC 881-2 students) spinlock used but interrupts will be DISABLED allowing the send Subject: Quiz 5 (the last one) (This message is being sent to all CPSC 881-2 students) Please bring quiz 5 (the last one I returned) with you to class tomorrow. thanks, Subject: Talk today on networking at BellSouth (This message is being sent to all CPSC 881-2 students) Robert Cribb, a 1976 Clemson M.S. grad, and now a senior manager at BellSouth and member of the CPSC Dept's industrial advisory board has volunteered to talk to our networking students on networking and IT issues faced by BellSouth. I think this will be an interesting talk... you are encouraged to attend if you can. The talk is today at 4:00-5:00pm in McAdams 114. Subject: test protocol module (This message is being sent to all CPSC 881-2 students) I have left a new test protocol module in /home/user on david in the lab. You should use the NEW attpgobl.c along with attpad.c for testing.. Right now it DOES NOT SUPPORT FCD (flow controlled datagram) type connections. So DON"T try those. Be sure that your protocol module DOES set the TTF_AD flag in both packets and acks that it transmits and does NOT set the TTF_FCD flag. Subject: notes on the next milestone (This message is being sent to all CPSC 881-2 students) I have provided some notes and reminders regarding the present milestone in assns/assn4.s05 Subject: Questions on the projects (This message is being sent to all CPSC 881-2 students) A student has asked some good questions regarding the project and I thought I would share the questions and answers with all. > > I am working on the 881 project and was thinking about if we really need > to clone the skb to save it for possible retransmission. > Yes! > What if we just increment the skb->users (effectively share it) and store > a reference to it in the retx table. Would that not prevent kfree_skb from > releasing the buffer because skb->users is > 1? > While sharing is clearly more efficient than cloning, sharing doesn't work too well (as I found out the hard way). As the packet flows the stack, the struct sk_buff is modified in non-obvious ways that must be "undone" before the sk_buff can be re-txed successfully. In particular the netfilter system system will write a signature into the struct sk_buff and if it sees a packet with the sig already set it believes there is a LOOP IN THE PACKET FILTER. Theoretically, if one could identify and correct all such problems before doing the retx sharing might work, but there is still potential for some ugly raciness there so I don't recommend it. > When the skb is passed to NF_HOOK, it is finally passed to > hard_start_xmit(), does this function call kfree_skb()? No. This was addressed earlier in class in our discussion of the device layer. In the Tx IRQ indicating that the packet has been successfully transmitted the sk_buff is enqueued on the softnet data structure where it is eventually freed by the tx softirq (net_tx_action()) (page 17 or so in devxmit) > I can also think > of a situation where the skb needs to be retransmitted multiple number of > times and every time NF_HOOK is called it decrements the user count and we > run the risk of it being cleaned out from under us and being left with an > invalid reference. Yes! It is critically important that you DON"T LET THIS HAPPEN. The way I do it is in my retransmission code, I do: skb = skb_clone(oqe->skb, GFP_ATOMIC); where oqe points into my table of saved skb pointers and then I pass the NEW CLONE to NF_HOOK(). You MUST reclone each time you retx. Subject: Extra credit (This message is being sent to all CPSC 881-2 students) One team asked about extra credit for doing a proper connection protocol. I don't think I want to go there but I will offer 7.5 points extra credit on the overall project grade for doing CORRECTLY receiver buffering and selective retransmission on receipt of TRIPLE ACKS at the sender. You should NOT do this though unless go back n is working perfectly!! (i.e. a broken submission with receiver buffering will be worth considerably LESS than a correct solution!) Subject: Flag settings (This message is being sent to all CPSC 881-2 students) I have examined my ttp and the most likely way that I could see that Prabu could have made it massively leak memory is to send a bunch of packets with TTF_SUPV and ~TTF_ACK. So please don't do that. Every packet with TTF_SUPV should carry TTF_ACK. Subject: Info on exam (This message is being sent to all CPSC 881-2 students) The exam will take place in room 114 McAdams at 4:00 pm (except for George) Tuesday. The exam will contain an embedded "makeup quiz". (i.e. some questions will count toward both makeup and exam.) The makeup quiz can replace your lowest quiz grade. About 20% of the exam (1 out of 5 pages) will cover TCP receive processing. Subject: Possible job opportunity (This message is being sent to all CPSC 881-2 students) If any of you are seeking employment, here is an opportunity in Atlanta. Dave, the HR guy, seems a little spacy but presumably the engineers understand what they are doing. mw ----------------------------------------------------------------- Mike, #3 is required #2 is a big plus (1) correctly written device drivers (2) correctly written protocol modules (TCP or IP for example) (3) packet filter modules (which play an important roll in network security applications) (4) all of the above (5) big ugly messes in which all of the above are incestuously bundled Regards, Dave Dowling Director, HR Business Services Internet Security Systems, Inc. www.iss.net (404) 236-4046 Protection that works. Ahead of the Threat. -----Original Message----- From: Mike Westall [mailto:westall@cs.clemson.edu] Sent: Tuesday, May 24, 2005 10:45 PM To: Dowling, Dave (ISS Atlanta) Subject: Re: Network Driver Development Opportunity-ISS Just let me know if you are (1) interested in MS students who have excellent Linux kernel but NO M$ kernel experience and NO commercial experience and (2) are willing to accept international students with OPT certs ------------------------------------------------------ If the answers either (1) or (2) is NO. Then stop reading now. -------------------------------------------------------- If the answer to BOTH (1) and (2) are YES, then, if I were in your job I would compose an eloquent recruiting message that describes why your company is an excellent company to work for and that you provide salary and benefits comparable to companies such as Intel, EMC, IBM, and NetApp which also recruit our grads (and also lose the TCP/IP device driver rhetoric -- it would make a knowledgeable student nervous). If you have time to do that, I'll be glad to pass it on to the students. But if you don't have time to do that but ARE interested in our students, I'll be glad to tell those that are still perusing the job market to send you an e-mail at: DDowling@iss.net Either way is fine by me, and thanks for your interest in our students! Mike Dowling, Dave (ISS Atlanta) wrote: >>Sorry Mike. Busy day.... I will get your answers for you. I would >>like to talk to your Masters degree students. What would be the best >>way to facilitate? >> >> >>Regards, >>Dave Dowling >>Director, HR Business Services >>Internet Security Systems, Inc. >>www.iss.net >>(404) 236-4046 >>Protection that works. Ahead of the Threat. >> >>-----Original Message----- >>From: Mike Westall [mailto:westall@cs.clemson.edu] >>Sent: Tuesday, May 24, 2005 10:47 AM >>To: Dowling, Dave (ISS Atlanta); Robert Geist >>Subject: Re: Network Driver Development Opportunity-ISS >> >>Err, >> >>The name would be "Mike" or "James" or >>"Professor Westall" but not "Wes" if you mean me? >> >>------------------- >> >>Having written several network device drivers and read MANY I don't >>really grasp what you mean by TCP/IP device drivers. >> >>A properly written device driver (see any ethernet driver in Linux for >>example) has NO incestuous relationships with network and transport >>layer protocols. The Linux ethernet drivers carry DecNet, Appletalk, >>TCP/IP, and ANY user written protocol just fine and dandy with NO >>special case code that depends upon upper layer protocols in use. >> >>So it would help if you could specify whether you really mean: >> >>(1) correctly written device drivers >>(2) correctly written protocol modules (TCP or IP for example) >>(3) packet filter modules (which play an important roll in network >>security >>applications) >>(4) all of the above >>(5) big ugly messes in which all of the above are incestuously bundled >> >>Next, next you seem to have TWO sets of skill and knowledge >>requirements.. one much more stringent than the other. Is one for >>entry level people and another for senior people??? >> >>As an educational institution we don't produce many graduates who >>already have 6 years of "commercial experience", and because of the >>not-so-open nature of the M$ Window$ OS we don't really produce any >>graduates with experience working in M$ kernel/driver/protocol >>development. >> >>We do however produce Master's degree holders who understand how to >>build Linux device drivers, protocol modules, and packet filters. >> >>If you are interested in a person with that skillset I would be glad to >>pass whatever information you would like on to this year's group. >>(There are only about 6 of them this year and at least half already >>have secured employment so I recommend that you hurry.) >> >>Oh, and ALL of them are international students so if you don't hire >>people with OPT work certs, I am afraid we don't have anyone likely to >>meet your needs. >> >>Regards, >>J. M. Westall >>Professor of Computer Science >> >> >>Dowling, Dave (ISS Atlanta) wrote: >> >> >> > >>>>Thanks Robert. Wes, Any assistance would be greatly appreciated. >>>> >>>> >>>>Regards, >>>>Dave Dowling >>>>Director, HR Business Services >>>>Internet Security Systems, Inc. >>>>www.iss.net >>>>(404) 236-4046 >>>>Protection that works. Ahead of the Threat. >>>> >>>>-----Original Message----- >>>>From: Robert Geist [mailto:rmg@cs.clemson.edu] >>>>Sent: Tuesday, May 24, 2005 9:07 AM >>>>To: Dowling, Dave (ISS Atlanta) >>>>Cc: westall@cs.clemson.edu >>>>Subject: Re: Network Driver Development Opportunity-ISS >>>> >>>> >>>>You might try James (Mike) Westall (westall@cs.clemson.edu). >>>>He's the leader of our networking research group, and he would know if >>>> >>>> > >> >> >> > >>>>any current graduate students have started looking for jobs. >>>> >>>>Also, companies can get R&D work done at reasonable costs through the >>>>University by jointly developing and then funding R&D grant proposals >>>>for specific projects. Mike could tell you about that, if you're >>>>interested. As an example, IBM funded Mike and me to develop the >>>>Linux ATM driver for the Turboways 25. >>>> >>>>-RG >>>> >>>> >>>> >>>> >>>>On Tue, 24 May 2005, Dowling, Dave (ISS Atlanta) wrote: >>>> >>>> >>>> >>>> >> >>>>>>Robert, >>>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>>>>I am the Director of HR Business Services for Internet Security >>>>>>>>Systems (www.iss.net). I found your contact information on Google. >>>>>>>>We are looking for a few Network Driver Development Engineers as >>>>>>>>our >>>>>>>> >>>>>>>> > >> >> >> > >>>>>>>>business expands and wanted to see if you knew anyone that I could >>>>>>>>network with. >>>>>>>> >>>>>>>>Internet Security Systems is an exciting company to work for and is >>>>>>>>the leader in the network security space. >>>>>>>>Internet Security Systems, Inc. (ISS) was founded in 1994 by >>>>>>>>Christopher W. Klaus and made its initial public offering on the >>>>>>>>NASDAQ on March 23, 1998. The company provides security products and >>>>>>>> >>>>>>>> >> >>>> >>>> >> >>>>>>>>services that preemptively protect enterprise organizations against >>>>>>>>Internet threats. ISS celebrated its 10th anniversary in 2004 and >>>>>>>>has commanded the leading edge of security innovation, inventing >>>>>>>>cornerstone technologies such as vulnerability assessment and >>>>>>>>intrusion detection/prevention. The company continues to set >>>>>>>>standards in the security space with its Proventia Enterprise >>>>>>>>Security Platform (ESP), offering enterprise-wide preemptive >>>>>>>>protection that is tightly integrated with existing IT business >>>>>>>> >>>>>>>> >> >>>>processes. >>>> >>>> >>>> >> >>>>>>>>TCP/IP Network Driver Development >>>>>>>> >>>>>>>>Working with a talented team of engineers to deliver high-quality >>>>>>>>security solutions. Must possess system design skills, strong >>>>>>>>programming skills, and be a team player. >>>>>>>> >>>>>>>>Skills & Knowledge requirements: >>>>>>>>- Development and maintenance of TCP/IP network drivers >>>>>>>>- Demonstrable experience in commercial software development >>>>>>>>- Solid programming skills on Microsoft Windows platforms >>>>>>>>- Experience in computer / information security Responsibilities >>>>>>>>Skills & Knowledge requirements: >>>>>>>>- Development and maintenance of TCP/IP network drivers >>>>>>>>- Demonstrable experience in commercial software development >>>>>>>>- Solid programming skills on Microsoft Windows platforms >>>>>>>>- Experience in computer / information security Qualifications - At >>>>>>>>least 6 years of commercial software development experience >>>>>>>>- At least 5 years of Windows TCP/IP network driver experience >>>>>>>>- Demonstrable experience in product design and architectural >>>>>>>>aspects >>>>>>>>- Excellent interpersonal skills to work effectively with >>>>>>>>development >>>>>>>> >>>>>>>> > >> >> >> > >>>>>>>>team and other groups >>>>>>>>- Understanding and appreciation of software engineering principles >>>>>>>>and practices >>>>>>>>- Excellent written and verbal communications skills >>>>>>>>- Self-motivated and driven >>>>>>>> >>>>>>>>Equal Opportunity Employer M/F/V/D >>>>>>>> >>>>>>>>Regards, >>>>>>>>Dave Dowling >>>>>>>>Director, HR Business Services >>>>>>>>Internet Security Systems, Inc. >>>>>>>>www.iss.net >>>>>>>>(404) 236-4046 >>>>>>>>Protection that works. Ahead of the Threat. >>>>>>>> >>>>>>>> >>>>>>>> > >> >> >> >> >> >> >> >>