Содержит ли кадр пакета информацию об учетной записи на ПК-отправителе?

Question

[PinapplePizzaWithOlives]

Более месяца назад появилась странная проблема в виде задержки печати у МФУ xerox workcentre 3335/45. При этом МФУ Pantum работают идеально. В учреждении у подсети нет продвинутой логики: это просто несколько коммутаторов, соединенных в цепь. К ним подключаются все устройства, после чего эта цепь подключается к Випнет координатору (управляется другим учреждением). Долго ломал голову над проблемой: и коммутаторы менял, и в настройках мфу копался, и трафик мониторил, и ACL правила для портов в веб интерфейсе коммутаторов задавал. Всё было безрезультатно. Даже триггер проблемы не мог установить.

Недавно обнаружил, что при отсутствии доступа к открытой сети у ПК, с которого отправляется запрос на печать, задержки нет. Стал копать в этом направлении. Далее ситуация становится еще интереснее: триггером задержки на ксероксах оказались... доменные учетные записи сотрудников. То есть печать с одного и того же компа может быть с задержкой (доменная учетка), а может быть моментальной (локальная учетка). Почему? Так и не понял. В качестве временного решения создал на ПК сотрудников с ксероксами локальные учетные записи и подключил к ним все необходимые сетевые ресурсы. Поскольку с точки зрения безопасности решение откровенно так себе, проблему то нужно добить.

Содержит ли в себе кадр пакета какую-либо информацию об учетной записи, которая была активна в момент отправки пакета? Погуглив, ничего не нашел. Знакомые тоже подобным не занимались.

Comments

[Ziptar]

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

Випнет координатору

Ну или где-то тут

[MaxKozlov]

Вы не написали, как именно у вас принтеры подключены.

Было бы логично их по ethernet подключать, но судя по "создал на ПК сотрудников с ксероксами" они подключены локально через usb.
То есть, фактически, печатают на расшареный на соседнем компе принтер. То есть включается "проблема прав". Видимо есть задержки в этой области. Локальные учётки == everyone, доменные - вопрос к домену.

Я бы в качестве постоянного решения подсоединил принтеры по ethernet и дал таки печатать по ip, если у вас не стоит задачи кому-то иметь принтер в настройках, но запрещать печатать.

[Zerg89]

Скорее всего происходит проверка прав доступа к принтерам в ad и из-за этого задержка, копайте в эту сторону

[alzneo]

Добавлю к комментарию MaxKozlov:
Если принтеры таки были подключены по сети, то проверьте по какому протоколу - классический ли это tcp/ip порт или wsd. Реализация последнего у производителей мфу хромает на обе ноги. Достаточно в одном сегменте появиться двум-трём одинаковым устройствам, как то одно, то другое перестаёт работать. Может, это Ваш случай.

Answer 1

[AntHTML]

На уровне сети сведения об учетке не содержатся, на уровне драйверов принтера - обычно передаются, чтобы на экране видеть от кого пришло задание и в некоторые журналы внутри принтера тоже попадает, также в таких мфушках может учавствовать в функционале "безопасной печати".
Но причины задержек нужно копать в другом, как сказал Ziptar вполне возможно что гдето что-то затрагивают GPO или ограниченная пользовательская учетка (попробывать закинуть доменного пользователя в локалиную группу администраторы, попробывать из под другой доменной учетки), также покапать насчет версий драйверов и протоколов PS/PCL, так-же не исключаю несколько последних обновлений Вынь10 попивших кровушки с печатью. А может и какой Стахановец подкидывает

Answer 2

[Максим Корнеев]

Что такое кадр сети? Какой протокол? Кадр в FC может содержать много информации. Кадр езернета - нет. Вы зачем задаёте вопрос словами которые не понимаете?

Answer 3

[rPman]

вы пробовали ИИ спросить?

anthropic:claude sonnet 4 - предложил что на принтере настроен внешний dns сервер, и он пытается доменного пользователя через внешний dns резолвить, вот и тормозит, предлагается вручную настроить на локальный dns сервер

openai:gpt-4.1 - проблемы с авторизацией (посмотреть по логам в момент медленной печати ошибки ldap), внешний dns, еще можно принудительно указать standart tcp в настройках порта принтера на машине, покопаться в GPO связанных с печатью, еще вариант указать политику always trust для autoprint (говорит что обычная проблема для неподписанных майкрософтом драйверов после win10)

остальные тоже это посоветовали, в частности standart tcp должен решить а то автоматом там будет wsd-xxx, отключить snmp (в настройках порта отключить 'Состояние SNMP разрешено'), еще можно отключить 'Двусторонний обмен данными'... само собой поискать аутентификацию ldap на самом принтере и отключить
...

Отпишитесь, на сколько это поможет, жуть как интересно как с этим ИИ справился.

spoiler

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

Answer 4

[PjaniyAdmin]

Очень похоже что у кого-то есть проблема с днс или контроллером. А ещё такое иногда бывает когда один из контроллеров помер.
Логи винды и принтера смотрели? Днс на контроллере, отрабатывает? (Не помню только юзает ли АД обратную зону, по идее должна). Конфигурация АД доступна?

Answer 5

[ValdikSS]

На принтер передаётся информация об учётке, с которой отправлено задание на печать. И у некоторых принтеров бывают проблемы с обратным слешем, который характерен для Windows-домена.
https://github.com/OpenPrinting/cups/issues/1145

Либо же принтер пытается IP разрезолвить в DNS-имя, как предположили ранее.