about cheating upper layers

[Peter Teoh]

what you said about ip_rcv() should work, since it is even earlier than
tcp, so no problem.

your ip address translation is exactly what NAT is doing, so u definitely
can remap it to what address u like.

but port + IP address does not imply anything about which NIC port it is
coming from.   perhaps the L2/MAC layer can provide the redirection....this
part I am not sure.



On Thu, Dec 5, 2013 at 1:41 AM, Guibin(Bill) Tian <gbtian at gmail.com> wrote:

> 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
>>
>
>


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