site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Sep 17, 2004, at 21:55, Matt Jaffa wrote: Here is how I am formulating my IP header: newip->ip_hl = 5; newip->ip_v = ipHeader->ip_v; printf("ipHeader version: %d\n", ipHeader->ip_v); printf("ipHeader hdrleng: %d\n", ipHeader->ip_hl); printf("newipheader: %d\n", newip->ip_v); printf("newipheader: %d\n", newip->ip_hl); BTW, I would set ip_off to zero. newip->ip_ttl = 35; newip->ip_p = ipHeader->ip_p; newip->ip_sum = 0; You compute the checksum later, right? Regards, Justin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... ipHeader is the ip header pulled out from the mbuf that I am not letting out into the internet. struct ip* newip = (struct ip*)_MALLOC(sizeof(struct ip),M_FREE,M_NOWAIT); Why are you using _MALLOC instead of (say) MGET? You may be asking for trouble here, unless you are taking care of properly releasing this storage. Well, what do the printf's say? FWIW, the kernel code defines _IP_VHL, and refers to the two fields as the combined field 'ip_vhl'. Why not print a hex dump of the first few bytes of the two IP headers? That may provide a clue (and it avoids any funky behavior based on bit-field operations). newip->ip_tos = 0; int data_len = strlen(httpresponse); // this is the HTTP/1.1 response length of the tcp data I will inject into the input I assume the length of this canned response is small enough that you don't have to worry about overflowing whatever you are using for buffers. newip->ip_len = sizeof(struct ip) + sizeof(struct tcphdr) + data_len; newip->ip_id = 34234; newip->ip_off = 0x4000; memcpy(&(newip->ip_src), &(ipHeader->ip_dst), sizeof(struct in_addr)); memcpy(&(newip->ip_dst), &(ipHeader->ip_src), sizeof(struct in_addr)); For correctness, you might want to assure that the values you are copying are in network order (since the IP stack has set it up that way on output). For PowerPC, host order and network order are the same, but it pays to keep this straight in your code. despite the fact that some of the other stuff might be wrong, why wouldn't the ip_v be the right version? The output does print out 4 like it should be. Any number of things could be wrong. One obvious possibility is that when you finally cons up the frame you inject, you aren't matching the assumptions of the input processing, so that when that code looks looks at the IP header, it's not seeing your IP header (e.g., there should be an ethernet header, but isn't; or there is an ethernet header, but there should not be one). To emphasize a point above, do *not* allocate mbufs other than by MGET (or similar call) unless you are actually obeying all the rules for supplying your own buffers (and freeing same). -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *--------------------------------------*-------------------------------* This email sent to site_archiver@lists.apple.com