Opened 15 years ago

Closed 15 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 rick, 15 years ago

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

comment:2 by huub, 15 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.

comment:3 by huub, 15 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

in reply to:  3 ; comment:4 by huub, 15 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.

in reply to:  4 comment:5 by huub, 15 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 huub, 15 years ago

Resolution: fixed
Status: newclosed

routing works in present version

Note: See TracTickets for help on using tickets.