|
OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
Ok. I got the Apple notebook to work again. Since the problem isn't depending on whether I produce network traffic or not, I decided to just connect and let the computer doing nothing, which results in the following traffic on rum0:
Code:
14:27:32.413035 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 003d 756f 75ce 1cff f0bc b201 7181 9ed8 d685 b885 2703 446b b0d9 803b 24a1 25df 3b00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 14:27:32.417492 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 0092 b451 92ae 8c29 5099 eeae 9461 d920 f1f2 d57d d772 438f 776a 9770 7111 7c84 b200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00f0 f57b 42d4 9854 7f49 321c bfa2 8f46 b000 1630 1401 14:27:32.417597 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 013d 756f 75ce 1cff f0bc b201 7181 9ed8 d685 b885 2703 446b b0d9 803b 24a1 25df 3b00 0000 0000 0000 0000 0000 0000 0000 00a5 0000 0000 0000 0000 0000 0000 0000 001d a190 22da 69ff a25b 0593 7723 ac61 ba00 50cd 4164 14:27:32.421482 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 0192 b451 92ae 8c29 5099 eeae 9461 d920 f1f2 d57d d772 438f 776a 9770 7111 7c84 b200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 006a 0338 d494 eaa6 8d62 de89 102e e48a 6100 00 14:27:32.422297 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:32.821314 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:33.220560 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:33.623806 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:34.032548 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:34.032668 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.254 tell 192.168.2.101 14:27:34.032737 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:34.032748 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0806 42: arp reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy 14:27:34.441219 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:34.822009 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:35.221007 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:36.041028 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:02 0800 46: 192.168.2.101 > 224.0.0.2: igmp leave 224.0.0.251 [ttl 1] 14:27:36.041121 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] 14:27:36.280442 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.63793 > 192.168.2.255.137: udp 50 14:27:36.548723 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.63793 > 192.168.2.255.137: udp 50 14:27:36.818514 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.63793 > 192.168.2.255.137: udp 50 14:27:39.549947 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.60856 > 192.168.2.255.137: udp 50 14:27:39.816475 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.60856 > 192.168.2.255.137: udp 50 14:27:40.086317 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.60856 > 192.168.2.255.137: udp 50 14:27:41.241586 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 0010 592e 4b5d ab13 6a8a 5468 a1bb 92dc d2a1 5606 774a ca79 21ee 1f36 7a5b 513c 4800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 14:27:41.246044 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 000e 25f5 26ea d5a7 3c46 5932 ec4a c83a 8296 ddcd 2d9f 2898 7993 e4c9 7d2e f970 5b00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00cb 81c0 6c6f c386 ba0b fa88 e42b bf4f 2300 1630 1401 14:27:41.246155 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 0110 592e 4b5d ab13 6a8a 5468 a1bb 92dc d2a1 5606 774a ca79 21ee 1f36 7a5b 513c 4800 0000 0000 0000 0000 0000 0000 0000 00b7 0000 0000 0000 0000 0000 0000 0000 001f bc0f b82e f53d b559 7a1e 20ce 00f5 3200 5007 189a 14:27:41.250146 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 010e 25f5 26ea d5a7 3c46 5932 ec4a c83a 8296 ddcd 2d9f 2898 7993 e4c9 7d2e f970 5b00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 009a b21b 2d7f 3cab dcd3 f298 520b adc6 4a00 00 14:27:41.251203 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:41.647413 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:42.046337 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:42.445851 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:42.845076 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:42.845253 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.254 tell 192.168.2.101 14:27:42.845302 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0806 42: arp reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy 14:27:43.243834 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:43.642860 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:43.972748 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] 14:27:44.045316 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:44.454036 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:53.471305 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 00a5 1a2b 8e57 cac6 0cfa 9719 f0bc ce58 805d fa5f 3d8d 43e5 085f c824 4256 11da a800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 14:27:53.475767 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 0017 31bd c74d e191 981d 0ec5 600f 0791 74b4 0962 9072 e2e2 59f4 c1e2 0590 c709 4200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 000f c9a1 0030 a0fe ad80 1872 677c 6053 2c00 1630 1401 14:27:53.475869 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 01a5 1a2b 8e57 cac6 0cfa 9719 f0bc ce58 805d fa5f 3d8d 43e5 085f c824 4256 11da a800 0000 0000 0000 0000 0000 0000 0000 00c2 0000 0000 0000 0000 0000 0000 0000 007a 46ed 25fd a8cf 3680 bba8 ad29 32bd e700 5014 0602 14:27:53.481258 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 0117 31bd c74d e191 981d 0ec5 600f 0791 74b4 0962 9072 e2e2 59f4 c1e2 0590 c709 4200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 007f 93f3 7e55 fc09 0e5b 50ce ed15 b160 df00 00 14:27:53.482552 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:53.875884 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:54.275093 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 14:27:54.674356 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:55.079843 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 14:27:55.079999 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.254 tell 192.168.2.101 14:27:55.080070 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:55.080082 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0806 42: arp reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy 14:27:55.488567 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:55.875358 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:56.276353 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 14:27:57.089293 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:02 0800 46: 192.168.2.101 > 224.0.0.2: igmp leave 224.0.0.251 [ttl 1] 14:27:57.089439 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] 14:28:00.533902 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] ^C 101 packets received by filter 0 packets dropped by kernel |
|
|||
And here's the tcpdump from the client:
Code:
14:40:12.215883 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117 14:40:12.215900 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 14:40:12.219956 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 14:40:12.219977 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 193: EAPOL key (3) v1, len 175 14:40:12.220487 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:12.620561 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:13.020662 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:13.420787 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 14:40:13.821017 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 14:40:13.821408 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.254 tell 192.168.2.101, length 28 14:40:13.825223 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:13.825279 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype ARP (0x0806), length 42: Reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy, length 28 14:40:14.225363 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:14.625490 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:15.025592 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:15.834600 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.2: igmp leave 224.0.0.251 14:40:15.834659 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.251: igmp v2 report 224.0.0.251 14:40:16.072058 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.51625 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:40:16.342945 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.51625 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:40:16.613281 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.51625 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:40:19.347260 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.54508 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:40:19.617561 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.54508 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:40:19.887840 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.54508 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST break 14:40:21.081885 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117 14:40:21.081902 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 14:40:21.085829 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:21.086021 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 14:40:21.086042 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 193: EAPOL key (3) v1, len 175 14:40:21.485940 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:21.886049 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 14:40:22.286175 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 14:40:22.530218 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.251: igmp v2 report 224.0.0.251 14:40:22.686436 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 14:40:22.686817 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.254 tell 192.168.2.101, length 28 14:40:22.689952 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype ARP (0x0806), length 42: Reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy, length 28 14:40:23.086030 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:23.486122 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:23.886227 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 14:40:24.286350 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 |
|
|||
You don't have to post over 1400 lines of tcpdump output.
The first thing you have to make sure is: Do I see the outgoing request packets and the incoming answers from a wired network host in those xterms? If something gets blocked it will show up in the tcpdump pflog0 xterm That is to confirm that the basic debugging strategy works. After confirmation repeat using a wireless client. Now Code:
13:17:00.243508 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0800 70: 192.168.2.254 > 192.168.2.99: icmp: host 17.149.36.197 unreachable Analysis of the first couple of packets Code:
13:16:40.908888 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0 [1n] [1au] ANY (Cache flush)? touchPod.local. (71) A request to the 224.0.0.0 multicast block 13:16:40.911770 0800 91: 192.168.2.99.57739 > 83.169.185.161.53: 59379+ A? safebrowsing.clients.google.com. (49) A DNS request source port 57739 -> dest port 53 13:16:40.919842 0800 211: 83.169.185.161.53 > 192.168.2.99.57739: 59379 7/0/0 CNAME clients.l.google.com.,[|domain] The answer source port 53 -> destination port 5773 So these DNS requests have no trouble passing 13:16:41.157010 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0 [1n] [1au] ANY? touchPod.local. (71) Looks like a DNS request packet to the 224.0.0.0 multicast block 13:16:41.261481 0806 42: arp who-has 169.254.255.255 tell 192.168.2.99 An ARP inquiry 13:16:41.406013 0800 113: 192.168.2.99.5353 > 224.0.0.251.5353: 0 [1n] [1au] ANY? touchPod.local. (71) 13:16:41.655503 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81) Looks like DNS request packets to the 224.0.0.0 multicast block 13:16:41.661492 0806 42: arp who-has 169.254.255.255 tell 192.168.2.99 An ARP inquiry 13:16:42.652756 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81) 13:16:44.667696 0800 123: 192.168.2.99.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) A 192.168.2.99, (81) Repeated cache flush requests to 224.0.0.0 multicast block 13:16:44.667828 0800 44: 192.168.2.99.5353 > 192.168.2.254.5351:[|domain] A truncated (by tcpdump) DNS packet 13:16:44.667962 0800 70: 192.168.2.254 > 192.168.2.99: icmp: 192.168.2.254 udp port 5351 unreachable An icmp message informing 192.168.2.99 that udp prt 5351 cannot be reached 13:16:44.668086 0800 170: 192.168.2.99.61471 > 192.168.2.254.1900: udp 128 13:16:44.668155 0800 70: 192.168.2.254 > 192.168.2.99: icmp: 192.168.2.254 udp port 1900 unreachable A SSDP packet and a message informing the sender that port 1900 cannot be reached
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
What do you mean? Should I forward/nat the ports to the outside or should I just pass in on rum0 from blabla to port { 1900, 5351 } ?
|
|
|||
In the pf.conf, I suggested and which I hope you are using, it is as simple as:
Code:
UDP_PORTS = '{domain 1900 5351}'
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump Last edited by J65nko; 2nd January 2010 at 03:22 PM. Reason: I forgot those "{" and "}" |
|
|||
Ok. I am allowing the traffic as you said.
router: Code:
# tcpdump -eni rum0 tcpdump: listening on rum0, link-type EN10MB 16:16:04.818278 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 007b c293 a1a9 0e55 ac19 4bc3 3578 cf33 5923 99b0 8aa9 24f0 51cb 1d1c c72e d9a6 3200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 16:16:04.822727 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 008b 1bae a891 9873 4d3e 262d 7c85 4397 b737 4246 1860 619f b161 1f8a 6dcf 92bb 9900 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00cb 3b26 cb91 7220 e1f5 a872 38ea 3097 6f00 1630 1401 16:16:04.822830 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 017b c293 a1a9 0e55 ac19 4bc3 3578 cf33 5923 99b0 8aa9 24f0 51cb 1d1c c72e d9a6 3200 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 00e3 c435 eb3c 4e44 a62a 9f6a 9b45 3e76 c600 50ff 2eb4 16:16:04.826968 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 018b 1bae a891 9873 4d3e 262d 7c85 4397 b737 4246 1860 619f b161 1f8a 6dcf 92bb 9900 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0046 f35d d255 2d7c 9c17 cd49 42b7 9a9a 0b00 00 16:16:04.830017 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:05.225046 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:05.624050 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:06.024032 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 16:16:06.432541 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 16:16:06.432688 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.254 tell 192.168.2.101 16:16:06.432779 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:06.432791 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0806 42: arp reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy 16:16:06.841232 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:07.222771 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:07.623250 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:08.451736 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:02 0800 46: 192.168.2.101 > 224.0.0.2: igmp leave 224.0.0.251 [ttl 1] 16:16:08.451859 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] 16:16:08.729106 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.55026 > 192.168.2.255.137: udp 50 16:16:08.998872 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.55026 > 192.168.2.255.137: udp 50 16:16:09.268674 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.55026 > 192.168.2.255.137: udp 50 16:16:11.825206 xx:xx:xx:xx:xx:xx 01:00:5e:00:00:fb 0800 46: 192.168.2.101 > 224.0.0.251: igmp nreport 224.0.0.251 [ttl 1] 16:16:11.997100 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.64321 > 192.168.2.255.137: udp 50 16:16:12.267852 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.64321 > 192.168.2.255.137: udp 50 16:16:12.536456 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0800 92: 192.168.2.101.64321 > 192.168.2.255.137: udp 50 16:16:13.672245 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 0011 76e4 d9fe 5038 7b65 a1aa 3e32 040c 4fb5 56ab 1179 381a 3d59 4d18 8706 25bc ae00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 16:16:13.676962 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 0068 5414 5c97 dec4 a3d7 e13e 001c 2cac b669 b5b1 6ea1 c047 c2fc d009 7d6f 73d3 4600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 006e 7ee2 88cc c251 7286 073f 8121 a4c9 a500 1630 1401 16:16:13.677065 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 0111 76e4 d9fe 5038 7b65 a1aa 3e32 040c 4fb5 56ab 1179 381a 3d59 4d18 8706 25bc ae00 0000 0000 0000 0000 0000 0000 0000 0014 0000 0000 0000 0000 0000 0000 0000 00e2 ff6e 1b64 0821 8e29 8243 6d50 d253 6700 5019 5fed 16:16:13.680966 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 0168 5414 5c97 dec4 a3d7 e13e 001c 2cac b669 b5b1 6ea1 c047 c2fc d009 7d6f 73d3 4600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00ae 61cf 6f10 4362 6d52 7467 7922 f004 3a00 00 16:16:13.682790 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:14.095521 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:14.481261 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 16:16:14.880498 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 16:16:15.279779 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 192.168.2.101 16:16:15.279936 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.254 tell 192.168.2.101 16:16:15.279987 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 0806 42: arp reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy 16:16:15.678772 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:16.077749 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:16.477014 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:16.876293 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 169.254.255.255 tell 192.168.2.101 16:16:25.870315 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 113: 0103 005f 0200 8a00 1000 0000 0000 0000 0086 131b f042 d636 11b2 dafd 37d0 4f07 56f0 35e1 89d0 5d74 2a93 4ece b270 f902 4f00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 16:16:25.874781 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 135: 0103 0075 0201 0a00 1000 0000 0000 0000 0053 6240 9743 afb0 b2b3 ea4c 3f6f cec2 3e65 80de a789 6afc ce63 2b4a 5f67 591d 3500 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 008c 7714 30fe af68 890e f63b 9165 8618 d000 1630 1401 16:16:25.874881 yy:yy:yy:yy:yy:yy xx:xx:xx:xx:xx:xx 888e 193: 0103 00af 0213 ca00 1000 0000 0000 0000 0186 131b f042 d636 11b2 dafd 37d0 4f07 56f0 35e1 89d0 5d74 2a93 4ece b270 f902 4f00 0000 0000 0000 0000 0000 0000 0000 001e 0000 0000 0000 0000 0000 0000 0000 005a ff46 45ea 5560 4d39 1fe4 3a90 bb93 2d00 5054 4137 16:16:25.878781 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 888e 113: 0103 005f 0203 0a00 1000 0000 0000 0000 0153 6240 9743 afb0 b2b3 ea4c 3f6f cec2 3e65 80de a789 6afc ce63 2b4a 5f67 591d 3500 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00e5 7e21 1369 14a9 b24b 0023 e748 3a58 e400 00 16:16:25.880610 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.2.101 tell 0.0.0.0 ^C 44 packets received by filter 0 packets dropped by kernel Code:
:# tcpdump -eni en1 tcpdump: WARNING: en1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes 16:19:18.623926 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117 16:19:18.623944 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:18.628216 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:18.628238 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 193: EAPOL key (3) v1, len 175 16:19:18.628467 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:19.028548 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:19.428753 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:19.828854 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 16:19:20.229426 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 16:19:20.229883 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.254 tell 192.168.2.101, length 28 16:19:20.230773 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:20.249442 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype ARP (0x0806), length 42: Reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy, length 28 16:19:20.630836 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:21.030975 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:21.431104 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:22.263078 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.2: igmp leave 224.0.0.251 16:19:22.263150 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.251: igmp v2 report 224.0.0.251 16:19:22.541029 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.55026 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:22.811397 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.55026 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:23.081914 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.55026 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:25.644632 xx:xx:xx:xx:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.2.101 > 224.0.0.251: igmp v2 report 224.0.0.251 16:19:25.816740 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.64321 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:26.087102 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.64321 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:26.357518 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.2.101.64321 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:19:27.499409 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117 16:19:27.499426 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:27.503625 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:27.503648 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 193: EAPOL key (3) v1, len 175 16:19:27.506847 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:27.907069 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:28.307199 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:28.707342 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 16:19:29.107630 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 192.168.2.101, length 28 16:19:29.108080 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.254 tell 192.168.2.101, length 28 16:19:29.111133 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype ARP (0x0806), length 42: Reply 192.168.2.254 is-at yy:yy:yy:yy:yy:yy, length 28 16:19:29.507371 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:29.907484 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:30.307619 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:30.707738 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.2.101, length 28 16:19:39.726657 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117 16:19:39.726675 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:39.728760 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.2.101 tell 0.0.0.0, length 28 16:19:39.730851 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95 16:19:39.730874 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype EAPOL (0x888e), length 193: EAPOL key (3) v1, len 175 ^C 44 packets captured 44 packets received by filter 0 packets dropped by kernel |
|
|||
Actually I am not interested in the client (only the clients packets arriving on the WLAN interface), but that en1 interface doesn't have an IP address
Code:
tcpdump: WARNING: en1: no IPv4 address assigned I suggest we continue with the iPhone Do you see any packets blocked in the tcpdump -eni pflog0 xterm? Who is supposed to hand out the IP addresses to the wlan clients? The OBSD router? Does it have the DHCP daemon running?
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump Last edited by J65nko; 2nd January 2010 at 05:10 PM. Reason: typo |
|
|||
Quote:
[QUOTE=J65nko;29065]Do you see any packets blocked in the tcpdump -eni pflog0 xterm? No. The only thing that appears is the message that igmp is being passed (as seen on post n° 28: http://www.daemonforums.org/showpost...2&postcount=28). But strangely the corresponding rule seems to be associated with the internal interface gem0. I do not understand this message because there's no rule that does igmp nor is there a rule that logs such things. The IP address is being given to the clients not by DHCPD since I switched that one off for the moment. I give the IP addresses manually. |
|
|||
A block log (all) logs all blocked packets to pflog0. That is why I insist on having that rule in your pf.conf
A tcpdump on your wlan rum0 interface will only show the packets that arrive on that interface. That does not mean that pf will let them pass. The only proof that the packet will pass out on your external interface, is seeing it go out in the tcpdump -eni $EXT xterm. If the packet is blocked by pf , we will, because of that "block log (all)" rule, see it in the tcpdump -eni pflog0 xterm. If we don't see a packet meant to leave through the external interface, it either will have been blocked by pf, and be visible on pflog0, or the router doesn't know how to route it. That is how we cover all possible routes (pun intended ) BTW If you give the IP addresses manually, you also have to give them them default route and tell them which name servers to use.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Quote:
Ok. I've tested all what I can think of. The iphone mainly produces traffic to 17.149.36.139:5223 which is being blocked out on $EXT. (I guess it is routed correctly but blocked on the outgoing interface.) This seems to be some sort of Apple crap. However, requests to google.com (port 80) and dns requests (port 53) are being passed out. Request from the client to port 1900 and 5353 are only seen on $WLAN and seem to be passing in the firewall on $WLAN but since there's no daemon or whatsoever listening on those ports the router sends icmp port not reachable packets back. Manually blocking these igmp packets (of which I still don't know what they are good for) does not make any difference. So in the end. I'm still puzzled. |
|
|||
Oh... And by the way. I also enabled dhcpd with "option router" set without any change in bahaviour of the clients.
|
|
|||
You could check netstat -s | grep route for stats of non-routable packets
Code:
$netstat -s | grep route 0 output packets discarded due to no route 0 SYNs dropped (no route or no space) 0 output packets discarded due to no route 0 no route 0 bad router solicitation messages 0 bad router advertisement messages I also noticed that your iPhone could send several requests out and received the corresponding replies. RE port 1900 Code:
$ grep 1900 /etc/services ssdp 1900/tcp # SSDP ssdp 1900/udp # SSDP Quote:
The Zeroconf entry mentions the 169.254.0.0/16 block which also could be seen in the tcpdump captures. I hope the netstat -s output of the OBSD firewall gives us some clue what is wrong.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Thanks for the lengthy reply. I'm not yet finished reading the articles but will continue soon.
In the meantime I played once again with the settings. The weird thing now is that the iphone disconnects every 10 seconds AGAIN. And I changed nothing overnight except for plugging off the adapter and enabled dhcpd for a short time. Back to the original settings from yesterday, the iphone still disconnects every 10 seconds. Then I remembered that I did change one thing, but not on the router but on the iphone: I turned off notifications. Enabled notifications again, the iphone disconnects every 60 seconds... Then I had a nice idea. I tried to ping the iphone from the router. What should I say. It works. But while the router is pinging the iphone it won't disconnect (tested it for 5 minutes). So I figured out as long as there is some kind of traffic or communication between the router and the iphone the iphone won't disconnect. Now that's strange. Maybe the adapter wants to change the frequency (or channel or what ever) every 10 seconds and the clients can't cope with that or are disoriented somehow? netstat -s | grep route shows some discarded output packets due to no route but the value doesn't changed over the last hour, so I suspect the rule contains just an old counter. Any other suggestions? Maybe it is possible to turn off channel hopping for the adapter or something similar? |
|
|||
I know how to debug OBSD firewalls and DMZ setups, but I never have used wireless stuff, until a month ago when Sinterklaas or Saint Nicolas brought me 2x a Netgear WNHDE111 HD 5 Ghz access point/bridge.
At this moment one, as access point, is connected to a switch in the living room. The switch connect to my wife's computer and the OpenBSD firewall. In my work room I have the other Netgear configured as a bridge. It connects to a switch with my two desktops connected. The bridge and the access point use proxy ARP. That is the only way because both wlan AP and bridge are in the same 192.168.222.0/24 network. That is another reason why I was interested to see your MAC addresses. I am going to add a third NIC to my OBSD firewall next week so the wireless LAN will have it's own subnet. What witheld me from wifi thus far is, that in my previous house nearly every room had UTP cable. I also disliked the low transmission speeds of the first wifi standards , and the unreliability and unsafety. I just could not believe people wanted to use that, sorry for the word, crap. Now I have to leave my door open, else the signal strength drops from 82 to 60%.. But the speed is OK, I get the same 750KB ftp downloads like over the wired Lan. Wifi, sorry my faith in you is weak, I am not a strong believer yet In my case the AP and the bridge negotiate the channel, so far no complaints about that.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Quote:
Code:
notebook / home-ethernet ----- \_____ router -----> cable modem ---- vpn ----> employee home-wifi -----´ \ iphone So what options do I have now? 1. Try setting up an arp proxy? Does that help? 2. Retry everything again and publishing the mac addresses here? 3. Maybe this issue is related to hardware and not software (routing, firewall, etc.) ? |
|
|||
I find it strange that the iPhone is able to connect and communicate through the firewall.
Don't you have another i386 desktop install a WiFi card and OpenBSD on it and try that as wireless client ? To eliminate the rum0 hardware, you could go to a Mom and Pop shop in the neighbourhood and get a hardware AP like I have, on a NoCureNoPay basis For less then 100 bucks, why continue struggling? You first plug it on your home ethernet. If that works then can add another NIC to your router. connect the hardware AP into the new NIC, so can give the wifi a subnet of its own, separate from the wired Lan.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Quote:
The iphone never was able to get packages other than port 80 and 53 through the firewall. The other packets (mainly port 5223) were blocked at the outside interface (EXT), port 5353 and port 1900 first blocked then passed on the wifi interface. |
|
|||
another rum0 user
I have D-Link DWA-110 (based on rum0).
I use it as client adapter on my laptop (because on-board wifi is unsupported Atheros 5424) and i can add my little experience. Your problems is probably drivers-related, my rum0 too semi-randomly disconnects from AP. But not in "ifconfig" form (status is active and link is established) but in "dhcp" form (because i need to "sudo dhclient rum0" to fix it). I use ifstated to automagically check (ping google.com) and fix my connection. PS So, IMHO, buggy driver/hardware version. PPS And sorry for my "newbie" terms, i'm total zero in networking. |
|
|||
Do you have your adapter running in ap mode or just in "normal" mode?
|
|
|||
as i said before i run it "normal" client mode, but behavior is very similar, isn't it?
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Wireless NIC for access point | dewarrn1 | FreeBSD General | 1 | 15th September 2009 11:01 PM |
How do I edit my .profile to permanently have an ftp site to point to | badguy | OpenBSD Packages and Ports | 12 | 19th July 2009 02:05 AM |
OpenBSD Wi-Fi acces point | LordZ | OpenBSD General | 4 | 18th October 2008 10:33 AM |
Point-to-Point VPN + Firewall + Router (sorta) - What should I use? | Bruco | FreeBSD General | 6 | 5th July 2008 11:09 PM |
Configuring a wireless access point | Serge | FreeBSD General | 6 | 6th June 2008 04:07 PM |