Chinaunix

标题: 多谢 Godbach指点。还有点小问题 [打印本页]

作者: 故哈 时间: 2009-08-18 14:46
标题: 多谢 Godbach指点。还有点小问题
首先感谢一下Godbach版主。真是拨开云雾见晴天啊

修正Godbach的一处错误

1 iph->check=ip_fast_csum((unsigned char *)iph, iph->ihl*4);
这里的iph->ihl不需要乘以4了如果乘以4,接收端会认为校验和错误

现在的问题是client受到了返回的http包.但是浏览器没有显示返回包的内容,还依旧不停的给真正的服务器发get包
通过抓包发现数据是发过来了

附件是我抓包的结果,

用Wireshark 打开，并加上 tcp.port==80的过滤过则。

[ 本帖最后由故哈于 2009-8-18 14:48 编辑 ]

tcp.port==80.zip

16.6 KB, 下载次数: 41

作者: Godbach 时间: 2009-08-18 14:58
不用客气。

那个地方确实写错了，源代码中就是直接使用iph->ihl。当时修改的多了，就直接拷贝了。结果把这个地方给弄错了。

作者: Godbach 时间: 2009-08-18 14:59
不过里面至少存在两个问题。你要结合实际的应用做一下对应的考虑。

作者: Godbach 时间: 2009-08-18 15:01
首先看一下，你抓到的包有没有诸如seq，ack之类的错误

作者: Godbach 时间: 2009-08-18 15:03
另外，这个报文构建的是不是有问题，不符合浏览器内核的规格。

作者: platinum 时间: 2009-08-18 15:06

原帖由故哈于 2009-8-18 14:46 发表
现在的问题是client受到了返回的http包.但是浏览器没有显示返回包的内容,还依旧不停的给真正的服务器发get包
通过抓包发现数据是发过来了

你做了什么吗？TCP 序号全是错的

作者: Godbach 时间: 2009-08-18 15:12
标题: 回复 #6 platinum 的帖子
呵呵，还是构造回探包啊。难道是计算错了吗？

作者: Godbach 时间: 2009-08-18 15:14

首先感谢一下Godbach版主。

其实构造回探包的实现，我是从白金兄那里学来的。

如果要感谢，还是要感谢白金兄啊。

作者: 故哈 时间: 2009-08-18 15:21

原帖由 platinum 于 2009-8-18 15:06 发表

你做了什么吗？TCP 序号全是错的

序列号都是重新赋值的

tmp=tcph->ack;
printk("tmp=%02X\n", tmp);
tcph->ack=htons(ntohs((tcph->seq)+ tcp_datalen));
printk("tcp->ack=%02X\n", tcph->ack);
tcph->seq= tmp;

作者: 故哈 时间: 2009-08-18 15:22

原帖由 Godbach 于 2009-8-18 15:14 发表

其实构造回探包的实现，我是从白金兄那里学来的。

如果要感谢，还是要感谢白金兄啊。

都感谢

作者: Godbach 时间: 2009-08-18 15:22
把tmp变量改成unsigned long型的吧

作者: 故哈 时间: 2009-08-18 15:27

原帖由 Godbach 于 2009-8-18 15:22 发表
把tmp变量改成unsigned long型的吧

还是不行。应该不是类型的问题。抓包报的是ack和seq是错的，可是看代码看不出什么问题，是和你昨天说那种方法一样的

作者: Godbach 时间: 2009-08-18 15:33

原帖由故哈于 2009-8-18 15:27 发表

还是不行。应该不是类型的问题。抓包报的是ack和seq是错的，可是看代码看不出什么问题，是和你昨天说那种方法一样的

你把接收到的包和发送出去的包的ack和seq比较一下看看是否符合计算的方法

作者: Godbach 时间: 2009-08-18 15:35
成员变量用的不对啊，改成这样：

tmp=tcph->ack_seq;
tcph->ack_seq=htonl(ntohl(tcph->seq)+ tcp_datalen);
tcph->seq= tmp;

作者: 瀚海书香 时间: 2009-08-18 15:36
标题: 回复 #8 Godbach 的帖子
可否讲解一下如何构造回探包

作者: 故哈 时间: 2009-08-18 15:43

原帖由 Godbach 于 2009-8-18 15:35 发表
成员变量用的不对啊，改成这样：

ack不赋值了？

作者: Godbach 时间: 2009-08-18 15:46
ACK本身就是一个标记位，上一个数据包肯定有ACK置位的，这里咱们修改的是seq和ack的序列号

作者: Godbach 时间: 2009-08-18 15:49

原帖由 瀚海书香 于 2009-8-18 15:36 发表
可否讲解一下如何构造回探包

看一下这篇帖子
http://linux.chinaunix.net/bbs/thread-1029601-1-1.html

作者: 故哈 时间: 2009-08-18 16:07

原帖由 Godbach 于 2009-8-18 15:35 发表
成员变量用的不对啊，改成这样：

赋值赋不上了

printk("old tcph->ack_seq=%u\n", ntohl(tcph->ack_seq));
      printk("old tcph->seq=%u\n", ntohl(tcph->seq));

      tmp=tcph->ack_seq;
      tcph->ack_seq=htonl(ntohl(tcph->seq)+ tcp_datalen);
      tcph->seq=tmp;

      printk("tcph->ack_seq=%u\n", ntohl(tcph->ack_seq));
      printk("tcph->seq=%u\n", tmp);

old tcph->ack_seq=2847419816
old tcph->seq=2484901326
tcph->ack_seq=2484904361
tcph->seq=2821568681

疯了

作者: platinum 时间: 2009-08-18 16:10

原帖由 Godbach 于 2009-8-18 15:14 发表

其实构造回探包的实现，我是从白金兄那里学来的。

如果要感谢，还是要感谢白金兄啊。

惭愧啊，我现在连构造 TCP 的 RST 还没实现呢

[ 本帖最后由 platinum 于 2009-8-18 16:11 编辑 ]

作者: 故哈 时间: 2009-08-18 16:11

原帖由 platinum 于 2009-8-18 16:10 发表

惭愧啊，我现在连构造 TCP 的 RST 还没实现呢
小伟之前做的那个是什么来着？我都忘记了

我这有个rst函数。一直在用

作者: platinum 时间: 2009-08-18 16:13

原帖由故哈于 2009-8-18 15:21 发表

序列号都是重新赋值的

tmp=tcph->ack;
printk("tmp=%02X\n", tmp);
tcph->ack=htons(ntohs((tcph->seq)+ tcp_datalen));
printk("tcp->ack=%02X\n", tcph->ack);
tcph->seq= tmp;

那之后的数据也要维护这个序号差值才行

作者: 故哈 时间: 2009-08-18 16:14

原帖由 platinum 于 2009-8-18 16:13 发表

那之后的数据也要维护这个序号差值才行

没有之后的了就是类似防盗链一样的东西发现非法的了就给客户端返回一个错误页面

作者: kwest 时间: 2009-08-18 16:15
看来大家对http tcp劫持都很有兴趣，都想学电信推广告了？

作者: Godbach 时间: 2009-08-18 16:19

原帖由 platinum 于 2009-8-18 16:10 发表

惭愧啊，我现在连构造 TCP 的 RST 还没实现呢

最初是构造ICMP的回应包啊。

RST包构造需要做哪些调整啊？

[ 本帖最后由 Godbach 于 2009-8-18 16:21 编辑 ]

作者: Godbach 时间: 2009-08-18 16:20

原帖由故哈于 2009-8-18 16:14 发表

没有之后的了就是类似防盗链一样的东西发现非法的了就给客户端返回一个错误页面

是啊，这个不是代理，就返回一次就可以了。

作者: 故哈 时间: 2009-08-18 16:23
tcph头会不会取错了？应该不会啊为什么取出来的seq值和seq_ack值和抓到的不一样呢？

作者: Godbach 时间: 2009-08-18 16:23
标题: 回复 #21 故哈的帖子
就是你调用的那个send_reply函数吗。这个函数发回的就是RESET报文？

作者: Godbach 时间: 2009-08-18 16:24

原帖由故哈于 2009-8-18 16:23 发表
tcph头会不会取错了？应该不会啊为什么取出来的seq值和seq_ack值和抓到的不一样呢？

这个地方是不是显示的问题，即网络字节序和主机字节序的问题。

你把值贴出来看看

作者: 故哈 时间: 2009-08-18 16:25

原帖由 Godbach 于 2009-8-18 16:23 发表
就是你调用的那个send_reply函数吗。这个函数发回的就是RESET报文？

确定肯定能用的那个函数。用了1年多了。。。。。

作者: 故哈 时间: 2009-08-18 16:27

原帖由 Godbach 于 2009-8-18 16:24 发表

这个地方是不是显示的问题，即网络字节序和主机字节序的问题。

你把值贴出来看看

ntohl old tcph->ack_seq=4179092007
ntohl old tcph->seq=1997420798

ntohl tcph->ack_seq=1997423833
ntohl tcph->seq=4179092007

%U打印

作者: Godbach 时间: 2009-08-18 16:28
看看十六进制是多少啊

作者: Godbach 时间: 2009-08-18 16:31
用十六进制打印收到报文的seq和ack_seq, 以及构造的seq和ack_seq
并且打印出收到报文载荷的长度，和新构造报文载荷的长度

作者: 故哈 时间: 2009-08-18 16:36

原帖由 Godbach 于 2009-8-18 16:31 发表
用十六进制打印收到报文的seq和ack_seq, 以及构造的seq和ack_seq
并且打印出收到报文载荷的长度，和新构造报文载荷的长度

old tcp_datalen 3035
old tcp_totlen 3055
old tcph->ack_seq=f2026212
old tcph->seq=fb686a5d
tcph->ack_seq=d6746a5d
tcph->seq=f2026212
new tcp_datalen 55256
new tcp_totlen 55276

感觉新包有问题

length是十进制

作者: 瀚海书香 时间: 2009-08-18 16:38
标题: 回复 #18 Godbach 的帖子
多谢

作者: platinum 时间: 2009-08-18 16:41

原帖由故哈于 2009-8-18 16:27 发表

%U打印

真正的 seq 和 ack 就是一个乱七八糟的数
wireshark 里看到的数实际上是与第一个 syn 的差值

如果想得到真正的序号，你需要把 syn 时候的数值记录下来，之后的序号去减这个 syn 的值就可以了

作者: 故哈 时间: 2009-08-18 16:45

原帖由 platinum 于 2009-8-18 16:41 发表

真正的 seq 和 ack 就是一个乱七八糟的数
wireshark 里看到的数实际上是与第一个 syn 的差值

如果想得到真正的序号，你需要把 syn 时候的数值记录下来，之后的序号去减这个 syn 的值就可以了

这样的话如果我想要知道正确的值的话就只能在握手的时候就记录每一条连接的seq值？

这样岂不是涉及到连接跟踪了？

god版主也是这么做的么？

[ 本帖最后由故哈于 2009-8-18 16:47 编辑 ]

作者: Godbach 时间: 2009-08-18 16:47
old tcp_datalen 3035
new tcp_datalen 55256

新的报文这么大啊，不对吧，MTU在以太网上也就1500啊，有分片了吗？

作者: 故哈 时间: 2009-08-18 16:49

原帖由 Godbach 于 2009-8-18 16:47 发表
old tcp_datalen 3035
new tcp_datalen 55256

新的报文这么大啊，不对吧，MTU在以太网上也就1500啊，有分片了吗？

我在对端接收的包是没有分片的

我是在新包发送之前取的值

tcp_totlen = iph->tot_len - iph->ihl*4;
      tcp_datalen = tcp_totlen -  tcph->doff*4;
      printk("new tcp_datalen %d\n", tcp_datalen);
      printk("new tcp_totlen %d\n", tcp_totlen);
      ret=dev_queue_xmit(skb);
      if(ret==-1){
            printk("send error\n");
      }

作者: Godbach 时间: 2009-08-18 16:49

原帖由故哈于 2009-8-18 16:45 发表

这样的话如果我想要知道正确的值的话就只能在握手的时候就记录每一条连接的seq值？

这样岂不是涉及到连接跟踪了？

god版主也是这么做的么？

你这里只是发送一次，你从skb中获取到的就是绝对值。这个应该没有问题，不用记录的。

作者: Godbach 时间: 2009-08-18 16:50
标题: 回复 #39 故哈的帖子
对照seq，看你抓到的包，载荷长度多大？

作者: 故哈 时间: 2009-08-18 16:51

原帖由 Godbach 于 2009-8-18 16:49 发表

你这里只是发送一次，你从skb中获取到的就是绝对值。这个应该没有问题，不用记录的。

从打印的来看赋值应该是成功了但是对端认为是错误的

作者: Godbach 时间: 2009-08-18 16:53
TCP报文的长度在以太网上是有限制的，怎么会那么大的，肯定有问题.

作者: 故哈 时间: 2009-08-18 16:54

原帖由 Godbach 于 2009-8-18 16:50 发表
对照seq，看你抓到的包，载荷长度多大？

没明白

作者: Godbach 时间: 2009-08-18 16:57
你内核中有打印的出来的包，wireshark还有抓到的包，对比一下啊

作者: 故哈 时间: 2009-08-18 16:58

原帖由 Godbach 于 2009-8-18 16:57 发表
你内核中有打印的出来的包，wireshark还有抓到的包，对比一下啊

抓到的包是对的

这边get的时候 seq和ack都是1 长度是3305

我返回的包 seq 是1 ack是3306

作者: Godbach 时间: 2009-08-18 16:59
标题: 回复 #46 故哈的帖子
看绝对值，老大

作者: 故哈 时间: 2009-08-18 17:00

原帖由 Godbach 于 2009-8-18 16:59 发表
看绝对值，老大

raw data？

作者: Godbach 时间: 2009-08-18 17:01
另外，看一下分片标记位是否置位了

作者: Godbach 时间: 2009-08-18 17:01

原帖由故哈于 2009-8-18 17:00 发表

raw data？

序列号的绝对值，十六进制数值，不是这个1什么的，这个是相对的

作者: platinum 时间: 2009-08-18 17:02

原帖由故哈于 2009-8-18 16:45 发表

这样的话如果我想要知道正确的值的话就只能在握手的时候就记录每一条连接的seq值？

这样岂不是涉及到连接跟踪了？

god版主也是这么做的么？

如果你想知道目前序号是这个链接中的多少，当然要有类似链接追踪的概念了
如果仅仅是处理 diff 值，那就不需要跟踪整个链接了

作者: 故哈 时间: 2009-08-18 17:12

原帖由 Godbach 于 2009-8-18 17:01 发表

序列号的绝对值，十六进制数值，不是这个1什么的，这个是相对的

GET时候 seq是e2 26 72 bc ack是1e b5 32 60

返回的时 seq是1e b5 32 60 ack是e2 26 7e 97

老的seq+datalen 不等于新的ack

old tcp_datalen 3035
old tcp_totlen 3055
old tcph->ack_seq=6032b51e
old tcph->seq=bc7226e2
tcph->ack_seq=977e26e2
tcph->seq=6032b51e
new tcp_datalen 55256
new tcp_totlen 55276

分片位好像置1了

作者: Godbach 时间: 2009-08-18 17:14
我给你的程序中不处理分片报文

作者: 故哈 时间: 2009-08-18 17:15

原帖由 Godbach 于 2009-8-18 17:14 发表
我给你的程序中不处理分片报文

我这个包应该不会分片因为我写的东西很少是不是要调用skb_trim 把数据包切一下？

作者: 故哈 时间: 2009-08-18 17:16

原帖由 Godbach 于 2009-8-18 17:14 发表
我给你的程序中不处理分片报文

我现在写的就这么点东西

HTTP/1.0 304 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Connection: close

<html>
      <body>
            OK OK Ok
      </body>
</html>

作者: Godbach 时间: 2009-08-18 17:17
是你接收到的那个报文是分片的

作者: 故哈 时间: 2009-08-18 17:19

原帖由 Godbach 于 2009-8-18 17:17 发表
是你接收到的那个报文是分片的

等会我在看看他那个语法写的比较恶心

是没分片。 don`t fragment : set

作者: Godbach 时间: 2009-08-18 17:26

old tcph->ack_seq=6032b51e
old tcph->seq=bc7226e2
tcph->ack_seq=977e26e2
tcph->seq=6032b51e

这些值现转换成主机字节序，然后在打印

作者: 故哈 时间: 2009-08-18 17:30

old tcp_datalen 3035
old tcp_totlen 3055
old tcph->ack_seq=f545a42c
old tcph->seq=90ea3357
tcph->ack_seq=90ea3f32
tcph->seq=f545a42c
new tcp_datalen 55256
new tcp_totlen 55276

发包 seq 90ea3357 ack f545a42c
回包 seq f545a42c ack 90ea3f32

作者: Godbach 时间: 2009-08-18 17:33

原帖由故哈于 2009-8-18 17:30 发表

发包 seq 90ea3357 ack f545a42c
回包 seq f545a42c ack 90ea3f32

关系正确啊。

作者: Godbach 时间: 2009-08-18 17:34
0x90ea3f32 - 0x 90ea3357 = 3035

但是载荷长度明显超过MTU，你用的是以太网吗，确认没分片？

作者: 故哈 时间: 2009-08-18 17:36

原帖由 Godbach 于 2009-8-18 17:26 发表

这些值现转换成主机字节序，然后在打印

iph->tot_len 好像是这个计算的部队

作者: 故哈 时间: 2009-08-18 17:37

原帖由 Godbach 于 2009-8-18 17:34 发表
0x90ea3f32 - 0x 90ea3357 = 3035

但是载荷长度明显超过MTU，你用的是以太网吗，确认没分片？

iph->tot_len 计算的不对

作者: platinum 时间: 2009-08-18 17:39

原帖由故哈于 2009-8-18 16:49 发表

我在对端接收的包是没有分片的

我是在新包发送之前取的值

tcp_totlen = iph->tot_len - iph->ihl*4;
      tcp_datalen = tcp_totlen -  tcph->doff*4;
      printk("new tcp_datalen %d\n", tcp_datalen);
      printk("new tcp_totlen %d\n", tcp_totlen);
      ret=dev_queue_xmit(skb);
      if(ret==-1){
            printk("send error\n");
      }

大哥！
iph->tot_len 是网络字节序！

作者: 故哈 时间: 2009-08-18 17:39

原帖由 platinum 于 2009-8-18 17:39 发表

大哥！
iph->tot_len 是网络字节序！

作者: Godbach 时间: 2009-08-18 17:41
是不是这个地方忘了转换了

作者: 故哈 时间: 2009-08-18 17:41
总算是对了

iph->tot_len =216
old tcp_datalen 3035
old tcp_totlen 3055
old tcph->ack_seq=f4d0ced
old tcph->seq=577b90b2
tcph->ack_seq=577b9c8d
tcph->seq=f4d0ced
new tcp_datalen 176
new tcp_totlen 196

这个结果和抓包的可以对应上了

作者: Godbach 时间: 2009-08-18 17:52

tcp_totlen = iph->tot_len - iph->ihl*4;

应该改成tcp_totlen =ntohl( iph->tot_len) - iph->ihl*4;

作者: platinum 时间: 2009-08-18 17:53

原帖由 Godbach 于 2009-8-18 17:52 发表

应该改成tcp_totlen =ntohl( iph->tot_len) - iph->ihl*4;

tot_len 是 16bit 数据空间
所以应该用 ntohs

作者: Godbach 时间: 2009-08-18 18:02
白金兄说的很对。不过ntohl应该不会影响结果吧。

作者: platinum 时间: 2009-08-18 18:09

原帖由 Godbach 于 2009-8-18 18:02 发表
白金兄说的很对。不过ntohl应该不会影响结果吧。

当然会影响呀，它取的是一个 32bit 空间数据，然后反向
除非内存中数据是 0x02 0x01 0x00 0x00，否则 ntohl 和 ntohs 取出的结果是不同的

作者: Godbach 时间: 2009-08-18 18:10
哦，看来我的理解有偏差。我觉得他应该是先把这个值按照他自身的类型取出来，然后再去转换，这样应该是没有影响的。

作者: 故哈 时间: 2009-08-19 14:46
抓了一对实际的通信包 ack和seq如下

1 seq=50 8e e2 5c ack=87 d7 67 56
2 seq=87 d7 72 82 ack=50 8e e4 f2

第一个包的长度为662
这里看第一个包的seq和第二个包的ack 确实如god版主说的seq+length的计算方法。但是第二个包的seq并不等于第一个包的ack。

作者: Godbach 时间: 2009-08-19 14:48
这个包经过你的那个模块处理了吗？

作者: 故哈 时间: 2009-08-19 14:49

原帖由 Godbach 于 2009-8-19 14:48 发表
这个包经过你的那个模块处理了吗？

没有

作者: Godbach 时间: 2009-08-19 14:50

原帖由故哈于 2009-8-19 14:49 发表

没有

没有经过模块处理，可能就是别的原因了。昨天的那个模块验证的怎么样了？

作者: Godbach 时间: 2009-08-19 14:52
第1个ack和第2个seq也不相等啊，这两个包有关系吗？

作者: 故哈 时间: 2009-08-19 14:53

原帖由 Godbach 于 2009-8-19 14:50 发表

没有经过模块处理，可能就是别的原因了。昨天的那个模块验证的怎么样了？

把iph的totlen转换之后，第一次回包的ack和seq不再报错了，但是从第二次开始还是报错。而且浏览器依然不行

ie chrome firefox 都试了

作者: 故哈 时间: 2009-08-19 14:58

原帖由 Godbach 于 2009-8-19 14:52 发表
第1个ack和第2个seq也不相等啊，这两个包有关系吗？

对不相等。是客户端get google 和google回复的包

作者: 故哈 时间: 2009-08-19 15:07
查了一下应该是我们的回包超出了会话建立时，约定的MSS值，我看了一下我这边约定的MSS值是1430

mss是从哪取值呢？我们的tcp包长度只有196 怎么会超过MSS值呢？

作者: Godbach 时间: 2009-08-19 15:20

原帖由故哈于 2009-8-19 14:53 发表

把iph的totlen转换之后，第一次回包的ack和seq不再报错了，但是从第二次开始还是报错。而且浏览器依然不行

ie chrome firefox 都试了

这种回应包不应该每次都发的。你还得做一些机制，记录一下，这个IP发过一次回应包了，以后还需要发吗？

作者: 故哈 时间: 2009-08-19 15:20
网上说MSS=MTU-IP-TCP
我在内核打印出来end-tail=1416

会不会是对端受到包之后看到我的tailroom过大超过了 MSS 因为当时约定的是1430 所以包被当成分片的包，所以没有被浏览器识别。

谁知道怎么移动end指针

作者: 故哈 时间: 2009-08-19 15:28

原帖由 Godbach 于 2009-8-19 15:20 发表

这种回应包不应该每次都发的。你还得做一些机制，记录一下，这个IP发过一次回应包了，以后还需要发吗？

因为现在没有完成所以客户端不停的发送get包所以才导致我这边也在发回包
成功之后是不会发的

作者: Godbach 时间: 2009-08-19 15:31
标题: 回复 #82 故哈的帖子
head和end指针是没法移动的，这是申请skbuff的时候已经笃定好了。可以修改的只有data和tail。且data>=head, tail<=end

作者: 故哈 时间: 2009-08-19 15:32

原帖由 Godbach 于 2009-8-19 15:31 发表
head和end指针是没法移动的，这是申请skbuff的时候已经笃定好了。可以修改的只有data和tail。且data>=head, tail

网卡在发包的时候end和tail之间的内容应该是不发送的吧

作者: Godbach 时间: 2009-08-19 15:33
标题: 回复 #83 故哈的帖子
那就相当于对于所有的GET或POST的HTTP报文，都发送回应包了。另外，你注册的hook函数放在了PREROUTING点，也就是如果你的设备是转发设备的话，那么双向交互的GET/POST包，你都会发送回应包的。

作者: Godbach 时间: 2009-08-19 15:33
标题: 回复 #85 故哈的帖子
发送的是data到tail之间的内容

作者: 故哈 时间: 2009-08-19 15:43

原帖由 Godbach 于 2009-8-19 15:33 发表
发送的是data到tail之间的内容

那就不对了

tail-data 肯定不会大于1430的

作者: Godbach 时间: 2009-08-19 15:46

我在内核打印出来end-tail=1416

你得确定一下，你打印出的这个包是否是带有比较大数据的包

作者: 故哈 时间: 2009-08-19 15:49

原帖由 Godbach 于 2009-8-19 15:46 发表

你得确定一下，你打印出的这个包是否是带有比较大数据的包

old tcp_datalen 445
old tcp_totlen 465
old tcph->ack_seq=20577665
old tcph->seq=9629a5ac
tcph->ack_seq=9629a769
tcph->seq=20577665
new tcp_datalen 176
new tcp_totlen 196
tail-data=230
end-tail=1416

应该不会这个包是get google根目录的包肯定不会很大

[ 本帖最后由故哈于 2009-8-19 15:51 编辑 ]

作者: Godbach 时间: 2009-08-19 15:52

new tcp_datalen 176
new tcp_totlen 196
tail-data=230

按你打印的顺序，这个指没有问题吧，符合包长的要求，196+20+14 = 230

作者: 故哈 时间: 2009-08-19 16:03

原帖由 Godbach 于 2009-8-19 15:52 发表

按你打印的顺序，这个指没有问题吧，符合包长的要求，196+20+14 = 230

看起来确实没有问题肯郁闷。现在的问题应该是我的包发过去之后对端是按照一个分片来接受的，应该是根本就没到应用层就被丢弃了

作者: Godbach 时间: 2009-08-19 16:08

原帖由故哈于 2009-8-19 16:03 发表

看起来确实没有问题肯郁闷。现在的问题应该是我的包发过去之后对端是按照一个分片来接受的，应该是根本就没到应用层就被丢弃了

那你在对端抓包，看一下是否分片位被置位.

作者: Godbach 时间: 2009-08-19 16:10
不过程序中对于初始分片包都直接放过了啊，不处理分片包的，所以构造的回应包，不大可能存在分片啊

作者: 故哈 时间: 2009-08-19 16:11

原帖由 Godbach 于 2009-8-19 16:08 发表

那你在对端抓包，看一下是否分片位被置位.

确实没有被置位。现在情况应该是客户端误认为我们发过去的包是很多分片中的其中一个

作者: Godbach 时间: 2009-08-19 16:13

原帖由故哈于 2009-8-19 16:11 发表

确实没有被置位。现在情况应该是客户端误认为我们发过去的包是很多分片中的其中一个

客户端为什么会误认，好好的一个包，符合协议的要求，咋就成了不正常的包呢？

作者: 故哈 时间: 2009-08-19 16:13

原帖由 Godbach 于 2009-8-19 16:10 发表
不过程序中对于初始分片包都直接放过了啊，不处理分片包的，所以构造的回应包，不大可能存在分片啊

而且ip头中是拒绝分片的如果我的包大于MTU会被丢弃然后直接返回给用户态一个错误

作者: Godbach 时间: 2009-08-19 16:16

原帖由故哈于 2009-8-19 16:13 发表

而且ip头中是拒绝分片的如果我的包大于MTU会被丢弃然后直接返回给用户态一个错误

把你调整后的代码及用于发回应包的html文件发给我，我帮你测试一下

作者: loveyaya0716 时间: 2009-08-19 16:33

也在关注这个~~~~~~

作者: Godbach 时间: 2009-08-19 16:59
你构造的那个数据本身不符合格式要求。抓包看不出来吗

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)