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@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@gmail.com>wrote:
On Wed, Dec 4, 2013 at 7:49 PM, Peter Teoh <htmldeveloper@gmail.com>wrote:
On Mon, Dec 2, 2013 at 1:48 PM, Guibin(Bill) Tian <gbtian@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
-- Regards, Peter Teoh
-- Regards, Peter Teoh