Re: Using ipf_inject_input with Local Packets
Re: Using ipf_inject_input with Local Packets
- Subject: Re: Using ipf_inject_input with Local Packets
- From: Raj Doshi <email@hidden>
- Date: Tue, 21 Jun 2005 18:57:02 -0400
Hi,
I just wanted to follow up on this problem to indicate that Josh was
correct and the checksum and the checksum flags were not getting
copied over to the new mbuf. I added the following line of code for
packets on the loopback interface to fix this:
mbuf_set_csum_performed(my_new_mbuf, MBUF_CSUM_DID_IP |
MBUF_CSUM_IP_GOOD | MBUF_CSUM_DID_DATA | MBUF_CSUM_PSEUDO_HDR, 65535);
It seems that in addition to the four flags, the checksum value
"65535" is necessary for the packet not to be dropped.
Thanks,
Raj Doshi
On Jun 20, 2005, at 11:39 AM, Josh Graessley wrote:
It may be possible that you aren't setting the rcvif correctly in
the mbuf pkthdr. There is a check that the loopback packets are
received on the loopback interface. Another possibility is that the
checksum related flags are not being carried over. These flags
indicate what checksums were performed in hardware. The loopback
uses a trick where it never calculates the checksums on transmit.
When the packet is looped back, the loopback interface sets the
flags indicating that the checksums were calculated in hardware on
the card and the checksums are correct. If you strip the flags
indicating the checksum was correct according to hardware, the
checksums will be performed in software. Since they were never
calculated on the outbound path, the checksums will be wrong and
the packet will be dropped. Look for bad checksums using netstat -s.
Or it could be something else completely.
-josh
On Jun 19, 2005, at 11:16 PM, Raj Doshi wrote:
Hello,
I would first like to thank Vincent Lubet for his help with my
previous question on this list. Now, I have another question:
I'm intercepting incoming packets in my kext with KPI IP filters
(Mac OS X 10.4.1), sending them to a user-space process, getting
them back (possibly modified) from the user-space process, and re-
injecting them with ipf_inject_input. I've got this working fine
in most cases, like when accessing remote web sites. However,
http connections to 127.0.0.1:80 fail and result in messages like
"NetInfo connection failed for server 127.0.0.1/local" in
console.log. To attempt to isolate the problem, I've tried the
following:
1. Immediately re-injecting the mbuf that I receive from the
filter. In this case, the local connection works.
2. Immediately re-injecting a copy (using mbuf_dup) of the mbuf
that I receive from the filter. In this case, the local
connection fails.
I am wondering what I can do so that these local connections will
still work when I inject a copy of the original mbuf. If there is
no good solution to this, then I am wondering exactly for which
packets I need to avoid making copies of the mbuf.
Thanks,
Raj Doshi_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden