about cheating upper layers

Peter Teoh htmldeveloper at gmail.com
Wed Dec 4 06:49:37 EST 2013


On Mon, Dec 2, 2013 at 1:48 PM, Guibin(Bill) Tian <gbtian at gmail.com> wrote:

> Hi there,
> Right now, I am trying to do such a thing.
>
> If a computer has multiple interface A and B, assume the packet is from
> device A.
> At ip layer, before the packet is transmitted to transport layer, I change
> the source address and destination address of the IP header and transmit to
> transport layer to pretend that this packet is from device B. Not sure
> whether this can work or not.
>

feasible?   yes, theoretically u can change IP address, but there is a
problem.   TCP port + IP address is combined together to uniquely identify
which "socket" to pass to.   And each socket is always associated with each
process.   if u change that the packet will be redirected to another
process.   (this process context identification is done in the upper layer
of TCP, ie, in interrupt context the packet has not been associated with
any process yet.)

and remember there is a checksum (TCP and IP) that need to be patched
whenever u change anything.

not sure why u want to that, but I suspect Netfilter should fulfill your
requirement as well?


>
> There are other interface specific information in the skb structure like
> the net_device member. If I pass the packet to transport layer only with my
> proposed modification, will the application's sockehit detect this? I
> didn't look into the socket match code, not sure if the socket match will
> check other information in skb struct beside the ip address and port number.
>
> Thanks for your help.
>
> Bill
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20131204/e6133e48/attachment.html 


More information about the Kernelnewbies mailing list