tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
WiFi Refresh -- Report 3
Hello tech-net,
This is my third report on the WiFi Refresh.
I did not make as much progress as I hoped to make over the last
two weeks. I've been working with the urtwn driver to help me get
things working properly before moving on to other drivers. (Current
work has IPV6 turned off.)
Progress for the last two weeks:
1) worked through scanning, the code now scans. (I still have some
driver issues to work through. The urtwn driver has callouts to
do periodic scans, but the FreeBSD 802.11 also does periodic
scans. I suspect I should remove the driver initiated scans in
favor of the framework scans.)
2) Selecting an open network now works. An issue here is the urtwn
driver (and I suspect all drivers will need to deal with this), the
driver rssi (Receive signal strength indicator) in the driver
is is dBm, numbers appear to be between -100 to 20. The
FreeBSD network selection process is checking for rssi to be
between 8 and 40. I currently add 80 in urtwn when passing rssi
to the FreeBSD framework.
3) I can assign an IPV4 address. I've seen at least one arp request
packed come to the stack ... which crashed the system.
Tcpdump sees arp requests being transmitted ... but I get no
responses. It appears as if the transmit functions don't send a
correct packet, but I don't have an AP on which I can run tcpdump
to see if the transmitted packets.
(Seem to have a regression with today's work as the network
is not being reported as active where earlier this week it was
being reported as active.)
For the final part of the contract in the next two weeks I plan to do:
1) Get the NetBSD specific ioctls implemented. I still have a few to
to do including setting the nwkey.
2) Look into getting the sysctl system with more nodes added. I've
spent very little time on sysctls.
3) Continue to search for answers as to why I'm not getting IP packets
sent/received correctly. (Management packets appear to be working
due to seeing the scanning requests and replys and the building of
a correct list of stations in the area.)
4) If I can solve the IP packet problem and can use the open networks,
I'll then move to trying WEP. I doubt I'll get to WPA in the next two
weeks.
If you want to try my work, check out current and then check out "phil-wifi"
on sys/net80211 and sys/dev/usb/if_urtwn.c. You can also get my current
TESTWIFI config at sys/arch/amd64/conf/TESTWIFI. You will have to disable
IPV6 in this config to get similar results to me.
Here is a current session showing the regression mentioned above.
bash-4.4# ifconfig urtwn0
urtwn0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ssid ""
ec_capabilities=ffffffffea4cae10
ec_enabled=63c52788
address: 74:da:38:e2:9d:fd
media: IEEE802.11 autoselect (autoselect mode 11b)
status: no network
bash-4.4# ifconfig urtwn0 nwid notusable
bash-4.4# ifconfig urtwn0
urtwn0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ssid notusable
ec_capabilities=ffffffffea4cae10
ec_enabled=63c52788
address: 74:da:38:e2:9d:fd
media: IEEE802.11 autoselect (autoselect mode 11b)
status: no network
bash-4.4# ifconfig urtwn0 192.168.1.100 netmask 0xffffff00
bash-4.4# ifconfig urtwn0
urtwn0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ssid notusable
ec_capabilities=ffffffffea4cae10
ec_enabled=63c52788
address: 74:da:38:e2:9d:fd
media: IEEE802.11 autoselect (autoselect mode 11g)
status: no network
inet 192.168.1.100/24 broadcast 192.168.1.255 flags 0x0
bash-4.4#
I have seen the status "active".
Home |
Main Index |
Thread Index |
Old Index