From owner-freebsd-net@FreeBSD.ORG Tue Feb 26 15:24:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678D8106567D for ; Tue, 26 Feb 2008 15:24:47 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 15F6213C4EF for ; Tue, 26 Feb 2008 15:24:41 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 24837 invoked from network); 26 Feb 2008 15:01:52 -0000 Received: from unknown (HELO ?10.0.0.199?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 26 Feb 2008 15:01:52 -0000 Message-ID: <47C428EC.3090909@acm.poly.edu> Date: Tue, 26 Feb 2008 09:57:48 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: if_gif/if_bridge problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 15:24:47 -0000 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 metric 0 mtu 1500 options=8 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 ) status: active bridge0: flags=8843 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 gif6: flags=8051 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 metric 0 mtu 1500 ether 00:18:e7:32:b1:9d media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) 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 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 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 member: ath0 flags=143 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