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 <[email protected]> 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 <[email protected]>wrote: > >> >> >> >> On Wed, Dec 4, 2013 at 7:49 PM, Peter Teoh <[email protected]>wrote: >> >>> >>> >>> >>> On Mon, Dec 2, 2013 at 1:48 PM, Guibin(Bill) Tian <[email protected]>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 >>>> [email protected] >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Peter Teoh >>> >> >> >> >> -- >> Regards, >> Peter Teoh >> > > -- Regards, Peter Teoh
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
