----- Original Message ---- > From: Ganbold <ganbold_at_gmail.com> > To: PseudoCylon <moonlightakkiy_at_yahoo.ca> > Cc: freebsd-current_at_freebsd.org; Ganbold Tsagaankhuu <ganbold_at_mobicom.mn> > Sent: Tue, June 15, 2010 8:02:02 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > AK-san, >PseudoCylon wrote: >>>>> From: Ganbold <ganbold_at_gmail.com> >>>>> To: PseudoCylon <moonlightakkiy_at_yahoo.ca> >>>>> Cc: freebsd-current_at_freebsd.org; Ganbold Tsagaankhuu <ganbold_at_mobicom.mn> >>>>> Sent: Thu, June 10, 2010 10:53:30 AM >>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>>>> >>>>> It seems like it is running without any problem so far, no more adsl >>>>> modem problem. >>>>> I can see arp packets in wlan0 interface as well as in macbook. >>>>> I will continue testing and let you know if there comes any problem. >>>>> >>>>> thanks again, >>>>> >>>>> Ganbold >>>>> >>>>> >>>> Hello, >>>> >>>> Glad to hear. It was an encryption problem. A client was dropping packets.. >>>> >>>> Please let me know if you find another bug. (Hope there won't be) >>>> >>>> >>> Well, looks like I was too fast :( >>> >>> It seems like client is not receiving any arp packets when rspro doesn't >>> first initiate ping (maybe arp request) to client. >>> If I first ping to client from rspro, later on arp packets can be seen >>> on client. >>> When I ping from rspro to client, response is very different: >>> >>> # arp -a >>> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >>> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >>> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >>> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >>> [ethernet] >>> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >>> [ethernet] >>> # ping 192.168.1.50 >>> PING 192.168.1.50 (192.168.1.50): 56 data bytes >>> 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >>> 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >>> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >>> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >>> 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >>> 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >>> 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >>> 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >>> 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >>> ^C >>> --- 192.168.1.50 ping statistics --- >>> 11 packets transmitted, 9 packets received, 18.2% packet loss >>> round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms >>> # arp -a >>> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >>> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >>> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >>> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >>> [ethernet] >>> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >>> [ethernet] >>> ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >>> [ethernet] >>> # ping 192.168.1.50 >>> PING 192.168.1.50 (192.168.1.50): 56 data bytes >>> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >>> 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >>> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >>> ^C >>> --- 192.168.1.50 ping statistics --- >>> 5 packets transmitted, 3 packets received, 40.0% packet loss >>> round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms >>> >>> >> >> Well, the patch is working (sort of). Old driver wouldn't let you ping anywhere. >> >> Replies are taking awfully long. One of them took 5 sec. This could be a different issue. >> >> Can you try a few thing? (Unfortunately, everything is working on my side.) >> * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? >> > >No. I will check again and let you know. > >> * If you give IP address to only bridge0, does it make any difference? >> > >I will let you know after testing. > >> * Does it make any difference if use rspro without 192.168.1.7 (if possible)? >> > >192.168.1.7 is just my freebsd laptop. > Hello, More questions. Is freebsd laptop working fine with wlan, or is it connected to ethernet port? Does adsl modem still freeze? Normally, when you ping from macbook to modem, there will be arp pakets 'who-has modem tell macbook' and 'modem is-at xx:xx...' Do you see these at wlan0 on rspro? If rspro can ping patch should be working, but let's make sure it is. Please before starting hostapd, sysctl hw.usb.run.debug=1 (If the driver is not compiled with kernel, please apply a patch attached.) When hostapd is started, it will print out Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:cf:03:e0:30 and ssid 'bsd' run_key_set: cmdq_store=0 run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off run_stop: All Tx cleared run_newstate: INIT -> INIT run_newstate: INIT -> SCAN ... omit some lines ... Please confirm there is run_key_set_cb: associd=0, mode=3, ... And, associd is '0' (This was the problem before. So, encryption with group key failed.) When macbook associates with AP, it will print run_newassoc: cmdq_store=2 run_newassoc: new assoc isnew=1 associd=c001 addr=00:26:bb:17:f6:61 run_newassoc: rate=0x82 ridx=0 ctl_ridx=0 ... omit some lines ... run_newassoc: rate=0x6c ridx=11 ctl_ridx=8 run_newassoc: rate=2, mgmt_ridx=0 run_key_set: cmdq_store=3 run_key_set_cb: associd=c001, keyix=0, mode=4, type=pairwise, tx=on, rx=on Please confirm there is run_key_set_cb: associd=c001, mode=4, ... And associd isn't '0'. If not, I need to fix the driver. If things go accordingly, please compare the mode. With your config, group key uses TKIP (mode 3) and pairwise key uses CCMP (mode 4). And very first arp who-has packet uses group key and other use pairwise key. Maybe, macbook doesn't like mixing the mode. So, please tcpdump -vvv -xxx -i wlan0 'arp' and check if any packet with address of all 'ff'. is sent/received alright. All 'ff 'means using group key. Others use pairwise key. All 'ff is easy to see in output of tcpdump. Or, you can chose one of them, CCMP or TKIP for 'wpa_pairwise=' and see if it makes any difference. Sorry for too many questions. It is working fine here, again. AK --patch Only needed if the driver is not compiled with the kernel-- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index e4fc8d2..65c1dab 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c _at__at_ -69,6 +69,7 _at__at_ __FBSDID("$FreeBSD: src/sys/dev/usb/wlan/if_run.c,v 1.11 2010/06/14 23:01:50 jki #include "usbdevs.h" #define USB_DEBUG_VAR run_debug +#define USB_DEBUG #include <dev/usb/usb_debug.h> #include "if_runreg.h" --end patch-- only one line to addReceived on Wed Jun 16 2010 - 08:43:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC