|
|
|||||||
| OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below. |
 |
|
|
Thread Tools | Display Modes |
10th March 2011
|
|||||
|
|||||
Wifi with atheros chipset AR9280
Hi,
I am trying to get a wifi access point running on my SOHO-server, OpenBSD 4.8, Netfinity 3000. The server acts as a gateway and firewall to a dsl-router. IP is 192.1687.0.20. Connection to the internet passes through OpenVPN (tun0). The intranet is configured with subnet 192.168.0.0. So nothing really strange there (I hope). Card TP-Link TL-WN851N is recognized on system bootup: Quote:
Quote:
# ifconfig athn0: Quote:
My /etc/dhcpd.conf: Quote:
But now problems arise: 1. I cannot ping the wifi card. And it doesn't matter if dhcpd is running or not. Quote:
# dhcpd athn0 it tries to give IP-Adresses to every network device on the net. Thus my openvpn connection breaks down and routing dies. Where is the missing link? Any help appreciated. Greets, Sebastian 
|
|
10th March 2011
|
|||
|
|||
|
Hi,
here are some logs that might help. 1. When I start dhcpd I get # tail -f /var/log/messages Quote:
# dhcpd athn0 2. When I try to connect my mobile with the wifi card and attempt to get into the internet: # tcpdump -i athn0 Quote:
Greets, Sebastian
|
|
10th March 2011
|
|||
|
|||
|
Quote:
 But if you have both the external interface and internal interface on 192.168.0.0/24 then this is not correct for the BSDs. The external interface needs to be on another subnet than the internal one. What is the output of Code:
# ifconfig -A
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
10th March 2011
|
|||
|
|||
Yes that's right:
the internal device is subnet 192.168.0.0, the external device is subnet 192.168.178.0 Here are the complete network interfaces (sorry for the bad format): # ifconfig -A Code:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
priority: 0
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:06:29:12:fd:a4
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::206:29ff:fe12:fda4%fxp0 prefixlen 64 scopeid 0x1
inet 192.168.178.21 netmask 0xffffff00 broadcast 192.168.178.255
athn0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 74:ea:3a:f3:05:39
priority: 4
groups: wlan
media: IEEE802.11 autoselect mode 11g hostap
status: active
ieee80211: nwid FreiKINO chan 11 bssid 74:ea:3a:f3:05:39 wpapsk xxxxxxxx wpaprotos
wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip
inet6 fe80::76ea:3aff:fef3:539%athn0 prefixlen 64 scopeid 0x2
inet 192.168.0.50 netmask 0xffffff00 broadcast 192.168.0.255
ne3: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:20:18:3c:12:55
priority: 0
media: Ethernet autoselect (10baseT)
inet 192.168.0.20 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::220:18ff:fe3c:1255%ne3 prefixlen 64 scopeid 0x3
enc0: flags=0<>
priority: 0
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
priority: 0
groups: pflog
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
priority: 0
groups: tun
status: active
inet 10.0.xx.xx --> 10.0.xx.xx netmask 0xffffffff
)Greets, Sebastian Last edited by J65nko; 10th March 2011 at 09:20 PM. Reason: Changed from quote to code tags
|
|
10th March 2011
|
|||
|
|||
|
The athn(4) driver has seen a lot of changes since 4.7/4.8, especially in the area of hostap support.
You should try a 4.9-current snapshot or wait for the 4.9 release.
|
|
10th March 2011
|
|||
|
|||
|
The ne3 and athn0 still share the same subnet.
Put the athn0 on a 10.0.0.0/24 subnet, adjust the dhcpd.conf accordingly and retry
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
11th March 2011
|
|||
|
|||
|
O.K., I changed the IP of athn0 interface to 10.0.0.1 . Now I can ping the interface, so there is some progress.
But the rest stays the same: no connection to the intranet or the internet. But maybe tcpdump gives a hint: the IP from the vpn interface shows up in the logs: # tcpdump -i athn0 Code:
tcpdump: listening on athn0, link-type EN10MB 17:22:36.121158 arp who-has soho.server tell 10.0.0.10 17:22:36.121240 10.0.xx.xx > 10.0.0.10: icmp: echo request 17:22:37.132500 arp who-has soho.server tell 10.0.0.10 17:22:38.131048 arp who-has soho.server tell 10.0.0.10 17:22:39.146774 arp who-has soho.server tell 10.0.0.10 17:22:40.163006 arp who-has soho.server tell 10.0.0.10 17:22:41.179724 arp who-has soho.server tell 10.0.0.10 17:22:44.164080 arp who-has soho.server tell 10.0.0.10 17:22:45.180205 arp who-has soho.server tell 10.0.0.10 17:22:46.196245 arp who-has soho.server tell 10.0.0.10 17:22:49.184902 arp who-has soho.server tell 10.0.0.10 @ BSDfan666 I am running 4.8-release. Would an upgrade with the lastest snapshot be sufficiant? Never did this before. Had a look at FAQ 5 already. Should work like an upgrade to the next release without upgrade hints from one release to the other, right? And where do I find info about changes from 4.8-release to 4.9-snapshot? Greets, Sebastian
|
|
11th March 2011
|
|||
|
|||
|
What is the output of
Code:
$ sysctl -a | grep ip.forward net.inet.ip.forwarding=0 In my case it is off, which is OK for a workstation. For a router you need to turn this on, by uncommenting the following line from /etc/sysctl.conf and reboot: Code:
#net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of IPv4 packets
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
11th March 2011
|
|||
|
|||
|
net.inet.ip.forwarding=1, always was.
Turning off openvpn is an option but here it's 11 pm now so I will try tomorrow  .Till then, Sebastian
|
|
12th March 2011
|
|||
|
|||
|
I deactivated openvpn but no progress. Smae results (none) and instead of IP from tun0 interface it just says "noname":
Code:
06:21:19.582009 arp who-has serv.kesslar.de tell 10.0.0.10 06:21:19.582089 noname > 10.0.0.10: icmp: echo request 06:21:20.591469 arp who-has serv.kesslar.de tell 10.0.0.10 I have no more clues so far. For me it seems as a driver problem indeed. Maybe I should try upgrading to newest snapshot. Greets, Sebastian
|
|
12th March 2011
|
|||
|
|||
|
Some tcpdump tips:
If you add the -e option like in tcpdump -eni re0 then the MAC addresses are shown: Code:
10:00:07.092146 00:19:db:47:b0:4c ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.222.11 tell 192.168.222.20 10:00:07.092359 00:08:c7:05:ca:0b 00:19:db:47:b0:4c 0806 60: arp reply 192.168.222.11 is-at 00:08:c7:05:ca:0b By using the -n option you will prevent tcpdump from doing reverse DNS lookups (IP nr -> symbolic name), that will pollute tpcdump's output. You can increase verbosity by using -vv and by setting the snap length with -s 1500 you can see the complete protocol info. For example this from a (repeated, forgot the -s 1500 the first time) dhclient request: Code:
10:25:34.948816 00:20:ed:25:f1:ac ff:ff:ff:ff:ff:ff 0800 342: 192.168.222.249.68 > 255.255.255.255.67: [udp sum ok] xid:0x85375eaa vend-rfc1048 RQ:192.168.222.249 DHCP:REQUEST PR:SM+BR+TZ+DG+DN+NS+HN [tos 0x10] (ttl 16, id 0, len 328) 10:25:34.988618 00:08:c7:05:ca:0b 00:20:ed:25:f1:ac 0800 342: 192.168.222.10.67 > 192.168.222.249.68: [udp sum ok] xid:0x85375eaa Y:192.168.222.249 S:192.168.222.10 vend-rfc1048 DHCP:ACK SID:192.168.222.10 LT:36000 SM:255.255.255.0 DG:192.168.222.10 DN:"utp.xnet" NS:192.168.222.10 [tos 0x10] (ttl 16, id 0, len 328) 10:25:34.995014 00:20:ed:25:f1:ac ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.222.249 tell 192.168.222.249 You can check the default route with netstat -rn -f inet After a mobile client got an IP address through DHCP, it should be able to ping the gateway, and the internal IP address of your server.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
13th March 2011
|
|||
|
|||
|
This is the output of
# tcpdump -eni athn0 Code:
14:34:20.800676 2c:d2:e7:5d:ee:bd ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > 255.255.255.255.67: xid:0x77737a38 [|bootp] 14:34:20.802631 74:ea:3a:f3:05:39 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 14:34:20.803306 74:ea:3a:f3:05:39 2c:d2:e7:5d:ee:bd 0800 344: 10.0.0.1.67 > 10.0.0.10.68: xid:0x77737a38 Y:10.0.0.10 S:10.0.0.1 [|bootp] [tos 0x10] 14:34:20.837111 2c:d2:e7:5d:ee:bd ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > 255.255.255.255.67: xid:0x77737a38 [|bootp] 14:34:20.850466 74:ea:3a:f3:05:39 2c:d2:e7:5d:ee:bd 0800 344: 10.0.0.1.67 > 10.0.0.10.68: xid:0x77737a38 Y:10.0.0.10 S:10.0.0.1 [|bootp] [tos 0x10] 14:34:20.858804 2c:d2:e7:5d:ee:bd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 0.0.0.0 14:34:22.345803 2c:d2:e7:5d:ee:bd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.1 tell 10.0.0.10 14:34:22.345883 74:ea:3a:f3:05:39 2c:d2:e7:5d:ee:bd 0800 62: 10.0.x.x > 10.0.0.10: icmp: echo request 14:34:22.345947 74:ea:3a:f3:05:39 2c:d2:e7:5d:ee:bd 0806 42: arp reply 10.0.0.1 is-at 74:ea:3a:f3:05:39 14:34:22.350676 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 62: 10.0.0.10 > 10.0.x.x: icmp: echo reply 14:34:23.348435 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 39871+ A? www.google.de. (31) 14:34:23.350165 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 8524+ A? www.google.de. (31) 14:34:27.373638 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 8524+ A? www.google.de. (31) 14:34:31.395775 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 39871+ A? www.google.de. (31) 14:34:31.396804 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 8524+ A? www.google.de. (31) 14:34:35.410839 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 57777+ AAAA? www.google.de. (31) 14:34:36.424462 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 39871+ A? www.google.de. (31) 14:34:36.425046 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 57777+ AAAA? www.google.de. (31) 14:34:40.444990 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 57777+ AAAA? www.google.de. (31) 14:34:44.462768 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 39871+ A? www.google.de. (31) 14:34:44.463526 2c:d2:e7:5d:ee:bd 74:ea:3a:f3:05:39 0800 73: 10.0.0.10.42911 > 195.x.x.x.53: 57777+ AAAA? www.google.de. (31) 195.x.x.x are dns server. Quote:
This is the output of # netstat -rn -f inet Code:
Internet: Destination Gateway Flags Refs Use Mtu Prio Iface 0/1 10.0.x.x UGS 0 2562 - 8 tun0 default 192.168.178.1 UGS 0 1067455 - 8 fxp0 10/8 link#2 UC 1 0 - 4 athn0 10.0.0.10 link#2 UHLc 1 1 - 4 athn0 10.0.x.x/32 10.0.x.x UGS 0 0 - 8 tun0 10.0.x.x 10.0.x.x UH 3 0 - 4 tun0 82.x.x.x/32 192.168.178.1 UGS 1 5447 - 8 fxp0 127/8 127.0.0.1 UGRS 0 0 33200 8 lo0 127.0.0.1 127.0.0.1 UH 3 112 33200 4 lo0 128/1 10.0.x.x UGS 0 2049 - 8 tun0 192.168.0/24 link#3 UC 1 0 - 4 ne3 192.168.0.1 1c:6f:65:80:49:a6 UHLc 3 918289 - 4 ne3 192.168.178/24 link#1 UC 1 0 - 4 fxp0 192.168.178.1 00:1a:4f:c1:70:51 UHLc 2 15 - 4 fxp0 192.168.178.21 127.0.0.1 UGHS 0 0 33200 8 lo0 224/4 127.0.0.1 URS 0 0 33200 8 lo0 82.x.x.x is the IP assigned by openvpn server. 192.168.178.1 is the IP of the dsl box. 192.178.178.21 is the IP of the external interface (via dhcp from dsl box). Greets, Sebastian Last edited by sws; 13th March 2011 at 06:33 AM.
|
|
13th March 2011
|
|||
|
|||
|
So the client gets an IP, can ping the athn0 IP, but does not receive an answer from the nameserver at 195.x.x.x.53.
Try a ping from the wireless client to the 192.168.0.20 (internal net) IP. Does a tcdpump on that interface (ne3) show the ICMP request? If it doesn't show an ICMP reply, then pf could be blocking it. With a block log all policy you can see blocked packets with running tcpdump on the pflog0 interface (tcpdump -eni pflog0) Something similar you can do for the DNS lookup. Follow the transport of the DNS request, by running tcpdump on every interface the packet should arrive on. BTW If you keep insisting on using OpenVPN, you (and including me) will not be sure, whether we are trying to debug a network/pf issue or an OpenVPN problem. For OpenVPN see the OpenVPN revisited thread.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
14th March 2011
|
|||
|
|||
|
So we have improvements here: I managed to connect to the intranet and the internet with my mobile!
First I took advice to add block log all and checked what was blocking all connections to athn0. I then added a pass in on athn0 in my pf.conf and had instant connection to my intranet. Second I disabled my external openvpn connection. Like a miracle I had access to the internet as well. @J65nko Thanks for your very helpful hints so far. But... How can I connect to the internet via athn0 AND OpenVPN? I have configured nat from athn0 to the external interface in pf.conf. Is there anything else that is missing? And there is another problem: my mobile opens on connection with athn0 every website I want. But the following link or any next website I want to open doesn't really work. Either it doesn't open at all or I have to klick a dozen times or more until changes take effect. I don't have another wifi client at hand at the moment. So I cannot check if it is serverside or just my mobile that does not work properly. Greets, Sebastian Last edited by sws; 14th March 2011 at 01:43 PM. Reason: typo removed
|
|
15th March 2011
|
|||
|
|||
|
Which type of mobile client you want to connect to the Net through OpenVPN? An OpenBSD box?
Do you want to use a VPN service provider like in http://www.daemonforums.org/showthread.php?t=5653 ? Or do you only want to encrypt the wireless traffic from the mobile client to the firewall/server? Don't make us guess, please be specific
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
15th March 2011
|
|||
|
|||
|
1. Description of my intranet:
My SOHO net consisits of a OpenBSD server that serves as a gateway between the intranet and the internet. The internal interface is a ne3 and connects to a switch where all hosts connect from the other side. Internet connections of the hosts are managed by appropriate nat rules in pf. This is internal_interface_1 in pf rules. The wifi interface is also configured to connect from within the intranet thus its IP is in the private address space with just another subnet. Again nat rules in pf for connections to the internet are established. On the other side is a ethernet interface fxp0 which connects to a dsl box and from there to the internet. The IP for fxp0 is assigned via dhcp from the dsl box within a different subnet than ne3. This is internal_interface_2 in pf rules. OpenVPN is realized through tun0 interface. This is the "external" interface in pf rules. 2. Reason to use OpenVPN: Germans are known to be a bit paranoid about their private data. Despite this fact the german government plans to collect every data from everyone that uses the internet (and telecommunications as well) as a means of fighting terror, so they say. So the ISPs will be obliged to store every data of who was where and when on the internet. This is called "Vorratsdatenspeicherung", kind of data preservation. They have done this before but were stopped by the german Constitutionanl Court. But they will try again soon. That's why all connections/services from my intranet to the internet are established via OpenVPN to a anonymisation service and are so anonymized and can not be backtraced. And this includes every host on my intranet be it a PC, netbook or cell phone. I don't have anything to conceal nor am I member of Al Kaida . But these are MY data and belong to me exclusively. Nobody has to have special interest in them. Hope this does not sound too weird  3. Which mobile client: At the moment I try to connect to the wifi interface with my cell phone, Nokia E52. But it's supposed to work with every device capable of wifi funtionality. Greets, Sebastian Last edited by sws; 15th March 2011 at 01:55 PM. Reason: typo removed
|
|
15th March 2011
|
|||
|
|||
|
Quote:
Most people would call the fxp0 interface external, because it faces the public Internet. All interfaces connected to the the internal LAN, are called internal interfaces. In your case ne3 and athn0. RE: OpenVPN I only wanted to know whether you were using an OpenVPN service provider or running an OpenVPN server on your firewall.server. If OpenVPN works for the clients on the wired LAN (those connected to the ne3 NIC), then I don't understand why the OpenVPN clients on the wireless LAN (athn0 interface) have problems connecting. One possible issue could that both wireless and OpenVPN use the 10/? net From your previously posted info: Quote:
Code:
$ grep tun0 netstat.sws
0/1 10.0.x.x UGS 0 2562 - 8 tun0
10.0.x.x/32 10.0.x.x UGS 0 0 - 8 tun0
10.0.x.x 10.0.x.x UH 3 0 - 4 tun0
128/1 10.0.x.x UGS 0 2049 - 8 tun0
One simple way would be to use something like the10.88.0.0/16 network for athn0.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|
|
17th March 2011
|
|||
|
|||
|
Quote:
Quote:
Thanks again for your help! Quote:
Last thing on my mind: I connect to the wifi interface with my cell phone and the first request works. Every next request, be it a link or a new page, does not. I will search the forum, google a bit and maybe open another thread .So long, many thanks, Sebastian
|
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Bug in libdrm with intel 865G chipset. | Svejk | OpenBSD General | 5 | 14th November 2010 11:05 PM |
| Atheros Wifi NetBSD on a Sparc64 | granowski | NetBSD General | 1 | 27th September 2010 11:35 AM |
| Trouble with atheros AR9280 | slack_eater | OpenBSD General | 0 | 31st August 2010 09:41 PM |
| Guide: Atheros ar5007 wifi cards in freebsd7 | Dazhelpwiz | FreeBSD Installation and Upgrading | 3 | 16th June 2008 02:23 AM |
| Losing connection with Atheros wifi | noonereallycares | FreeBSD General | 2 | 11th June 2008 03:57 AM |
Linear Mode
