Opened 16 years ago
Closed 16 years ago
#59 closed defect (fixed)
test of nodehuub: no routing no nameservice for users
Reported by: | huub | Owned by: | nobody |
---|---|---|---|
Priority: | major | Milestone: | |
Keywords: | Cc: | ||
Resource needed to fix: |
Description ¶
Test on
FreeBSD CNodeHuub.wLeiden.NET 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Tue Jul 14 15:58:12 CEST 2009 root@fab:/usr/obj/nanobsd.wleiden/usr/src/sys/kernel.wleiden i386
I made a wireless connection with the omni of NodeHuub with my EEEPC, just like a 'normal user' would. I get an ip-address and a nameserver:
wlan0 Link encap:Ethernet HWaddr 00:22:43:58:11:8a
inet addr:172.17.16.45 Bcast:172.17.16.63 Mask:255.255.255.192
and
cat /etc/resolv.conf:
# Generated by NetworkManager
domain wLeiden.NET
search wLeiden.NET
nameserver 172.17.16.1
There is a good connection with the node:
--- 172.17.16.1 ping statistics ---
32 packets transmitted, 32 received, 0% packet loss, time 31018ms
rtt min/avg/max/mdev = 3.342/8.098/37.396/7.536 ms
Routing table is OK:
root@cc:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.17.16.0 0.0.0.0 255.255.255.192 U 0 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
0.0.0.0 172.17.16.1 0.0.0.0 UG 0 0 0 wlan0
However, the nameserver doesnot work:
root@cc:~# ping huub.wleiden.net
ping: unknown host huub.wleiden.net
and
root@cc:~# dig huub.wleiden.net
; <<>> DiG 9.5.1-P2 <<>> huub.wleiden.net
;; global options: printcmd
;; connection timed out; no servers could be reached
Also routing doesnot work.
For instance a ping to 172.17.48.1 (nodethomas):
root@cc:~# ping 172.17.48.1
PING 172.17.48.1 (172.17.48.1) 56(84) bytes of data.
C
--- 172.17.48.1 ping statistics ---
34 packets transmitted, 0 received, 100% packet loss, time 33022ms
Whereas NodeHuub has a good connection with thomas and also names are resolved when I log in at the node:
CNodeHuub# ping thomas
PING thomas.wleiden.net (172.17.48.1): 56 data bytes
64 bytes from 172.17.48.1: icmp_seq=0 ttl=62 time=8.640 ms
64 bytes from 172.17.48.1: icmp_seq=1 ttl=62 time=9.011 ms
64 bytes from 172.17.48.1: icmp_seq=2 ttl=62 time=8.878 ms
.....
Change History (6)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Re the routing problem: I checkt whether there is a 'gateway=yes' statement in /etc/rc.conf.
There is, so source of problem must be 'elsewhere'.
Node is now running latest version r7085.
follow-up: 4 comment:3 by , 16 years ago
I checked the firewall rules introduced for the captive portal feature:
CNodeHuub# ipfw list
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
10000 allow tcp from any to 127.0.0.1 dst-port 80
10001 allow tcp from any to me dst-port 80
10100 fwd 172.16.1.38,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.65,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.3.21,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 127.0.0.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.31.255.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.0.14,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
65000 allow ip from any to any
65535 allow ip from any to any
follow-up: 5 comment:4 by , 16 years ago
Replying to huub:
I checked the firewall rules introduced for the captive portal feature:
CNodeHuub# ipfw list
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
10000 allow tcp from any to 127.0.0.1 dst-port 80
10001 allow tcp from any to me dst-port 80
10100 fwd 172.16.1.38,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.65,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.3.21,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 127.0.0.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.31.255.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.0.14,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
65000 allow ip from any to any
65535 allow ip from any to any
If I flush the rules routing works OK:
CNodeHuub# ipfw -q -f flush
CNodeHuub# ipfw list
65535 allow ip from any to any
and now from a local pc I can ping NodeVosko1:
bash-3.2$ ping 172.174.1.1
PING 172.174.1.1 (172.174.1.1) 56(84) bytes of data.
64 bytes from 172.174.1.1: icmp_seq=1 ttl=107 time=20.8 ms
etc.
So the packet filtering is clearly causing the problem.
comment:5 by , 16 years ago
Replying to huub:
Replying to huub:
I checked the firewall rules introduced for the captive portal feature:
CNodeHuub# ipfw list
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
10000 allow tcp from any to 127.0.0.1 dst-port 80
10001 allow tcp from any to me dst-port 80
10100 fwd 172.16.1.38,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.65,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.3.21,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 127.0.0.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.31.255.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.16.0.14,8081 tcp from any to not 172.16.0.0/12 dst-port 80
10100 fwd 172.17.16.1,8081 tcp from any to not 172.16.0.0/12 dst-port 80
65000 allow ip from any to any
65535 allow ip from any to any
If I flush the rules routing works OK:
CNodeHuub# ipfw -q -f flush
CNodeHuub# ipfw list
65535 allow ip from any to any
and now from a local pc I can ping NodeVosko1:
bash-3.2$ ping 172.174.1.1
PING 172.174.1.1 (172.174.1.1) 56(84) bytes of data.
64 bytes from 172.174.1.1: icmp_seq=1 ttl=107 time=20.8 ms
etc.
So the packet filtering is clearly causing the problem.
Not really: vosko1 has ip 172.17.174.1 which works also with firewall rules in place
So this is really a red herring.
Only real issue seems to be nameserver (and captive portal).
comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
routing works in present version
Named seems to have a really poor startup script, plus some variables are not set correctly, causing the resolving to fail. Will give ping when fixed