[CL4]The test /waln twice and screen full in SSID message.

[garysu]

OS:31004o4
OFW:Q7B02
The test /waln twice and screen full in SSID message.
(Test with new wireless module (WCBN603MH) for C build)
Procedure
1.Enter to OK prompt
2.test /wlan => appear SSID with empty message
3.test /wlan again => screen full in SSID.

[garysu]

Sorry for the lost information, this wireless card is new one of 8787(WCBN603MH)
it supported wireless 802.11 abgn + Bluetooth

[Quozl]

Gary, please provide serial port output. I have tried test /wlan repeatedly with Q7B02 XO-4 B1 with 8787 card, and it does not fail for me. But I have different access points. Perhaps the problem depends on the environment.

[garysu]

SSID message

[garysu]

duplicated this message after test 4 times, there are many access point working in my office.

[Quozl]

Thanks. Still I cannot reproduce it. Your serial port output shows the .ssids word may have processed beyond the scan buffer. I propose two action plans:

Plan 1

Use the following test method to manually scan and dump the scan buffer:

ok select /wlan:force     \ open the device
ok (scan)                 \ request a scan
ok .                      \ print the scan command result (success or fail)
0                         \ zero means success
ok .s                     \ print the scan command returned values
fd9f6b80 d7               \ address and length of scan buffer
ok 2dup cdump             \ dump the buffer
b8 00 02 55 00 00 1a 2b ...
ok drop .ssids            \ display the scan results
ok unselect               \ test finished

Repeat the test until the problem in this ticket occurs. Attach the serial port output.

Plan 2

Try in the same office location using an 8686 card, so that I can check to see if the problem is unique to the 8787 card?

[Quozl]

Gary Su, any update?

[garysu]

For 8686 no this issue, it occurs with this card, use the same unit to do test.

[Quozl]

Thanks, your scan result packet causes the same problem here.

The printing of the display results has read beyond the buffer, and the result is unpredictable. This is a defect in Open Firmware. I'll try to fix it so that it does not read beyond the buffer.

The maximum packet buffer size is 1600 bytes, and the scan result packet was truncated to this size. A following packet may hold the remainder of the scan result, or the module may have wanted to DMA more than 1600 bytes, I'm not sure which.

It is the complexity of the data structures sent by the access points that combines with the firmware defect to cause this problem. The order in which the beacons are received also affects the problem. The data structures can be seen with a modified scan;

ok dev /supplicant patch .ie .ie-short .ap-ssid dend scan-wifi

This may generate incorrect output for the same reason.

[Quozl]

Research notes.

WLAN Subsystem host driver-firmware interface v14.0 does not appear to mention a maximum packet size.

Review of the Linux kernel driver mwifiex.

A #define MAX_SCAN_BEACON_BUFFER 8000 exists but is not used. Several defines suggest packet buffers exceeding the 1600 bytes used in Open Firmware.

Handling of corrupt scan results buffer looks good. The driver reports "SCAN_RESP: TLV buffer corrupt\n" if the end of the buffer is reached while processing TLVs. mwifiex_ret_802_11_scan_get_tlv_ptrs. The driver also reports "err: InterpretIE: in processing IE, bytes left < IE length\n" if the end of the buffer is reached while processing IEs. mwifiex_update_bss_desc_with_ie. "InterpretIE: not enough bytes left\n" and "%s: bytes left < IE length\n" may also occur.

[Quozl]

Gary Su, please try testing with http://dev.laptop.org/~quozl/q7b03jg.rom ... this is a test version that only contains larger packet buffers. It doesn't fix the defect, but it might avoid it. This is useful for me to prove the cause.

[garysu]

Hi Jaems, after test over 50 times(test /wlan many)it better than previous version. except SSID lost infomation, it appear Channel information only, unknow it is problem or not.
ex: RSSI: 30 SSID:　　　　 Channel: 11 (SSID disappear)

RSSI: 44 SSID:3COM　　Channel: 11

[Quozl]

Thanks! I acknowledge that an SSID did not appear. This is a surprise. There was no change to SSID printing in this version, so I presume the data was not provided by the wireless module. Scan results can be somewhat random, as it depends on when the scan starts in relation to the beacon transmissions. Some access points have SSID that cannot be printed. Could you repeat the "Plan 1" test method above so that I can check this?

[garysu]

Plan1 with q7b03jg.rom

[garysu]

please review putty.3.log

[Quozl]

(Thanks for the additional ticket comment. Sorry I didn't notice the log earlier, our ticket system does not send mail for attachments.)

The output you see in this log is expected. Further detail below:

I've loaded the dump into an XO-4 B1 here and run .ssids and the same output is generated.

Looking at the entries where an SSID did not appear, each one of them corresponds to an access point that has provided an empty SSID IE TLV. This may happen if the access point is configured for hidden SSID.

• at offset 14e (RSSI 34), the SSID is empty, the IE TLV is h# 00 00,
• at offset 433 (RSSI 25), and at offset 54f (RSSI 26), the SSID is empty, the IE TLV is h# 00 01 00.

The test shows that increasing the buffer size solves the problem.

[garysu]

Yes, it solves this, and wireless can connect AP in sugar(31007o4).

[Quozl]

There should have been no impact on Sugar, since my change was only to the Open Firmware driver, and this driver is not used in Sugar.

Increasing the buffer size isn't obviously the right thing to do, and I cannot find any specification of the maximum scan buffer size in the Marvell documentation.

http://dev.laptop.org/~quozl/q7b03jh.rom fixes the problem by stopping the display of the scan buffer results when the end of the scan buffer has been reached.

svn 3374.

[Quozl]

Was released.