Ticket #12144 (closed defect: fixed)

Opened 2 years ago

Last modified 22 months ago

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

Reported by: garysu Owned by: Quozl
Priority: normal Milestone: 4-firmware
Component: ofw - open firmware Version: Development firmware
Keywords: Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Attachments

putty.log (19.0 kB) - added by garysu 2 years ago.
SSID message
putty.2.log (19.0 kB) - added by garysu 2 years ago.
putty_8686.log (8.9 kB) - added by garysu 2 years ago.
putty_8787.log (5.5 kB) - added by garysu 2 years ago.
putty.3.log (6.0 kB) - added by garysu 2 years ago.
Plan1 with q7b03jg.rom

Change History

Changed 2 years ago by dsd

  • owner set to Quozl
  • component changed from not assigned to ofw - open firmware

Changed 2 years ago by garysu

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

Changed 2 years ago by 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.

Changed 2 years ago by garysu

SSID message

Changed 2 years ago by garysu

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

Changed 2 years ago by garysu

Changed 2 years ago by 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?

Changed 2 years ago by Quozl

Gary Su, any update?

Changed 2 years ago by garysu

Changed 2 years ago by garysu

Changed 2 years ago by garysu

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

Changed 2 years ago by Quozl

  • next_action changed from never set to design

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.

Changed 2 years ago by 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.

Changed 2 years ago by 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.

Changed 2 years ago by 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

Changed 2 years ago by 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?

Changed 2 years ago by garysu

Plan1 with q7b03jg.rom

Changed 2 years ago by garysu

please review putty.3.log

Changed 2 years ago by 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.

Changed 2 years ago by garysu

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

Changed 2 years ago by Quozl

  • next_action changed from design to add to release
  • version changed from not specified to Development firmware
  • milestone changed from Not Triaged to 4-firmware

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.

Changed 22 months ago by Quozl

  • status changed from new to closed
  • next_action changed from add to release to no action
  • resolution set to fixed

Was released.

Note: See TracTickets for help on using tickets.