Протокол HTTP требует, чтобы строки заголовка заканчивались на \ r \ n
в нотации UNIX). Чтобы увидеть, что на самом деле возвращает curl
, вы можете попробовать:
curl -IL --silent $username:$password@$IP_addr | grep HTTP | cat -v
В UNIX $ isOK
в последующих сообщениях связано с завершающим
echo "$isOK is not the same as $status"
записывает
HTTP/1.1 401 Unauthorized<CR>
is not the same as HTTP/1.1 401 Unauthorized
в одну и ту же строку.
Частичный ответ:
Ваш беспроводной адаптер подключен к шине PCI 3b. Согласно dmesg
,
[ 0.338888] pci 0000:00:1c.0: PCI bridge to [bus 3b]
эта шина находится за мостом PCI 0:1c.0
. Существует четыре сообщения об ошибках, связанных с четырьмя разными мостами PCI :
[ 0.888395] dpc 0000:00:1b.0:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[ 0.888407] dpc 0000:00:1c.0:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[ 0.888423] dpc 0000:00:1c.4:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[ 0.888436] dpc 0000:00:1d.0:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
, возможно, поэтому он не может найти беспроводной адаптер. Я не знаю, что должно быть за теми другими мостами.
Вы можете сравнить с выводом dmesg
при работающей загрузке и посмотреть, присутствуют ли все еще сообщения об ошибках.
Однако я подозреваю, что это какая-то аппаратная проблема. Это будет нелегко исправить.