БАГИ

Ответить

Смайлики
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:
BBCode ОТКЛЮЧЕН
Смайлики ВКЛЮЧЕНЫ
Обзор темы
   

Развернуть Обзор темы: БАГИ

Re: БАГИ

aka » Ср окт 30, 2013 1:14 pm

MAGNet писал(а):Достигнут максимальный общий размер ваших вложений.
Гы. Оно мне тоже так сказало. Починил.

Re: БАГИ

MAGNet » Чт окт 17, 2013 5:39 am

aka писал(а):Если 192.168.21.103 это IP терминала, а 00.27.22.c0.c1 это не МАК терминала, то ругань терминала вполне обоснована. Именно такой пакет должно рассылать любое другое устройство, занимающее тот же МАК, что и наш терминал.
Всё именно так. Нужно отключить антенну, видимо она сошла ума.

Re: БАГИ

aka » Ср окт 16, 2013 9:04 pm

В логе на две строчки выше твоего выделения дамп ARP пакета. ARP это вот это: http://ru.wikipedia.org/wiki/ARP

В этом дампе:

00 01 - Hardware type (HTYPE)
Каждый канальный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001.

08 00 - Protocol type (PTYPE)
Код сетевого протокола. Например, для IPv4 будет записано 0x0800.

06 - Hardware length (HLEN)
Длина физического адреса в байтах. Адреса Ethernet имеют длину 6 байт.

04 - Protocol length (PLEN)
Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта.

00 01 - Operation
Код операции отправителя: 1 в случае запроса и 2 в случае ответа.

00 27 22 c0 c1 - Sender hardware address (SHA)
Физический адрес отправителя.

c0 a8 15 67 - Sender protocol address (SPA)
Логический адрес отправителя.

00 00 00 00 00 00 - Target hardware address (THA)
Физический адрес получателя. Поле пусто при запросе.

c0 a8 15 64 - Target protocol address (TPA)
Логический адрес получателя.

Это корректно составленный ARP запрос. Машина с МАКом 00.27.22.c0.c1 и IP адресом c0.a8.15.67 (192.168.21.103) спрашивает у сети, какой МАК у устройства с IP c0.a8.15.64 (192.168.21.100).

Если 192.168.21.103 это IP терминала, а 00.27.22.c0.c1 это не МАК терминала, то ругань терминала вполне обоснована. Именно такой пакет должно рассылать любое другое устройство, занимающее тот же МАК, что и наш терминал. Wireshark в руки и разбирайся, кто, почему и зачем ты его так настроил.

Re: БАГИ

MAGNet » Ср окт 16, 2013 6:51 am

Так! Смог-таки расковырять..
Изображение
Лог тоже сохранился, но Достигнут максимальный общий размер ваших вложений.
Хотите, 1864 строки вставлю? :)

Re: БАГИ

MAGNet » Ср окт 16, 2013 5:48 am

aka писал(а): И где лог?
И где скриншот?
Вот только о лога и скриншотах оставалось думать, когда касса в магазине зависла, а там очередь!
Это не лабораторный стенд - это действующий магазин.
Вот всё, чо осталось от лога:

Код: Выделить всё

WTware v.5.1.45

OK. Going to reboot.
Home   WTware diskless client.
Устроит?

К сожалению, единственое, на что хватило ума в панике - это нажать кнопку "Перезагрузка"
..и он-таки перезагрузился

Re: БАГИ

aka » Ср окт 16, 2013 1:10 am

MAGNet писал(а):который находится неизвестно где (vlan), имеет статически прописанный ИП, не настроен и не задействован в принципе. Более того - он находится в другой подсети и пакеты с его маской никак не могли попасть в подсеть терминала.
Гы. Модуль телепатии в втвари работает :)
MAGNet писал(а):терминал отзывался по вебу и выдавал отчеты
И где лог?
MAGNet писал(а):и при попытке запросить лог из консоли вывалилась та же ошибка, что адрес перехвачен другим устройством
И где скриншот?

Re: БАГИ

MAGNet » Вт окт 15, 2013 1:02 pm

Следующий баг
Сегодня вывалился терминал с сообщением, что его IP заняло устройство с mac-адресом таким-то..
Устройство с этим маком в сети есть, но ирония заключается в том, что это вифи-ретранслятор, который находится неизвестно где (vlan), имеет статически прописанный ИП, не настроен и не задействован в принципе. Более того - он находится в другой подсети и пакеты с его маской никак не могли попасть в подсеть терминала.
Разумеется, что никто никаких адресов не перехватывал. Антенна сидела на своем прежнем адресе, терминал отзывался по вебу и выдавал отчеты, но работать отказывался и при попытке запросить лог из консоли вывалилась та же ошибка, что адрес перехвачен другим устройством, хотя этого не было и быть не могло!

Резонный вопрос: почему терминал так решил и на каком основании он разорвал связь, если своего адреса не потерял?! Замечательно пинговался и отвечал через веб-нитерфейс..

Re: БАГИ

MAGNet » Пн окт 14, 2013 11:19 am

Rushmore писал(а):Если свич умный, попробуйте поиграться с настройками flow control, на крайняк попробуйте принудительно выставить скорость на порту 100 мегабит. Если не поможет, попробуйте грузить с http. У меня по http машинки гораздо стабильнее грузятся.
Спасибо, предпочитаю устранять причины, а не следствия.
Была предпринята попытка перепрошивки - тыц
Поцыэнт оказался скорее жив, чем мёртв! Успешно перепрошилось с 1.2.22 на 1.5.43. Всё работает без ошиок! Всем спаибо за участие.

Re: БАГИ

Rushmore » Пн окт 14, 2013 9:08 am

MAGNet писал(а):Склоняюсь я к тому, что нужно "положить на полку" эти говнодевайсы
Если свич умный, попробуйте поиграться с настройками flow control, на крайняк попробуйте принудительно выставить скорость на порту 100 мегабит. Если не поможет, попробуйте грузить с http. У меня по http машинки гораздо стабильнее грузятся.

Re: БАГИ

MAGNet » Пн окт 14, 2013 6:54 am

aka писал(а):Потому что сеть плохая. Пакеты теряются. WTware TFTP отрабатывает эту проблему лучше, чем "tftpd (0.17-18ubuntu2)" - не портит файлы при передаче.
Не стал бы так критично заявлять, просто tftpd "помнит" про старые баги.
Сеть отличная! это косяк прошивки PXE. Intel(R) Boot Agent GE v1.2.22 (c)1995-2004
Мне совершенно не понятно почему в устройстве 2013-го года стоит рошивка 10-ти летней давности :?
Что касается ошибок, то их нет. wtware.pxe грузится нормально и выдает ошибку загрузки ядра. далее вываливается в команднуюстроку. если из командной строки руками дать команду продолжения загрузки, то всё нормально грузится и работает.
Не знаю, почему втварьный софт видит ошибки там, где их нет ((

К слову, встроенные сетевухи имеют пршивки 2007-го года и с ними всё нормально в тех же условиях.
Склоняюсь я к тому, что нужно "положить на полку" эти говнодевайсы, вот только не знаю, как обосновать начальству покупку ещё двух аналогичных, но от другого производителя.. :roll:

Re: БАГИ

aka » Сб окт 12, 2013 1:37 pm

MAGNet писал(а):
  • Почему Intel Pro не не может договориться с wtware-tftp?
Потому что сеть плохая. Пакеты теряются. Протокол TFTP очень плохо переносит потерю пакетов.
MAGNet писал(а):[*]Почему wtware.pxe не хочет грузить kernel со стороннего сервера? Напомню, что после ошибки из командной строк boot: wtware всё проходит на ура.[/list]
Потому что сеть плохая. Пакеты теряются. WTware TFTP отрабатывает эту проблему лучше, чем "tftpd (0.17-18ubuntu2)" - не портит файлы при передаче. Еще вариант - ты влез руками в pxe.cfg и чего-то там испортил.

Можешь вместо wtware.pxe попробовать работать с оригиналом. wtware.pxe это pxelinux.0, pxe.cfg это pxelinux.cfg/default, гугл знает откуда это брать.

Re: БАГИ

MAGNet » Пт окт 11, 2013 3:25 pm

Так, с конфигом разобрался - не все файлы копирнулись.
Остается два вопроса:
  • Почему Intel Pro не не может договориться с wtware-tftp?
  • Почему wtware.pxe не хочет грузить kernel со стороннего сервера? Напомню, что после ошибки из командной строк boot: wtware всё проходит на ура.

Re: БАГИ

MAGNet » Пт окт 11, 2013 3:01 pm

Накатил для теста tftpd (0.17-18ubuntu2). Теперь вот такой расклад:

Код: Выделить всё

Oct 11 18:17:01 WS-MAGNet tftpd[12822]: tftpd: trying to get file: 5.1.45/wtware.pxe
Oct 11 18:17:01 WS-MAGNet tftpd[12822]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12824]: tftpd: trying to get file: 5.1.45/wtware.pxe
Oct 11 18:17:01 WS-MAGNet tftpd[12824]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12827]: tftpd: trying to get file: 5.1.45/d6c42a68-280b-11de-8b0c-0013200b4f9e
Oct 11 18:17:01 WS-MAGNet tftpd[12827]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12829]: tftpd: trying to get file: 5.1.45/01-90-e2-ba-46-35-2c
Oct 11 18:17:01 WS-MAGNet tftpd[12829]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12831]: tftpd: trying to get file: 5.1.45/C0A81566
Oct 11 18:17:01 WS-MAGNet tftpd[12831]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12833]: tftpd: trying to get file: 5.1.45/C0A8156
Oct 11 18:17:01 WS-MAGNet tftpd[12833]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12835]: tftpd: trying to get file: 5.1.45/C0A815
Oct 11 18:17:01 WS-MAGNet tftpd[12835]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12837]: tftpd: trying to get file: 5.1.45/C0A81
Oct 11 18:17:01 WS-MAGNet tftpd[12837]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12839]: tftpd: trying to get file: 5.1.45/C0A8
Oct 11 18:17:01 WS-MAGNet tftpd[12839]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12841]: tftpd: trying to get file: 5.1.45/C0A
Oct 11 18:17:01 WS-MAGNet tftpd[12841]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12843]: tftpd: trying to get file: 5.1.45/C0
Oct 11 18:17:01 WS-MAGNet tftpd[12843]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12845]: tftpd: trying to get file: 5.1.45/C
Oct 11 18:17:01 WS-MAGNet tftpd[12845]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12847]: tftpd: trying to get file: 5.1.45/pxe.cfg
Oct 11 18:17:01 WS-MAGNet tftpd[12847]: tftpd: serving file from /tftpboot
Oct 11 18:17:01 WS-MAGNet tftpd[12849]: tftpd: trying to get file: 5.1.45/packages/kernel
Oct 11 18:17:01 WS-MAGNet tftpd[12849]: tftpd: serving file from /tftpboot
PXE загружает, доходит до ядра и говорит в терминале
Invalid or corrupt kernel image.
boot:
Далее memtest грузит без проблем и wtware тоже без проблем, через командную строку, но не подгружает дефолтный конфиг.
В логах примерно так:

Код: Выделить всё

[initrd] dhcp: server address 192.168.20.3.
[initrd] dhcp: 192.168.21.102/255.255.255.0.
[initrd] dhcp: DNS 192.168.20.3.
[initrd] dhcp: DNS 192.168.20.5.
[initrd] dhcp: domain GELTD.
[initrd] dhcp: TFTP 192.168.21.79.
[initrd] dhcp: boot file (067) 5.1.45/wtware.pxe.
[initrd] TFTP binary "5.1.45/", configs prefix "", using "/" slash.
Send broadcast WTCU discover.
[initrd] TFTP: download file Everyone/list.wtc from 192.168.21.79.
[initrd] It isn't WTware5 TFTP server...
[initrd] tftp error code 1: File not found.
[initrd] TFTP: download file Terminals/90.E2.BA.46.35.2C/config.wtc from 192.168.21.79.
/--- FILE "/tmp/config.wtc" -----------------------
| [BOM]
| user=geltd\kassa1[Кассир]:123qweasd
| clienthostname=WSN-KASSA2
| video=intel(U)
| serial=COM1(usb)
| turnoffmenu=poweroff
| shell=mshta d:\remoteapp\launcher\launcher.hta
| server=192.168.21.100
| connection
\----------------------------------------------------
Ясно, что где-то что-то я не допилил..
Где и что?

Re: БАГИ

MAGNet » Пт окт 11, 2013 11:30 am

если вы допиливали tftp, то ковыряйтесь там. Вот похожая ситуазия.
Кратко:
Error description
We had a problem when our <SYN> packet sent from TPF client was responded with <SYN/ACK> but with totaly different ACK number (AIX box). The <SYN/ACK> ACK number was not <SYN> SEQ + 1.
It was responded by TPF by re-sending original <SYN> packet ignoring previous <SYN/ACK> received. This got to a loop, because the remote side responded with wrong ACK number in <SYN/ACK>.
Basically, if TPF sent a SYN (we are in SYN_SENT state) and receive a SYN/ACK with the wring ACK value, we should reject that SYN/ACK with a RST/ACK. In the current code (at label CTT6RTSN) we end up just discarding the SYN/ACK message in this case. We should be able to use an existing reason code for the RST, like
socket does not exist (branch to label CTT6RTRJ).

SOLUTION:
If TPF receives a SYN/ACK with the wrong acknowledgment number and the socket is still in SYN SENT state, reject the inbound SYN/ACK with a RST. This allows the new connection to come active upon the next retransmission of the SYN by TPF.
Может не совсем оно, но похоже.. Кстати, гугл мне подсказал, что я тут не первый столкнулся с этой проблемой. Ещё года три назад её поднимали, но так и не решили :(

Re: БАГИ

MAGNet » Пт окт 11, 2013 11:06 am

после перемещения девайса в один сегмент с серверомситуация не изменилась:

Код: Выделить всё

14-54-24-0788| [TFTP] 00000000: 5c 35 2e 31 2e 34 35 5c 70 78 65 2e 63 66 67 00
14-54-24-0788| [TFTP] 00000010: 6f 63 74 65 74 00 74 73 69 7a 65 00 30 00 62 6c
14-54-24-0788| [TFTP] 00000020: 6b 73 69 7a 65 00 31 34 30 38 00
14-54-24-0788| [TFTP] Request block size 1408, forced to 1400.
14-54-24-0788| [TFTP] Requests file "5.1.45\pxe.cfg". Tsize is requested, blksize 1400 bytes.
14-54-24-0788| [TFTP] Sending OASK (tsize 192, blksize 1400).
14-54-24-0788| [TFTP] Transfer of file "5.1.45\pxe.cfg" completed.
14-54-24-0788| [TFTP] Connection closed.
14-54-24-0788| [TFTP] Got RRQ, 51 bytes.
14-54-24-0788| [TFTP] 00000000: 5c 35 2e 31 2e 34 35 5c 70 61 63 6b 61 67 65 73
14-54-24-0788| [TFTP] 00000010: 2f 6b 65 72 6e 65 6c 00 6f 63 74 65 74 00 74 73
14-54-24-0788| [TFTP] 00000020: 69 7a 65 00 30 00 62 6c 6b 73 69 7a 65 00 31 34
14-54-24-0788| [TFTP] 00000030: 30 38 00
14-54-24-0788| [TFTP] Request block size 1408, forced to 1400.
14-54-24-0788| [TFTP] Requests file "5.1.45\packages\kernel". Tsize is requested, blksize 1400 bytes.
14-54-24-0788| [TFTP] Sending OASK (tsize 2129264, blksize 1400).
14-54-25-0272| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-25-0833| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-26-0644| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-27-0471| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-28-0579| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-29-0952| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-31-0589| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-33-0524| [TFTP] Incorrect ACK received (expected 23, received 22).
14-54-35-0536| [TFTP] Timeout occured while transfer "5.1.45\wtware.pxe".
14-54-35-0536| [TFTP] Timeout occured while transfer "5.1.45\packages\kernel".
вплоть до:

Код: Выделить всё

14-55-10-0090| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-10-0652| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-11-0463| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-12-0290| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-13-0397| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-14-0770| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-16-0408| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-18-0342| [TFTP] Incorrect ACK received (expected 1738, received 1737).
14-55-20-0355| [TFTP] Timeout occured while transfer "5.1.45\wtware.pxe".
14-55-20-0355| [TFTP] Timeout occured while transfer "5.1.45\packages\initrd".
14-55-21-0572| [TFTP] Transfer of file "5.1.45\packages\initrd" completed.
14-55-21-0572| [TFTP] Connection closed.
Разница лишь в том, что синхронизировались они гораздо быстрее.

Думаю, что имеет смысл пднять сторонний tftp и попробовать на нем. На выходных займусь, если не лень будет :)

Re: БАГИ

MAGNet » Пт окт 11, 2013 10:48 am

у меня сеть тянет гигабит. более того, в том сегменте, где это будет работать все свитчи управляемые и не более 2-х в цепи.
в данной ситуации карта находится в другом сегменте сети на стенде. другие гигабитные девайсы здесь работают нормально.
вопрос в другом, почему ругается tftp? что это за расхождение в единицу между ожидаемым и полученным?
вам, как авторам, это должно сказать намного больше чем мне.

к слову, пришла вторая карта - ситуация та же.
не могу выложить лог, ибо Достигнут максимальный общий размер ваших вложений.
но смею вас заверить - он абсолютно такой же. карта около 2-3 минут пытается договориться с tftp.

Сейчас попробую закинуть стендовую машину в один сегмент с сервером и отпишусь по результатам.

Re: БАГИ

aka » Пт окт 11, 2013 10:23 am

MAGNet писал(а):сразу начались проблемы. стартует минуты две..
В логе ругань в ссамом начале загрузки, когда прошивка сетевой карты грузит первые файлы. Никакой наш код там еще не выполняется. Можно попробовать обновить прошивку, но правильнее чинить сеть. Зачем было покупать гигабитную карту, если твоя сеть все равно не тянет гигабит?

Re: БАГИ

MAGNet » Пт окт 11, 2013 6:14 am

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

сегодня вывалилась другая проблема.
специально под новые лицензии приобрели новые стевые карты Intel® PRO/1000 GT Desktop Adapter. Приехала пока только одна, но с ней сразу начались проблемы. стартует минуты две..
В логе ошибки обмена. Полный лог загрузки прилагается.
WTware_90.E2.BA.3E.D8.1C_2013-10-11_09-47-15.txt
Полный лг загрузки с Intel® PRO/1000 GT Desktop Adapter
(146.94 КБ) 1338 скачиваний
Будет ли проблема со второй картой, скажу на следующей неделе, но чистоты эксперимента не будет, ибо другая партия.
Что это может быть?

зы
ну, и ещё маленькая плюшка не по теме. в админке, в окне лога не работает скроллинг колесиком. мелочь, но приятно :)

Re: БАГИ

aka » Пт окт 11, 2013 1:02 am

MAGNet писал(а):tftp родной, втварный.
Тогда я продолжаю думать про повторное использование IP. Оно так всегда бывает, когда появляется больше одного dhcp.

Re: БАГИ

MAGNet » Чт окт 10, 2013 11:36 am

tftp родной, втварный. слешь роли не играет. это перое, что я сделал - поставил слешь, когда втваря ругнулась. это самый первый лог. после добавления слэша ничего не изменилось, просто те логи не сохранились. сейчас на продакшине эксперименты делать не буду, но дело не в слэше - это точно.
попробую вечером более детально описать ситуацию

Re: БАГИ

aka » Чт окт 10, 2013 9:33 am

MAGNet писал(а):та строчка Send broadcast WTCU discover. ничего не подсказывает?
Ничего не подсказывает.

Вижу что путь в одном случае начинается со слэша, в другом слэша нет. Это может иметь значение для какого-нибудь кривого TFTP. TFTP сервер какой?

Re: БАГИ

MAGNet » Чт окт 10, 2013 7:04 am

вот правильная загрузка. с остановленной wtware-dhcp:

Код: Выделить всё

[initrd] dhcp: server address 192.168.20.3.
[initrd] dhcp: 192.168.20.134/255.255.255.0.
[initrd] dhcp: default gateway 192.168.20.254.
[initrd] dhcp: DNS 192.168.20.3.
[initrd] dhcp: DNS 192.168.20.5.
[initrd] dhcp: domain GELTD.
[initrd] dhcp: TFTP 192.168.20.105.
[initrd] dhcp: boot file (067) \5.1.45\wtware.pxe.
[initrd] TFTP binary "\5.1.45\", configs prefix "\", using "\" slash.
Send broadcast WTCU discover.
[initrd] TFTP: download file \Everyone\list.wtc from 192.168.20.105.
[initrd] WTware TFTP v.5.1.45.
Сравните с неправильной и всё поймете. здесь wtware-dhcp активна.

Код: Выделить всё

[initrd] dhcp: server address 192.168.20.3.
[initrd] dhcp: 192.168.20.134/255.255.255.0.
[initrd] dhcp: default gateway 192.168.20.254.
[initrd] dhcp: DNS 192.168.20.3.
[initrd] dhcp: DNS 192.168.20.5.
[initrd] dhcp: domain GELTD.
[initrd] dhcp: TFTP 192.168.20.105.
[initrd] dhcp: boot file (067) 5.1.45\wtware.pxe.
[initrd] TFTP binary "5.1.45\", configs prefix "", using "\" slash.
Send broadcast WTCU discover.
[initrd] TFTP: download file Everyone\list.wtc from 192.168.20.105.
[initrd] Incorrect TFTP server? Return -1, errno 11.
вот та строчка Send broadcast WTCU discover. ничего не подсказывает?
Активная служба wtware-dhcp перехватывает бродкасты и флудит, моё мнение. Другого объяснения не нахожу.

Re: БАГИ

MAGNet » Чт окт 10, 2013 6:55 am

Prizrak писал(а):Блин, ну тут одно напрашивается:"Пить меньше надо"
не меньше - качественнее :)

Re: БАГИ

aka » Ср окт 09, 2013 12:49 pm

Я ничего не понял. Втварь совершенно точно умеет работать с другими DHCP серверами. Больше всего это похоже на то, что IP 192.168.20.134 используется кем-то еще.

Дай полностью два лога от включения питания и до входа в виндовс или до ошибки. С одного и того же терминала. С нашим dhcp и с ненашим dhcp. И сам убедись, что в обоих случаях терминал получал один и тот же ip.

Re: БАГИ

Prizrak » Ср окт 09, 2013 12:35 pm

Блин, ну тут одно напрашивается:"Пить меньше надо"

Re: БАГИ

MAGNet » Ср окт 09, 2013 12:23 pm

WTware, спасибо.
спасибо, что моя додумался посмотреть на сервере активные службы.
просто интуитивно остановил ваше dhcp.

спасибо интуиции!!

Re: БАГИ

MAGNet » Ср окт 09, 2013 12:20 pm

просто представьте картину:
Девять утра, я с бешеного бодуна пднимаю трубку и слышу: "КАССЫ НЕ РАБТЮТ!!"
..и ещё много всякого..
..а сколько Вам нужно времени, чтоб с похмелья под визги кассиров по удаленке решить эту проблему?

напомню, там очередь и "КАССЫ НЕ РАБТЮТ!!"
..а ты дома с хорошго похмелья.

БАГИ

MAGNet » Ср окт 09, 2013 7:49 am

Давайте поддержим и закрепим эту тему, дабы не пихать свои посты куда попало..
Начнем:

Если Варя установлена с dhcp-сервером то присутствует соответствующая служба, которая в режиме авто и всегда работает.
Если в сети уже есть действующий DHCP-сервер, то выключить встроенный dhcp можно через консоль управления Варей, но это приводит к багу - терминалы перестают загружаться.

Вот кусок лога:

Код: Выделить всё

[initrd] dhcp: server address 192.168.20.3.
[initrd] dhcp: 192.168.20.134/255.255.255.0.
[initrd] dhcp: default gateway 192.168.20.254.
[initrd] dhcp: DNS 192.168.20.3.
[initrd] dhcp: DNS 192.168.20.5.
[initrd] dhcp: domain GELTD.
[initrd] dhcp: TFTP 192.168.20.105.
[initrd] dhcp: boot file (067) 5.1.45\wtware.pxe.
[initrd] TFTP binary "5.1.45\", configs prefix "", using "\" slash.
Send broadcast WTCU discover.
[initrd] TFTP: download file Everyone\list.wtc from 192.168.20.105.
[initrd] Incorrect TFTP server? Return -1, errno 11.
[initrd] tftp.cpp ( 538), _tftp: -- ERROR -- INTERNAL ERROR. Please, contact WTware tech support.
[initrd] TFTP: download file Terminals\00.1C.C0.CA.24.2F\config.wtc from 192.168.20.105.
kotenok-httpd.cpp ( 268), _writeFile: -- ERROR -- HTTP: file /etc/config.compiled not found.
[initrd] tftp.cpp ( 538), _tftp: -- ERROR -- INTERNAL ERROR. Please, contact WTware tech support.
[initrd] TFTP: download file Terminals\00.1C.C0.CA.24.2F.wtc from 192.168.20.105.
[initrd] tftp.cpp ( 538), _tftp: -- ERROR -- INTERNAL ERROR. Please, contact WTware tech support.
[initrd] TFTP: download file Terminals\default.wtc from 192.168.20.105.
[initrd] tftp.cpp ( 538), _tftp: -- ERROR -- INTERNAL ERROR. Please, contact WTware tech support.
[initrd] TFTP: download file Everyone\all.wtc from 192.168.20.105.
[initrd] tftp.cpp ( 538), _tftp: -- ERROR -- INTERNAL ERROR. Please, contact WTware tech support.
Ошибка пропадает после остановки службы WTware DHCP.
Почему так?

Вернуться к началу