[Solved] Error installing VirtualBox on Windows 10

Note: this solution works only if you have Kaspersky (or probably other security/antivirus) software installed.

Default VirtualBox installation on Win 10 failed with error messages:

Oracle VM VirtualBox 5.0.12 Setup Wizard ended prematurely
Installation failed! Fatal error during installation

Software versions:

VirtualBox 5.0.12 released on December 18th, 2015
Windows 10 build 10586

I can complete install only with all networking features disabled (no bridged, no host-only - no networking at all).

Solution in my case: remove Kaspersky antivirus (trial version pre-installed by the laptop vendor). Seems kaspersky network drivers/shim caused failure of VirtualBox network driver installation.

Security vs convenience. Is it Oracle or Kaspersky behaving odd?..

Update.
Found the same issue and solution at https://forums.virtualbox.org/viewtopic.php?f=6&t=68590&start=315

Включается, но не загружается wifi Extreme Altitude AP450

Столкнулся с такой проблемой. Не работает Wi-Fi точка Extreme Networks Altitude AP450.
Не видно ее по радио (SSID), не включается Ethernet-порт (и при Power over Ethernet-подключении, и с внешним блоком питания). Что хорошо: есть признаки жизни, при загрузке загорается первый светодиод зеленым цветом - и на этом всё. В документации такой случай (LED1 Solid Green) не описан.
Традиционный ход в таких случаях - собрать максимум информации по проблеме и открывать тикет у производителя. Я попробовал разобраться сам, т.к. точка нужна была срочно.

К счастью, у AP450 имеется консольный порт (Serial Port) с разъемом RJ45. А значит, достаточно консольного кабеля (коих у нас столько, что можно благотворительно раздавать), подключаемся COM-портом или переходником USB-COM и получаем текстовую консоль устройства на скорости 9600 бит/с или выше. Экспериментально (а затем и чтением документации) находится скорость 115200.

Перезагрузив точку, увидим по консоли, что загрузчик живой, но:

U-Boot 1.2.0.05 (Mar 26 2008 - 16:44:22)
Primary Image
DRAM:  128 MB
Flash: 16 MB
In:    serial
Out:   serial
Err:   serial
Net:   eth0
Hit any key to stop autoboot:  2 ... 1 ... 0 
### JFFS2 loading 'boot_kernel.img' to 0x80400000
Scanning JFFS2 FS:   ... done.

### JFFS2 load complete: 2732 bytes loaded to 0x80400000

## Checking Image at 80400000 ...
   Image Name:   Boot ROM Script
   Created:      2007-11-01  17:00:32 UTC
   Image Type:   PowerPC Linux Script (uncompressed)
   Data Size:    2668 Bytes =  2.6 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Executing script at 80400000
check for watchdog, limit=3...
check for reset by watchdog...
no watchdog...
bSaveEnviron=0 image_order=secondary primary
### JFFS2 loading 'secondary.gz.uImage' to 0x80500000
### JFFS2 load complete: 3098725 bytes loaded to 0x80500000
ready to boot kernel, starting watchdog...
## Booting image at 80500000 ...
   Image Name:   Linux Kernel Image
   Created:      2009-04-25   0:19:30 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    3098661 Bytes =  3 MB
   Load Address: 80060000
   Entry Point:  80246000
   Verifying Checksum ... Bad Data CRC
boot failed - stopped watchdog
### JFFS2 loading 'primary.gz.uImage' to 0x80500000
### JFFS2 load complete: 2612177 bytes loaded to 0x80500000
ready to boot kernel, starting watchdog...
## Booting image at 80500000 ...
   Image Name:   Linux Kernel Image
   Created:      2008-09-14   5:31:36 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    2612113 Bytes =  2.5 MB
   Load Address: 80060000
   Entry Point:  80246000
   Verifying Checksum ... Bad Data CRC
boot failed - stopped watchdog
ERROR: Cannot boot either kernel image, dropping to interactive shell.
Boot-> 

Что это означает по-русски?
1. После включения микрокод системной платы передал управление на загрузчик U-Boot, прочитав его из первого сектора встроенной флешки. 
2. Загрузчик в соответсвии со своими настройками (которые хранятся там же на флеше) прочитал вспомогательный код boot_kernel.img и запустил его.
3. Вспомогательный код находит на флешке образ операционной системы (secondary.gz.uImage), копирует его в RAM, проверяет корректность и контрольную сумму, после чего передает ему управление.
4. На шаге проверки контрольной суммы и обрывается загрузка: оба образа ОС, сохраненные во флеше (secondary.gz.uImage, primary.gz.uImage) оказываются битыми - "Verifying Checksum ... Bad Data CRC".
5. В итоге получаем "ERROR: Cannot boot either kernel image, dropping to interactive shell."
6. Дружелюбное приглашение "Boot->" как бы намекает - сделайте что-нибудь.

Наша задача: имея живой загрузчик восстановить операционную систему. Поскольку обе прошивки битые, то восстановление работоспособности AP потребует следующих 3 шагов:

1. Найти прошивку;
2. Затолкнуть ее в устройство (в RAM или Flash);
3. Запустить ее.

Этап 1. Образ ОС.
1.1 На сайте производителя стягиваем A450-V5R1.10310.3.img:

 
1.2 Распаковываем его как bzip2-архив:

Этот файл назовем boot.img и попробуем с ним загрузиться.

1.3 Но сначала сравним наш получившийся файл boot.img с образом из флеш (primary.gz.uImage).
Как это сделать? К флешке прямого доступа нет. Но образ с флешки уже оказался в RAM, как видно в лога выше: ### JFFS2 loading 'primary.gz.uImage' to 0x80500000

Воспользуемся командой чтения памяти (md = memory dislay):

Boot-> md 0x80500000
80500000: 27051956 02cf3b82 48cca1b8 0027db91    '..V..;.H....'..
80500010: 80060000 80246000 5de703fc 05050201    .....$`.].......
80500020: 4c696e75 78204b65 726e656c 20496d61    Linux Kernel Ima
80500030: 67650000 00000000 00000000 00000000    ge..............
80500040: 1f8b0808 b7a1cc48 0003766d 6c696e75    .......H..vmlinu
80500050: 782e6269 6e00ec7d 0f745b57 99e7f7fe    x.bin..}.t[W....
80500060: d8561295 3ebb6aaa 3629969c 2759b486    .V..>.j.6)..'Y..
80500070: 518bda9a 41d017c9 495d08e0 76c31096    Q...A...I]..v...
80500080: ce8cea24 25b0dd3d ee1286ec 4ee828b6    ...$%..=....N.(.
80500090: 92baa058 060278d9 cc41752c d714d972    ...X..x..Au,...r
805000a0: 4b4a0d93 8249d2e2 61bb4bd8 e99ee9e9    KJ...I..a.K.....
805000b0: 74c03419 da619843 8002eebf bcfd7df7    t.4..a.C......}.
805000c0: be27cb92 95041838 67dae61c f7e9ddef    .'.....8g.......
805000d0: deef7edf 77bffbfd b9f7be5b 229a25f9    ..~.w......[".%.
805000e0: f7dabfd7 febdf6ef 55fe2fae a71bdb1f    ........U./.....
805000f0: b69f3533 fa4ea248 b0f44d32 bcca679e    ..53.N.H..M2..g.

Сравнивая с картинкой boot.img (вверху) находим небольшое отличие: строка Linux Kernel Image в нашем файле смещена дальше от начала, т.е. boot.img содержит дополнительный заголовок. 
Если на следующем этапе записать наш файл в память по тому же адресу 0x80500000 и запустить, то получили бы ошибку:

Boot-> bootm
## Booting image at 80500000 ...
Bad Magic Number

1.4 Нужно либо обрезать лишний заголовок в нашем файле, либо оставить и учесть это смещение в будущем при записи в RAM. Арифметика говорит, что немодифицированный boot.img нужно будет писать по адресу 0x804FFE00.

Этап 2. Заталкивание образа ОС в коробочку.
Изучая CLI и просматривая мануал по U-Boot находим, что поддерживается загрузка по консоли (115200 бит/с), TFTP (на скорости сети), из флеш.
Выберем загрузку с TFTP как самый оперативный способ. Консоль - медленно; флеш - нужно разобрать коробочку и скорее всего флешка окажется неподходящего форм-фактора.
Считаем, что в U-Boot командами printenv и setenv уже выставлены сетевые настройки (я же использовал DHCP, чтобы заодно указать адрес TFTP-сервера и имя файла). Также в сети (на ноуте) запущен TFTP-сервер.

2.1 Чтобы поднять Ethernet-порт, надо инициировать сетевую активность с самой точки.

Boot-> ping 192.168.1.97
Using eth0 device
ping failed; host 192.168.1.97 is not alive

Первый пинг неудачен, медленно поднимается сетевой интерфейс, зато последующие в порядке.

Boot-> ping 192.168.1.97
Using eth0 device
host 192.168.1.97 is alive

2.2 Загружаем образ в RAM по TFTP
Если переменные окружения выставлены, достаточно набрать "tftp". Если нет, то полный синтаксис:

tftpboot [loadAddress] [[hostIPaddr:]bootfilename]

Берем вычисленный выше адрес. Получается:

Boot-> tftp 804ffe00 192.168.1.97:boot.img
Using eth0 device
TFTP from server 192.168.1.97; our IP address is 192.168.1.20
Filename 'boot.img'.
Load address: 0x804ffe00
Loading: *.#################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     ##########################################
done
Bytes transferred = 5534818 (547462 hex)

Этап 3. Запуск
3.1 Проверяем, что у нас оказалось в RAM по 0x80500000. Точно что и требовалось:

Boot-> md 80500000
80500000: 27051956 02cf3b82 48cca1b8 0027db91    '..V..;.H....'..
80500010: 80060000 80246000 5de703fc 05050201    .....$`.].......
80500020: 4c696e75 78204b65 726e656c 20496d61    Linux Kernel Ima
80500030: 67650000 00000000 00000000 00000000    ge..............
80500040: 1f8b0808 b7a1cc48 0003766d 6c696e75    .......H..vmlinu
80500050: 782e6269 6e00ec7d 0f745b57 99e7f7fe    x.bin..}.t[W....
80500060: d8561295 3ebb6aaa 3629969c 2759b486    .V..>.j.6)..'Y..
80500070: 518bda9a 41d017c9 495d08e0 76c31096    Q...A...I]..v...
80500080: ce8cea24 25b0dd3d ee1286ec 4ee828b6    ...$%..=....N.(.
80500090: 92baa058 060278d9 cc41752c d714d972    ...X..x..Au,...r
805000a0: 4b4a0d93 8249d2e2 61bb4bd8 e99ee9e9    KJ...I..a.K.....
805000b0: 74c03419 da619843 8002eebf bcfd7df7    t.4..a.C......}.
805000c0: be27cb92 95041838 67dae61c f7e9ddef    .'.....8g.......
805000d0: deef7edf 77bffbfd b9f7be5b 229a25f9    ..~.w......[".%.
805000e0: f7dabfd7 febdf6ef 55fe2fae a71bdb1f    ........U./.....
805000f0: b69f3533 fa4ea248 b0f44d32 bcca679e    ..53.N.H..M2..g.

3.2 Проверим целостность образа

Boot-> iminfo 80500000
## Checking Image at 80500000 ...
   Image Name:   Linux Kernel Image
   Created:      2008-09-14   5:31:36 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    2612113 Bytes =  2.5 MB
   Load Address: 80060000
   Entry Point:  80246000
   Verifying Checksum ... OK

3.3 При желании можно выполнить последовательность команд загрузочного скрипта (boot_kernel.img), благо его код присутствует в самой прошивке:

3.4 Передаем управление на загруженный код

Boot-> bootm 0x80500000
## Booting image at 80500000 ...
   Image Name:   Linux Kernel Image
   Created:      2008-09-14   5:31:36 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    2612113 Bytes =  2.5 MB
   Load Address: 80060000
   Entry Point:  80246000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...
Linux version 2.6.15--LSDK-7.0.0.335 (root@mismbldv06) (gcc version 3.4.4) #2 Sun Sep 14 01:31:25 EDT 2008
flash_size passed from bootloader = 16
<...>
init started: BusyBox v1.6.0 (2008-09-14 01:26:Algorithmics/MIPS FPU Emulator v1.5
52 EDT) multi-call binary
starting pid 14, tty '': '/etc/rc.d/rcS'
Jan  1 00:00:06 syslogd started: BusyBox v1.6.0
Jan  1 00:00:06 kernel: klogd started: BusyBox v1.6.0 (2008-09-14 01:26:52 EDT)
<...>

3.5 Как видно, система стартовала нормально. Далее точка доступа благополучно по сети нашла контроллер (систему централизованного управления) и выполнила полезную работу: стянула с него свежую прошивку и сохранила во флеш. Молодец!

(none) mips #2 Sun Sep 14 01:31:25 EDT 2008 
(none) login: 
*************************
Reboot issued due to: Software Image Upgrade
*************************

После перезагрузки wifi-точка запустилась исправно и теперь стабильно работает.

Вот так коробочка вернулась к жизни. А загрузчик U-Boot в целом произвел весьма приятное впечатление!

P.S. Справочно, printenv с коробочки:

Boot-> printenv
bootcmd=run boot_flash
bootdelay=2
baudrate=115200
ipaddr=192.168.1.20
serverip=192.168.1.1
gatewayip=192.168.1.1
netmask=255.255.255.0
PB44_CONFIG1_ADDR=0xBFE80000
PB44_CONFIG1_SIZE=0x40000
PB44_CONFIG2_ADDR=0xBFEC0000
PB44_CONFIG2_SIZE=0x40000
WATCHDOG_LIMIT=3
MOSTRECENTKERNEL=1
BOOT_KERNEL=primary
BOOT_BOOTROM=unknown
SERVICEATTRS=ac_manager,ru_manager
VERSIONBASE=0
REGION=NA
mtdparts=mtdparts=ar7100-nor0:256K(BootBAK)ro,256K(BootPRI),14336K(FS),256K(CFG1),256K(CFG2),256K(NVRAM1),256K(NVRAM2),256K(RSVD1),256K(RSVD2)
static_bootargs=console=ttyS0,115200n81 mem=130560K panic=30 ro
boot_flash=order="img bak"; for script in ${order}; do if fsload 0x80400000 boot_kernel.${script}; then if imi 0x80400000; then autoscr 0x80400000; exit; fi; fi; done; echo ERROR: Problem with boot script, dropping to interactive shell
ethact=eth0
DEFAULT_SETTING=0
CURR_VER=U-Boot 1.2.0.05 (Mar 26 2008 - 16:44:22)
MODEL=A450
SERIAL#=1000008299080291
ethaddr=00:04:96:3A:38:96
RADIOADDR0=00:04:96:3A:97:E0
RADIOADDR1=00:04:96:3A:97:E8
HW_RELEASE=3
MB81_CTL_VER=2
MB82_CTL_VER=3
SERVICETYPE=extreme
AC_HOSTNAME=ext-summitwm-connect-1
APSK=0225CEB33E7586566DF2C97EE14F48AEAB8400E4C5240F22A500B9260D76242378
WATCHDOG_COUNT=0
stdin=serial
stdout=serial
stderr=serial
mem=130560k
ver=U-Boot 1.2.0.05 (Mar 26 2008 - 16:44:22)
filesize=27dbd1
bootargs=mtdparts=ar7100-nor0:256K(BootBAK)ro,256K(BootPRI),14336K(FS),256K(CFG1),256K(CFG2),256K(NVRAM1),256K(NVRAM2),256K(RSVD1),256K(RSVD2) BOOT_BOOTROM="U-Boot 1.2.0.05 (Mar 26 2008 - 16:44:22)" BOOT_KERNEL=primary console=ttyS0,115200n81 mem=130560K panic=30 ro
WDOG_TIMER=0xffffffff
TEMP=0x00000000

Blinking WiFi led (Debian on HP6730b)

Blinking wifi led on my laptop really annoys me: this problem appeared after regular update. Google says that it's known issue, so how to cope with it?

Assume you use iwlagn module for Intel wireless card. It might be iwl3945 or something similar: just use your module name instead of iwlagn in steps below.

So, firstly, look at lsmod to check Intel wifi module name:
$ lsmod | grep w
iwlagn                150691  0
usb_wwan               12950  1 option
usbserial              27298  2 option,usb_wwan
...

Secondly, find out led options with modinfo:
# modinfo iwlagn | grep led
parm:       led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking (int)
parm:       plcp_check:Check plcp health (default: 1 [enabled]) (bool)
parm:       ack_check:Check ack health (default: 0 [disabled]) (bool)

As light is blinking, we conclude that default value is not good enough. Let set more convenient value "1", so led would be on when the adapter is turned on, and off when the adapter is off.

Create file /etc/modprobe.d/wlan.conf with single line:
options iwlagn led_mode=1

Finally, reboot the laptop or just execute:

rmmod iwlagn

modprobe iwlagn

Now LED is solid blue when on and solid amber when off.

Тестируем пропускную способность WiFi с iPerf

Intro

Есть беспроводная сеть. Но скорость передачи файлов бывает падает до 700 кБ/с и ниже. Так что захотелось выяснить, в чем дело: где узкое место и кого давит жаба.

Вероятные источники проблемы:

1. Интерференция
2. Другой трафик
3. Ноутбук или точка ASUS WL-500W: неудачаная реализация/драйверы/система

Для проверки этих гипотезы подойдет iPerf - открытый и бесплатный инструмент для тестирования пропускной способности сети. Работает под Linux и Windows (здесь), интерфейс - командная строка (отмечу, что есть еще jPerf - переписан на Java и с графическим интерфейсом).

В Debian устанавливается через:

apt-get install iperf

Запуск
Одна сторона - сервер: iperf -s
Другая сторона - клиент: iperf -c Server_IP

При этом iperf замеряет пропускную способность по TCP от клиента к серверу. Для полудуплексной беспроводной сети это и нужно, трафик идет от беспроводного клиента (ноутбук) через точку доступа к компьютеру в обычной сети.
В других случаях может быть полезной опция -d (Do a bidirectional test simultaneously).

В ходе тестов удалось посмотреть как ведет себя сеть и убедиться, что действительно в разное время пропускная способность разная.

Нормальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 33344 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 5.0-10.0 sec 12.9 MBytes 21.7 Mbits/sec
[ 3] 10.0-15.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 15.0-20.0 sec 13.3 MBytes 22.3 Mbits/sec
[ 3] 0.0-20.0 sec 52.5 MBytes 22.0 Mbits/sec

Как видно, при теоретическом пороге для полудуплексного 802.11g в 27 Мбит/c мы получаем приемлемое значение около 22-23 Мбит/c. Передача файла по SMB с линукс-станции на виндовую шару в такое время выдает 2 Мбайт/c = 16 Мбит/с, что кажется приемлемым, учитывая болтливость протокола SMB.

Аномальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 37460 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 12.7 MBytes 21.3 Mbits/sec
[ 3] 5.0-10.0 sec 10.1 MBytes 16.9 Mbits/sec
[ 3] 10.0-15.0 sec 6.71 MBytes 11.3 Mbits/sec
[ 3] 15.0-20.0 sec 2.33 MBytes 3.91 Mbits/sec
[ 3] 0.0-20.5 sec 31.8 MBytes 13.0 Mbits/sec

Что-то происходит и скорость начинает падать. Вот продолжение:
[ 3] 0.0- 5.0 sec 4.71 MBytes 7.90 Mbits/sec
[ 3] 5.0-10.0 sec 5.09 MBytes 8.53 Mbits/sec
[ 3] 10.0-15.0 sec 3.92 MBytes 6.58 Mbits/sec
[ 3] 15.0-20.0 sec 6.41 MBytes 10.7 Mbits/sec

Отключение домашней сети (плоская сеть с сотней компьютеров) ситуацию не меняет.
Остаются варианты:
а) интерференция - микроволновки и т.п.
б) левый трафик в беспроводной сети: нужно при случае перевести карточку в monitor mode и посмотреть, что там бегает.

Диагностика в режиме UDP
А пока я успел перевести iperf в режим работы через UDP и пронаблюдал следующую интересную картину.
sk@hal:~$ iperf -i 5 -t 300 -c 192.168.0.65 -u -b 25m
------------------------------------------------------------
Client connecting to 192.168.0.65, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 35797 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 9.81 MBytes 16.5 Mbits/sec
[ 3] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec
[ 3] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec
[ 3] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec
[ 3] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec

Т.е. удалось запечатлеть момент когда закончилась "яма" и скорость снова вышла на нормальный уровень.
На самом деле тестирование по UDP в случае беспроводной сети позволяет заглянуть еще дальше и точнее понять происходящее. Вот выходные данные на стороне сервера:
H:\soft\Network\iPerf, jPerf>iperf -s -i 5 -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[1928] local 192.168.0.65 port 5001 connected with 192.168.0.63 port 35797
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1928] 0.0- 5.0 sec 9.84 MBytes 16.5 Mbits/sec 0.602 ms 0/ 7022 (0%)
[1928] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec 0.600 ms 0/10521 (0%)
[1928] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec 0.591 ms 0/ 4684 (0%)
[1928] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec 0.590 ms 0/10609 (0%)
[1928] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec 0.586 ms 0/10638 (0%)

Видно что потерь пакетов нет. UDP, как известно, протокол без потверждения доставки; в отличии от TCP он не может адаптироваться к заторам в сети; UDP-клиент (в нашем случае iperf) отсылает трафик с возможной для него скоростью (для iperf выставлено 25 Мбит/c).
Но мы видим, что в "яме" скорость отправки составляла 16.5 Мбит/с и даже 11.0 Мбит/с. Вместе с тем, нет сброшенных пакетов и ошибок, в сети ничего не потерялось. Значит, что-то не давало клиенту возможности отправлять трафик в сеть с большей скоростью. Что это?

Это - механизм контроля доступа к беспроводной среде - CSMA/CA (Carrier sense multiple access with collision avoidance). Он мониторит среду и обнаруживает, что какая-то станция уже передает трафик, и не позволяет отправить фрейм в этот момент.

Т.е. тест показывает, что в беспроводной сети присутствует некий "левый" (с моей точки зрения) трафик; остается его идентифицировать и принять меры по лечению...

Что касается iPerf, он снова хорошо показал себя: легкий, удобный и удивительно полезный инструмент.