Updated 24th Feb 1997 --------------------- ---------- Sohail Munir asks: > the raise button in demo doesnot work, Agreed. Please avoid using it. We'll see if we can fix it in the meantime. --------- Shabbir asks: Shabbir> How does the last parameter for the above function Shabbir> i.e. "char * sourcep" work? Do I need to take care of Shabbir> offsetting to the right point while fragmenting? Yes. That is the nitty-gritty of fragmentation - accounting where you are in the original packet when you are fragmenting. A hint: consider ip_data as an array of characters and use a running index on it. -------- feng wang >> How to reset the time-to-live field of ipfq(in ipreass)? is that IP_FTTL which is 6? or 0? Yes. Set it to IP_FTTL. The ipftimer periodically decrements the field. >> what's the use of BOGUS? in ipfq.ipf_state? can we ignore that? Just need to check FREE and VALID? >> Yes. Ignore it. In real networks, the table entry is marked bogus for a long time and removed only after a timeout to avoid getting late fragments. ---------- jianping jiang >> >> I get errors like: oops, something wrong... oops, something wrong... oops, something wrong... oops, something wrong... Empty n_pdu IOT trap >> This "oops.." is in network_layer_wrappers.c in AddPDUToOrderedList, when you try to add another pdu with the same ordered list index (ie the same 13-bit frag offset) ... check where you are adding to the ordered list and look at the index you are passing ... >> I got this message running the codes: Empty n_pdu then it just stopped there. What could cause this message? >> The DLC layer checks to see if it has received an n_pdu, when it expects to. If not, it simply exits the program... Please set the type field in the pdu ... >> DatalinkToPhysical(DLC_LAYER_ENTITY_TYPE *dlc_layer_entity, PDU_TYPE *pdu_from_network) { PDU_TYPE *pdu_to_physical = (PDU_TYPE *)pdu_alloc(); if (pdu_from_network->type != TYPE_IS_N_PDU) panic("Empty n_pdu\n"); . . . >> ------------ Jiangxin Chen >> >> Empty n_pdu IOT trap (core dumped) which is similar to the error you mentioned in Lab2.faq. But the difference is that I use fmr.config which doesn't require any fragmentation and reassembly. Furthermore, when in fmr.config, the error occurs after 75% of the image has been received at node 2. Even if I use fmr2.config, node 2 can still receive some completely reassembled packets before the error comes out. If there's some errors about the packet type in my program, the error should have appeared at the beginning and it should not influence the performance of fmr.config. Because if no fragmentation is needed, I won't do anything to the pdu, simply return it. Can you figure out what is the probelm? In addition, I find that in the handout, DropPDU() is to free the pdu, but in function NetworkToApplication(), pdu_free() is used to free the pdu. Is there any difference between these two functions? Which one should we use when freeing the pdu in ipfcons() and FragmentPacketAndSendToDLC()? >> Answer to your second question first: yes, DropPDU() and pdu_free() are identical. You can use one instead of the other... For your first question, I suspect that you are probably not freeing pdus correctly (following the comments given in the network_layer.c file - nothing more, nothing less!) Else, you might have some loose pointer pointing to some wierd location causing a sanity check error as you observe... ------------ Hui Mei Lai >>> >> app2: Unknown packet type app2: Unknown packet type app2: Unknown packet type @ Empty N_pdu IOT trap Is this normal? >> Obviously not ! I am guessing that you have some pointer problems: for example: you are allocating a packet (through createpacket) but not deallocating it in the appropriate places (through pdu_free) as mentioned in the code comments ... One more possibility is that you are not maintaining/updating indices correctly while creating/reassembling fragments. ------- Feng Wang >> >> Am I supposed to recompile network_wrapper.c if I add some fields in network_layer.h? what files else need to be recomiled? revise the makefile? I am not sure what to do with the .a .o file. This is for the statistical requirement. >> No, no. You have a copy of the network_layer.h in your local directory. (with your modifications) If you have modified network_layer_wrappers.c, you have one in your local directory. The wrappers file is #include'd in network_layer.h The makefile will look at your local directory first before looking at the defaults area. So, your compilation should go through without changes to the makefile. --------- steven andrew smith >> > Can we just put an MF variable in the N_PDU_TYPE declaration in pdu.h? No. You have to use the bit in the header: you cannot change IP header format. > if not, how are we supposed to set/check the flag? I am presently ORing the ip_fragoff with IP_MF to set, and then using (fragoff & IP_MF)!=0 to check it. > Right way to do it. >> However, for ipreass(), there is a case in which fragoff should equal 0, but MF should be set(the first packet in a fragmented group). But if I set MF by ORing it with 0, I will get MF, which is decimal 8192. Or is this avoided because we are using short instead of int for fragoff? >> To just check the 13-bit frag offset part without looking at the MF flag, you can use the bitmask IP_FRAGOFF defined in pdu.h If you do (fragoff & IP_FRAGOFF) you get the lower order 13 bits ... >> /* check if reassembly complete. If so, join the fragments and return reassembled pdu, else return NULL : ipfjoin() */ I'm stuck on this part. How do I check if reassembly is complete? Do I use nfrags? >> What I mean is that you call ipfjoin to do this function. See the comments in ipfjoin().... > so is it just return(ipfjoin(piq))? And any statistics collection you may want to do... >> if I do that, I can't get to the /* If you are here => you haven't found a match in the fragment lists */ /* Use the free spot to create a new fragment list */ >> Yes you can (each time in the loop, you hit the continue statement ...) -------- chi chung lam >> In 6.(d), I'm not sure how the number of packets dropped and the number of fragments lost are defined. Suppose there are only 3 packets, each divided into 2 fragments. And the receiver gets both fragments of packet 1, only 1 fragment of packet 2, and nothing of packet 3. Then, should the number of packets dropped be 2 (packets 2 & 3), and the number of fragments lost be 4 (all fragments of packets 2 & 3)? If not, what are the correct answers? >> Packets may be "dropped" in the network or in the destination due to timeout. Fragments are "lost" only in the network. You know from the previous configuration what is the total number of fragments created. Count all the fragments received at the destination - the rest have been lost in the network. Don't count fragments dropped at the destination due to timeout as "dropped" For example, if the source sends 1 packet which is broken into 2 fragments, one of which reaches the destination, the packet will be dropped at the destination due to timeout. Then, num_pkts_lost = 1 num_frags_lost = 1 Another related question is what happens if the packet/fragment is dropped before it ever reaches the router... How many fragments are there in this case ? For simplicity, let us assume (hypothetically) that the errored packets/fragments are detected only at the destination DLC. So, from the previous config, you know the total fragments created. From this config, you know the total fragments received at the destination. We will assume that the rest are lost. ------------ > How to count number of fragments created in the routers: Initialize a global variable to 329 (total number of packets sent). At a router where N fragments are created, add N-1 to this variable. --------------- thomas michael von hoene>> >> Do we have to go through and intialize the entries in fragment table to be IPFF_FREE? When I print out the intial values for ipf_state, it's always zero, which isn't even a legal value (VALID=1, BOGUS=2, FREE=3). I don't see where we could do this since it needs to be done exactly once, but all we are writing are the functions. Or am I just completely missing something? Because no free spot is ever found, my program just throws all the pdu's away right now. I tried chaning IPFF_FREE to be zero, but I don't think my pdu.h is even being included, because when I typed make after changing it, nothing happened, and I don't even see pdu.h being included anywhere. If it's included in aother header, but that header is located elsewhere, the compiler will look where the first header is located for pdu.h, not your local directory. At least that's my understanding. >> network_layer_wrappers.c has a routine cn_start() which initializes ipf_state to IPFF_FREE. I don't know when you print your values, but they should be initialized to FREE when you receive packets at the destination ... Try checking at ipreass() if you have not done so already... Your changes to pdu.h will not be effective because it has already been compiled into the object libraries given to you in the defaults area ... Only network_layer.h is open to adding new variables since network_layer.o is not among the object files. ----------- thomas michael von hoene>> >> My lab does exactly as it should - all the fragments are received and successfully reassembled into packets. The graphs look just like they should. The only problem is that it runs very slowly. The first 20 packets come quickly, but the it starts to degenerate - it runs slower and slower. At about 80 packets I get an out of memory message. Any ideas? >> I suspect you are allocating packets but not deallocating them. So, there is a "memory leak" and you run out of memory ... check wherever you are allocating packets... Or where you are creating fragments and not destroying the original packet etc ... ------ xiangrong cai >> >> % make gcc -O -g network_layer.c In file included from network_layer.c:2: /n/park/0/cise/cis678/Lab2/defaults/sim.src/cisePort.h:48: compat/limits.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `network_layer.o' >> No clue on this one. Are you compiling on HPs (same environment as everybody else ?) ... Your environment/paths may be messed up ... --------------- Waiting for your frequently asked questions ... Please post your questions to the newsgroup cis.course.cis678 and send me email too - for fastest response. -Shiv (shivkuma@cis)