yanchick.A

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

Самопал.

Там же всё просто: 1 табличка, 1 пост запрос на оплату, 1 пост запрос на проверку. Есть код, но на питоне. И как обычно может всплыть куча нюансов по биллингу.

Такого у нас не было, но такие грабли решают в индивидуальном порядке комерсы. В идеале типовые несостыковки в реглаемент, всё что вне его на личные разборки первых лиц. Логи само собой, но и они бывают не спасают. В идеале еще камера где-то рядом, а лучше над. Глючит до сих пор, преимущественно правда в последний месяц-два до сдачи ЭКЛЗ. НО и за самой ЭКЛЗ надо следить, в плане чтобы вовремя его поменяли, а не получили кучу претензий на неработающий терминал(ибо если с фискальником/эклз проблемы - блокировать его нафик)

Делали такое мы. Правда запустили один терминал, но зкладывали вопросы расширения. Поток был приличный до того как открыли кассу. Технически проблем нет простецкий драйвер на купюроприемник и проприетарный драйвер на фискальник. Терминал лучше собирать самому - выйдет дешевле чем брать готовый. Мы еще думали карточки внедрить, но воз и ныне там. Касательно стыка с биллингом - скрипты творят и не такие чудеса. Если резюмировать - технически проблем создать терминал нет. Но есть целый ряд орг. и финансовых вопросов. Такие как - инкасация и разборки по соотвествие суммы в стекере и з-отчете. Особенно приколы со съеденной купюрой и пропавшими платежами/деньгами. Лечится регламентами. Финансовые вопросы были далеки от меня, так что проконсультировать не смогу. По остальным - велком.

Можно копию таблички на yan@yanchick.org?

Всем привет. Есть микротик. На него поднимается PPTP сессия. До определенного момента всё, хоть и с косяками, работало. Косяк заключался в том что сессия в опредленный момент отваливалась, но смогла подниматься только после перезагрузки роутера. Однако намедне сессия вообще перестала подниматься. При попытки коннекта в логах видно вот чего: echo: pptp,ppp,info <pptp-0>: waiting for call... [admin@MikroTik] > echo: pptp,ppp,debug <1.1.1.1>: LCP lowerup [admink@MikroTik] > (14 messages discarded) echo: pptp,ppp,debug,packet <1.1.1.1>: rcvd LCP ConfAck id=0x1 echo: pptp,ppp,debug,packet <mru 1460> echo: pptp,ppp,debug,packet <magic 0x6a0fce5a> echo: pptp,ppp,debug,packet <auth pap> echo: pptp,ppp,debug,packet <1.1.1.1>: rcvd LCP ConfReq id=0x2 echo: pptp,ppp,debug,packet <magic 0xd7ca883c> echo: pptp,ppp,debug,packet <1.1.1.1>: sent LCP ConfAck id=0x2 echo: pptp,ppp,debug,packet <magic 0xd7ca883c> echo: pptp,ppp,debug <1.1.1.1>: LCP opened echo: pptp,ppp,debug,packet <1.1.1.1>: rcvd PAP AuthReq id=0x1 echo: pptp,ppp,debug,packet <user USER> echo: pptp,ppp,debug,packet <password passsword> [admin@MikroTik] > (20 messages discarded) echo: pptp,ppp,debug <1.1.1.1>: BCP down event in starting state echo: pptp,ppp,debug <1.1.1.1>: IPCP lowerdown echo: pptp,ppp,debug <1.1.1.1>: IPV6CP lowerdown echo: pptp,ppp,debug <1.1.1.1>: IPV6CP down event in starting state echo: pptp,ppp,debug <1.1.1.1>: MPLSCP lowerdown echo: pptp,ppp,debug <1.1.1.1>: MPLSCP down event in starting state echo: pptp,ppp,debug,packet <1.1.1.1>: sent LCP TermAck id=0x3 echo: pptp,ppp,debug <1.1.1.1>: LCP lowerdown echo: pptp,ppp,info <pptp-0>: terminating... echo: pptp,ppp,debug <1.1.1.1>: LCP lowerdown echo: pptp,ppp,debug <1.1.1.1>: LCP down event in starting state echo: pptp,ppp,info <pptp-0>: disconnected Настройка профиля: 1 name="PPTP-IN" local-address=10.180.250.31 remote-address=pptp remote-ipv6-prefix-pool=(unknown) use-ipv6=no use-mpls=no use-compression=no use-vj-compression=no use-encryption=no only-one=no change-tcp-mss=yes dns-server=10.180.250.30 Настройка клиента 2 USER any password PPTP-IN [yanchick@MikroTik] /interface> pptp-server server print enabled: yes max-mtu: 1460 max-mru: 1460 mrru: disabled authentication: pap keepalive-timeout: 30 default-profile: PPTP-IN Вопрос. Почему у меня не поднимается сейчас сессия? Почему у меня могли быть проблемы с запуском сессии до перезагрузки? Заранее благодарен. UPD побывал играться с параметрами аутентификации, не помогло.

Доброго времени суток всем. В локальной сети скалдывается ситуация что на магистральных(транковых) портах домовых коммутаторов появляется очень много Drop Pkts. Причем замечено что они преимущественно появляются на порту с приходящим линком. После чистки в течении суток - полутора количество пакетов снова получается много(>5000). В отделе складывается мнение что проблемы в физике, но лично мне кажется что проблема в чём-то другом. Сам Dlink по этому поводу пишет следующее: 1) Input buffer full - переполнение входного буфера на порту. 2) Packets denied by ACL - пакеты отброшенные ACL. 3) VLAN ingress checking - проверка по VLAN на входе. ACL-ки отпадают т.к. на этои порту нет и никогда не было листов. Меня интересует что может скрываться за пунктом 1) и 3). И вообще вопрос надо ли так сильно бороться за отсутствие Drop Pkts на транковых портах коммутатора?