[bridge]加入到bridge中的interface能直接与ip层通信吗？

new_learner

原帖由 Godbach 于 2009-3-21 09:36 发表

如果你是从lan侧的pc发到wan侧pc的ping包，按理说会通过ARP得到wan侧pc的MAC啊，这样桥为什么没有把这个ping包转发呢，反而要走IP层。

我抓包的时候发现，当lan侧PC发起ping包到wan侧pc时，

1. 
   
2. ping 175.18.214.8
   

复制代码

lan侧会先发arp包，但这个arp包不是"who is 175.18.214.8", 而是"who is 192.168.1.1"

192.168.1.1是lan侧pc通过dhcp获取的网关，也就是router中的br0的ip。
所以这个ping包的目的mac就是router本身的mac，而不是wan侧pc的mac。

Godbach

原帖由 new_learner 于 2009-3-21 10:39 发表

我抓包的时候发现，当lan侧PC发起ping包到wan侧pc时，

ping 175.18.214.8

lan侧会先发arp包，但这个arp包不是"who is 175.18.214.8", 而是"who is 192.168.1.1"

192.168.1.1是lan侧pc通过dhcp获取的 ...

我觉得桥一般不会像你这么用法。把一个内网和外网接口加到一个桥里。

new_learner

原帖由 Godbach 于 2009-3-21 10:41 发表


我觉得桥一般不会像你这么用法。把一个内网和外网接口加到一个桥里。

是的，一般的确不是这样用的。
我这样用，只是处于试验和学习的目的。
我现在的疑问是，为什么这样用了以后，通过ip层找到了interface以后，packet却没有往外发？
希望能从源码级别上来了解这个问题。

gejiajie_01

加入到桥里面的interface是二层直接转发的，不可能用到第三层的啊

kevert

数据报目的MAC是网关，那么肯定就会被br0收到，从而交给上层处理，如果数据报到了三层的话，那么找路由的时候肯定可以找到路由，至少会找到默认路由，可以考虑在dev_queue_xmit 处加上打印信息，看是否走到此处了。我觉得看你的组网图来说应该是通的，你在WAN侧抓包看是否网关会向PC所ping的WAN侧主机发送ARP请求。看是否网关学习到了对方的ARP。

Godbach

同意LZ的测试方式。先看看学到ARP没有. 至于在dev_queue_xmit上加调试信息，可能有些麻烦

new_learner

原帖由 kevert 于 2009-3-21 22:20 发表
数据报目的MAC是网关，那么肯定就会被br0收到，从而交给上层处理，如果数据报到了三层的话，那么找路由的时候肯定可以找到路由，至少会找到默认路由，可以考虑在dev_queue_xmit 处加上打印信息，看是否走到此处了。我觉得看你的组网图来说应该是通的，你在WAN侧抓包看是否网关会向PC所ping的WAN侧主机发送ARP请求。看是否网关学习到了对方的ARP。

从wan侧抓包的情况来看，网关已经学习到了wan侧主机的mac地址了，但无法在wan侧主机上抓到ping包。在ip_finish_output2()中加入打印信息，在ip层网关也的确把ping发出来了。

所以我一直怀疑是不是网关wan侧interface eth0加入了bridge，所以导致ip层在向下层发包的时候没有传入到eth0中。
看来是有必要在dev_queue_xmit ()加入打印信息，仔细调试一下。

new_learner

原帖由 Godbach 于 2009-3-21 23:25 发表
同意LZ的测试方式。先看看学到ARP没有. 至于在dev_queue_xmit上加调试信息，可能有些麻烦

arp已经学到了。
斑竹有什么建议吗？

kevert

之所以ICMP报文没有发送出去应该是跟ARP有关系的。
ip neigh ls 看看结果。
基本流程是这样子的：
ping报文到了网关，MAC地址是网关自己，因此br0收到这个报文，从而交给上层也就是IP层处理，IP层处理之后，找路由找到eth0，创建路由缓存，但是此时并没有对应WAN侧设备的ARP信息，因此创建一个邻居节点，将这个邻居节点和这条路由缓存关联起来，但是没有获取到ARP，所以，发送ARP请求出去，也就是通过eth0发送ARP请求出去，这个请求的响应被网关eth0收到，本来这个请求的skb->dev指向的是eth0的，结果因为eth0又被加到桥里面去了，因此，使得这个请求被桥处理之后skb->dev变成了br0了，然后送给上层处理，此时，因为ARP请求是从eth0发出去的，但是结果回应却在ARP层看来是从br0收到的，而实际上内核创建一个邻居节点的时候需要两个条件: dev 以及 MAC地址，因此这样skb->dev变成了br0，从而导致匹配不上，从而导致ARP从eth0发送出去之后没有dev匹配不上，而导致没有响应，认为目的不可达，也就是eth0并没有学到WAN侧设备的MAC地址，而是认为可以通过br0到达，所以，你最终看到结果是学习到了ARP,但是是br0学习到的，而不是eth0学习到的，使用 ip neigh ls 就可以很清楚的知道， arp -a 显示出来内容不够细致。

说了这么多，自己都觉得有点罗嗦了，不知道解决了你的疑问么。

[ 本帖最后由 kevert 于 2009-3-23 22:17 编辑 ]

Godbach

继续关注该问题