关于构造Http Response包的问题

Godbach

当我判断到Http Get请求时，我要直接给请求方发送一个Response包。这里涉及到构造数据包的问题。

如果采用修改请求包的方式，要调整的地方：
IP层，源与目的地址，TTL
TCP层，源与目的端口号，SEQ和ACK number
应用层的话，就是构造出来一个Response包。如果基于原先请求包的修改，在应用层数据部分的长度肯定是要发生变化了，这个时候，我还能用直接修改的方法，还是alloc_skb的方法呢？

Godbach

可能要修改tail指针，以及skb->len，下午测试一下

platinum

我觉得直接修改原来的包就行，改一下 skb->len 等相应长度参数（IP 头的、TCP 头的），重新计算校验和
IP 的原目的要交换，MAC 的原目的也要交换，skb->data 重新指向 MAC 头，skb->len 要加上 MAC 头的长度以及 payload 变化后的增量

Godbach

原帖由 platinum 于 2008-9-4 12:41 发表
我觉得直接修改原来的包就行，改一下 skb->len 等相应长度参数（IP 头的、TCP 头的），重新计算校验和
IP 的原目的要交换，MAC 的原目的也要交换，skb->data 重新指向 MAC 头，skb->len 要加上 MAC 头的长度以 ...

多谢白金兄指点啊。那payload变化了，是不是tail也要发生变化呢？

qps104

要是payload比原来得长得话，需要重新alloc_skb吧

Godbach

原帖由 qps104 于 2008-9-4 12:57 发表
要是payload比原来得长得话，需要重新alloc_skb吧

skb分配的时候是有固定大小的吧，一般是可以容纳下一个包的。Payload变化的话，估计调整tail指针就可以了

qps104

不是哦。你去访问下skb->tail后面得地址机器肯定死掉

ShadowStar

看你是在哪个处理流程中做了。

直接修改原始skb，再发送出去的话，例如：
rcv ()
{
send()
return
}
容易引起系统崩溃，因为dev_queue_xmit最后会kfree_skb，所以rcv之后的处理流程就会handle NULL pointer。

另外skb数据空间的大小不是固定，是根据网卡接受的大小分配的，所以skb_put前要检查tailroom

ShadowStar

原帖由 qps104 于 2008-9-4 13:09 发表
不是哦。你去访问下skb->tail后面得地址机器肯定死掉

不一定会死，但是要是put到end外面就挂了

tail到end还是有一些空间的

Godbach

原帖由 ShadowStar 于 2008-9-4 13:12 发表
看你是在哪个处理流程中做了。

直接修改原始skb，再发送出去的话，例如：
rcv ()
{
send()
return
}
容易引起系统崩溃，因为dev_queue_xmit最后会kfree_skb，所以rcv之后的处理流程就会handle NULL po ...

我这里接受数据包之后，修改之后然后发出去，这样就结束了，rcv之后的流程不会处理这个数据包了