WiFi Refresh -- Report 3

[Phil Nelson]

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".

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Phil Nelson
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.)
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.)

Yes, we should be pushing as much work into shared code, and out of the drivers, as possible.

Post by Phil Nelson
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.

Probably worth taking a look at the FreeBSD urtwn driver to see what they're doing.

Post by Phil Nelson
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.)
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".

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Phil Nelson]

Post by Jason Thorpe

     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.

Probably worth taking a look at the FreeBSD urtwn driver to see what they're doing.

I have been reading their code, but it is a completely different code base
from our our urtwn code and without hardware documents (any one have
some to share????) it is a little difficult seeing what they are doing. I will
look closer for this issue for the rssi at some point.

--Phil

p.s. FreeBSD only has a urtw driver and it covers a lot fewer devices than
the NetBSD urtwn driver.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Phil Nelson

Post by Jason Thorpe

Post by Phil Nelson
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.

Probably worth taking a look at the FreeBSD urtwn driver to see what they're doing.

I have been reading their code, but it is a completely different code base
from our our urtwn code and without hardware documents (any one have
some to share????) it is a little difficult seeing what they are doing. I will
look closer for this issue for the rssi at some point.
--Phil
p.s. FreeBSD only has a urtw driver and it covers a lot fewer devices than
the NetBSD urtwn driver.

Oh, interesting. urtwn also exists in OpenBSD, and I think a FreeBSD guy has been doing work on it. "rtw" and "rtwn" are totally different devices, FWIW.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

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.

Would it be worth getting another USB WiFi device and plugging it into
a machine running hostapd(8) ?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Phil Nelson]

Post by Robert Swindells
Would it be worth getting another USB WiFi device and plugging it into
a machine running hostapd(8) ?

I'm sure it would help. I've got to learn it :)

--Phil

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Phil Nelson

Post by Robert Swindells
Would it be worth getting another USB WiFi device and plugging it into
a machine running hostapd(8) ?

I'm sure it would help. I've got to learn it :)

You don't even need to run hostapd(8) to have an access point. Heck,
you don't even need to run NetBSD on the access point. :-)

Usually it's important to have some NetBSD box with a highly capable
WiFi NIC with which you can eavesdrop on the unfiltered traffic
involving the device under test. It may help if it's a third NIC
doing the eavesdropping. There's no strong reason that the third
NIC has to be in a third computer.

I don't know if there is a driver in mainline NetBSD that lets you see
frames having a bad CRC or other malformedness, but it helps now and
then. ISTR adding sysctls to one or two drivers for that, but I may
have decided the capability was too obscure and never committed it.

Dave