about cheating upper layers

[Guibin(Bill) Tian]

Thanks Peter for your explanation.  But in fact, I am not going to touch
transport layer. The work shall be done inside the call stack of ip_rcv().

In ip layer, there is no specific process information, so the process
assignment shouldn't be a problem.
At the application layer, each application maintains its own socket pair.

My concern is that if the packet is from another NIC rather than the one
used to make the connection, can I make it transparent to the application
by only modifying the source and destination address in the ip header?



On Wed, Dec 4, 2013 at 12:01 PM, Peter Teoh <htmldeveloper at gmail.com> wrote:

>
>
>
> On Wed, Dec 4, 2013 at 7:49 PM, Peter Teoh <htmldeveloper at gmail.com>wrote:
>
>>
>>
>>
>> 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?
>>
>>
>
> Sorry, not sure if the earlier explanation is clear to you?
>
> So to be specific:
>
> in net/ipv4/tcp_ipv4.c:
>
> This is from the ingress path (still executing in software interrupt
> context mode, ie, packet has not been assigned to any process yet, and so
> you can always modify the packet content):
>
> int tcp_v4_rcv(struct sk_buff *skb)
> {
>         const struct iphdr *iph;
>         const struct tcphdr *th;
>         struct sock *sk;
>         int ret;
>         struct net *net = dev_net(skb->dev);
>
>         if (skb->pkt_type != PACKET_HOST)
>                 goto discard_it;
>
>         /* Count it even if it's bad */
>         TCP_INC_STATS_BH(net, TCP_MIB_INSEGS);
>
>         if (!pskb_may_pull(skb, sizeof(struct tcphdr))
>
> and in include/net/sock.h:
>
> /* This is the per-socket lock.  The spinlock provides a synchronization
>  * between user contexts and software interrupt processing, whereas the
>  * mini-semaphore synchronizes multiple users amongst themselves.
>  */
> typedef struct {
>         spinlock_t              slock;
>         int                     owned;
>         wait_queue_head_t       wq;
>         /*
>
> To modify the packet, you can either do it before the above function, or
> after the function, but before the packet gtet assigned to its rightful
> owner.   ****MY GUESS*****!!!!
>
>
>>
>>> 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
>>
>
>
>
> --
> Regards,
> Peter Teoh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20131204/e7680f8d/attachment.html