if_gif/if_bridge problem

Boris Kochergin spawk at acm.poly.edu
Tue Feb 26 15:24:47 UTC 2008


Hi, list. As per the comment in the if_bridge(4) man page, I'm trying to 
tunnel Ethernet through IP for the purpose of having multiple 802.11 
"access points" all feed into a "concentrator," which will perform NAT. 
I have the concentrator with the following setup (gif0 through gif1 are 
IPv4-over-IPv6 tunnels and I don't believe them to be relevant to the 
problem, but I'm open to being wrong):

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:04:ac:58:a4:c3
        inet6 fe80::204:acff:fe58:a4c3%fxp0 prefixlen 64 scopeid 0x1
        inet 128.238.9.202 netmask 0xffffff00 broadcast 128.238.9.255
        inet6 2001:4830:2401::1 prefixlen 64
        inet6 3ffe:401d:ff:186a::1 prefixlen 64
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500
        ether 3e:7f:e8:ef:f6:a4
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: gif6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
gif6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 128.238.9.202 --> 128.238.35.81
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffff00
        inet6 fe80::204:acff:fe58:a4c3%gif6 prefixlen 64 scopeid 0xa

The concentrator performs NAT with pf. The only line in /etc/pf.conf is 
"nat on fxp0 from bridge0:network to any -> (fxp0) static-port". It also 
runs dhcpd, whose configuration file is:

ddns-update-style none;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.100 192.168.0.200;
  option routers 192.168.0.1;
  option domain-name "poly.edu";
  option domain-name-servers 128.238.9.202, 4.2.2.1;
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.0.255;
  default-lease-time 3600;
  max-lease-time 3600;
}

I have an access point with the following setup:

ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 
0 mtu 1500
        ether 00:18:e7:32:b1:9d
        media: IEEE 802.11 Wireless Ethernet autoselect <hostap> 
(autoselect <hostap>)
        status: associated
        ssid acm channel 1 (2412 Mhz 11g) bssid 00:18:e7:32:b1:9d
        authmode OPEN privacy OFF deftxkey 1 wepkey 1:104-bit txpower 31.5
        scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7
        roam:rate11g 5 protmode CTS burst dtimperiod 1
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 128.238.35.81 --> 128.238.9.202
        inet 10.0.0.2 --> 10.0.0.1 netmask 0xffffff00
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500
        ether 4a:0a:2d:b1:17:ae
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: gif0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        member: ath0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>

Clients are able to associate with the access point, and are able to 
acquire an IP via DHCP:

# dhclient ral0
DHCPREQUEST on ral0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.199 -- renewal in 1800 seconds.

However, nothing after this seems to work. I've started debugging by 
attempting to ping 192.168.0.1 (the concentrator) from the client, and 
this is what happens:

On the client:

# tcpdump -n -i ral0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ral0, link-type EN10MB (Ethernet), capture size 96 bytes
10:41:58.628796 arp who-has 192.168.0.1 tell 192.168.0.199
10:41:59.630223 arp who-has 192.168.0.1 tell 192.168.0.199
10:42:00.631064 arp who-has 192.168.0.1 tell 192.168.0.199

On the access point:

# tcpdump -n -i bridge0
tcpdump: WARNING: bridge0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge0, link-type EN10MB (Ethernet), capture size 68 bytes
09:52:23.065926 arp who-has 192.168.0.1 tell 192.168.0.199
09:52:24.067110 arp who-has 192.168.0.1 tell 192.168.0.199
09:52:25.067883 arp who-has 192.168.0.1 tell 192.168.0.199

On the concentrator:

# tcpdump -n -i bridge0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes
09:51:32.483177 arp who-has 192.168.0.1 tell 192.168.0.199
09:51:33.484216 arp who-has 192.168.0.1 tell 192.168.0.199
09:51:34.484948 arp who-has 192.168.0.1 tell 192.168.0.199

So, the tunnels and bridges appear to be sending the traffic around 
properly, but the concentrator machine isn't replying to ARP requests 
for its bridge0 interface's IP. This is where I'm stuck. Any help is 
appreciated.

-Boris


More information about the freebsd-net mailing list