BiTel

Не удается создание сессии по наличию трафика.

В настройках типа сервиса указано "Тип инициации сессии: по трафику" (см. вложение)



Netflow на сервер поступает.

Что еще надо настроить, чтобы сессия создавалась по наличию трафика?

Устройство-источник в дереве устройств заведено?
В директории, куда сохраняются flow-логи, появляются новые файлы?

Как указан сервис договора, привязан к этому устройству-источнику?

Устройство-источник в дереве устройств заведено?
Да, заведено.

В директории, куда сохраняются flow-логи, появляются новые файлы?
Появляются.

Как указан сервис договора, привязан к этому устройству-источнику?
Сервис договора привязан к коммутатору, который является дочерним устройством для устройства-источника:





NAT-SERVER-2 - это устройство, с которого приходит netflow
В Конфигурации коммутатора ELTEX прописали:



Нам надо, чтобы с сервисом был связан именно коммутатор, так как мы используем опцию DHCP 82.

На сервисе прописан статический IP-адрес/диапазон/подсеть?
DHCP 82 и инициация сессии "по трафику" - это немного разные вещи.
"по трафику" - это когда мы назначаем абоненту статический адрес/подсеть/диапазон или интерфейс flow-агента и по появлению подходящий flow-записей в биллинге появляется сессия.
"по сигналу" - это когда сессия начинается в биллинге по RADIUS-пакету или по DHCP-пакету. Таким сессиям может быть выдан динамический адрес, а также "псевдо"-статический (биллинг по RADIUS или DHCP всегда выдает один и тот же адрес или адреса из одного и того же диапазона). Такие сессии также могут быть тарифицированы по Netflow/sFlow - для этого достаточно привязки flow-агента flow.agent.link=3:-1


В Вашем случае нужно либо указать статический адрес для этого сервиса и просто тарифицировать по Netflow, либо настраивать под DHCP82, указав инициация "по сигналу", а привязка Netflow будет уже к адресу, который получила сессия.


Попробуйте в InetAccounting/log4j-accounting.xml в конце поменять INFO на TRACE и посмотреть, что пишет, когда получает flow-запись, которая должна привязаться к этому сервису договора.

Понятно.

Мы поменяли настройки инициации сессии, сделали "по сигналу" DHCP.
При включенном сервисе сессия инициируется нормально.

Но при этом наблюдаем следующую проблему: если сессия инициируется при заблокированном (например, за неуплату) сервисе, то сессия стартует в состоянии "Отключено".
Затем если сервис разблокируется, то в файле лога connection.log сервиса BGInetAccounting мы видим постоянные попытки включить сессию:

03-10/15:53:25 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Sending event to enable session...
03-10/15:53:45 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.
03-10/15:53:45 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Already sent event to enable session.
03-10/15:54:05 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.
03-10/15:54:05 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Sending event to enable session...
03-10/15:54:25 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.
03-10/15:54:25 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Already sent event to enable session.
03-10/15:54:45 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.
03-10/15:54:45 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Already sent event to enable session.
03-10/15:55:05 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.
03-10/15:55:05 INFO [accwrkr-1-p-10-t-1] connection - 63:63 Already sent event to enable session.
03-10/15:55:25 INFO [accwrkr-1-p-10-t-1] connection - 63:63 inetServ[id=1] is active.

но при этом сессия остается в состоянии "Отключено", несмотря на то, что сервис заблокирован.



Подскажите, пожалуйста, как решить эту проблему.

Добавление: Аналогично, если сессия инициируется при включенном сервисе, а потом сервис блокируется, то сессия не переходит в состояние "отключено", а в логах connection.log появляются ошибки:


03-10/16:14:30 INFO [ActiveMQ Session Task] connection - 64:64 Register ip: 10.15.8.252
03-10/16:14:40 INFO [accwrkr-3-p-12-t-1] connection - 63:63 Finish event connection by sessionFinishTimeout
03-10/16:14:40 INFO [accwrkr-3-p-12-t-1] connection - 63:63 Finishing call session with lastActive=Thu Mar 10 16:14:20 MSK 2016
03-10/16:14:40 INFO [accwrkr-3-p-12-t-1] connection - 63:63 Unregister ip: 10.15.8.82
03-10/16:15:25 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12
03-10/16:15:25 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Sending event to stop session...
03-10/16:15:35 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12
03-10/16:15:35 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Already sent event to stop session.
03-10/16:15:45 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12
03-10/16:15:45 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Already sent event to stop session.
03-10/16:15:55 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12
03-10/16:15:55 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Sending event to stop session...
03-10/16:16:05 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12
03-10/16:16:05 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Already sent event to stop session.
03-10/16:16:15 INFO [accwrkr-1-p-10-t-1] connection - 64:64 Found error 12

rootDeviceId указан правильный в inet-access.xml и inet-accounting.xml (ID корневого устройства)?
accounting.deviceTypeId= в конфигурации модуля указан правильный (ID типа корневого устройства)?

Если да, то нужно смотреть логи InetAccess - он должен получать задания на сброс/отключение сессии - возможно не может выполнить (зависит от установленного обработчика активации сервисов, например, не может подключиться к коммутатору по telnet/ssh).

rootDeviceId указан правильный в inet-access.xml и inet-accounting.xml (ID корневого устройства)?

да.

accounting.deviceTypeId= в конфигурации модуля указан правильный (ID типа корневого устройства)?

Здесь вопрос: я правильно понимаю, что надо указывать этот параметр равным id типа корневого устройства, которое задано вот здесь:



То есть в нашем случае accounting.deviceTypeIds=1 ?

Да.

При этом этого параметра не должно быть указано в inet-access.xml.

Потом перезапустите InetAccess и уже надо будет смотреть, что в его логах, когда появляется в необходимости переключить состояние сессии на подключена/отключена.

Проблема в том, что когда я ставлю accounting.deviceTypeIds=1 то перестает работать DHCP.

Появляется ошибка:

03-10/20:36:40 INFO [dhcpLstnr-p-7-t-4] AbstractInetDhcpProcessor2 - REQUEST:
Message type: BOOT_REQUEST
Dhcp message type: DHCP Discover{1}
htype: 1, hlen: 6, hops: 1
xid: 1888323387, secs: 3072, flags: 0
Client IP: 0.0.0.0
Your IP: 0.0.0.0
Server IP: 0.0.0.0
Relay IP: 192.168.21.55
Client MAC: {EC9A74549C46}
{61}={01EC9A74549C46}
Requested IP Address{50}=10.15.8.10
Host name{12}={onduty1}
{60}={4D53465420352E30}
Parameter request list{55}={1, 15, 3, 6, 44, 46, 47, 31, 33, 121, -7, 43}
Agent information{82}=
sub{1}={000408070109}
sub{2}={0006A8F94B78ED80}

03-10/20:36:40 DEBUG [dhcpLstnr-p-7-t-4] AbstractInetDhcpProcessor2 - OP_BOOT_REQUEST
03-10/20:36:40 DEBUG [dhcpLstnr-p-7-t-4] AbstractInetDhcpProcessor2 - Found device by giaddr id=4
03-10/20:36:40 DEBUG [dhcpLstnr-p-7-t-4] InetDhcpProcessor2 - DHCP_DISCOVER
03-10/20:36:40 DEBUG [dhcpLstnr-p-7-t-4] InetDhcpProcessor2 - request.giaddr= 192.168.21.55, clientAddress=/192.168.21.55:68
03-10/20:36:40 INFO [dhcpLstnr-p-7-t-4] InetDhcpDevice - Search serv on deviceId: 4; 1; interfaceId: 9
03-10/20:36:40 INFO [dhcpLstnr-p-7-t-4] InetDhcpProcessor2 - InetServ found: ContractId: 9; status: 0; servId: 1
п≤пҐя┌п╣я─пҐп╣я┌ (п≤пҐя┌п╣я─я└п╣п╧я│ 9)
Options [5:04.03.2016-01.01.1970; ] TariffModuleTreeSet [5:03.03.2016-Б─і; ]
Device state: 0; optionSet:5
03-10/20:36:40 INFO [dhcpLstnr-p-7-t-4] InetDhcpProcessor2 - Stopping session with deviceState=1 and wantDeviceState=0
03-10/20:36:46 ERROR [dhcpLstnr-p-7-t-4] InetDhcpProcessor2 - Timeout exceed!
ru.bitel.bgbilling.common.BGException: Timeout exceed!
at ru.bitel.bgbilling.modules.inet.access.InetConnectionManager.accountingStop(InetConnectionManager.java:638)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.dhcpRequestUpdate(InetDhcpProcessor2.java:442)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestRaw0(InetDhcpProcessor2.java:642)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestRaw(InetDhcpProcessor2.java:273)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestImpl(InetDhcpProcessor2.java:117)
at ru.bitel.bgbilling.modules.inet.dhcp.AbstractInetDhcpProcessor2.processOption82Request(AbstractInetDhcpProcessor2.java:352)
at ru.bitel.bgbilling.modules.inet.dhcp.AbstractInetDhcpProcessor2.processRequest(AbstractInetDhcpProcessor2.java:184)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processRequest(InetDhcpProcessor2.java:61)
at ru.bitel.bgbilling.kernel.network.dhcp.DhcpListenerWorker.runImpl(DhcpListenerWorker.java:90)
at ru.bitel.common.worker.WorkerTask.run(WorkerTask.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:46)


Когда я меняю значение accounting.deviceTypeIds на любое другое - то DHCP работает без проблем.

Пробовали поставить и перезапустить InetAccounting тоже?

Попробовал. Ситуация не изменилась:


03-10/20:48:37 INFO [dhcpLstnr-p-7-t-7] AbstractInetDhcpProcessor2 - REQUEST:
Message type: BOOT_REQUEST
Dhcp message type: DHCP Discover{1}
htype: 1, hlen: 6, hops: 1
xid: 454481188, secs: 3072, flags: -32768
Client IP: 0.0.0.0
Your IP: 0.0.0.0
Server IP: 0.0.0.0
Relay IP: 192.168.21.55
Client MAC: {EC9A74549C46}
{61}={01EC9A74549C46}
Requested IP Address{50}=10.15.8.10
Host name{12}={onduty1}
{60}={4D53465420352E30}
Parameter request list{55}={1, 15, 3, 6, 44, 46, 47, 31, 33, 121, -7, 43}
Agent information{82}=
sub{1}={000408070109}
sub{2}={0006A8F94B78ED80}

03-10/20:48:37 DEBUG [dhcpLstnr-p-7-t-7] AbstractInetDhcpProcessor2 - OP_BOOT_REQUEST
03-10/20:48:37 DEBUG [dhcpLstnr-p-7-t-7] AbstractInetDhcpProcessor2 - Found device by giaddr id=4
03-10/20:48:37 DEBUG [dhcpLstnr-p-7-t-7] InetDhcpProcessor2 - DHCP_DISCOVER
03-10/20:48:37 DEBUG [dhcpLstnr-p-7-t-7] InetDhcpProcessor2 - request.giaddr= 192.168.21.55, clientAddress=/192.168.21.55:68
03-10/20:48:37 INFO [dhcpLstnr-p-7-t-7] InetDhcpDevice - Search serv on deviceId: 4; 1; interfaceId: 9
03-10/20:48:37 INFO [dhcpLstnr-p-7-t-7] InetDhcpProcessor2 - InetServ found: ContractId: 9; status: 0; servId: 1
п≤пҐя┌п╣я─пҐп╣я┌ (п≤пҐя┌п╣я─я└п╣п╧я│ 9)
Options [5:04.03.2016-01.01.1970; ] TariffModuleTreeSet [5:03.03.2016-Б─і; ]
Device state: 0; optionSet:5
03-10/20:48:37 INFO [dhcpLstnr-p-7-t-7] InetDhcpProcessor2 - Stopping session with deviceState=1 and wantDeviceState=0
03-10/20:48:42 ERROR [dhcpLstnr-p-7-t-7] InetDhcpProcessor2 - Timeout exceed!
ru.bitel.bgbilling.common.BGException: Timeout exceed!
at ru.bitel.bgbilling.modules.inet.access.InetConnectionManager.accountingStop(InetConnectionManager.java:638)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.dhcpRequestUpdate(InetDhcpProcessor2.java:442)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestRaw0(InetDhcpProcessor2.java:642)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestRaw(InetDhcpProcessor2.java:273)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processOption82RequestImpl(InetDhcpProcessor2.java:117)
at ru.bitel.bgbilling.modules.inet.dhcp.AbstractInetDhcpProcessor2.processOption82Request(AbstractInetDhcpProcessor2.java:352)
at ru.bitel.bgbilling.modules.inet.dhcp.AbstractInetDhcpProcessor2.processRequest(AbstractInetDhcpProcessor2.java:184)
at ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2.processRequest(InetDhcpProcessor2.java:61)
at ru.bitel.bgbilling.kernel.network.dhcp.DhcpListenerWorker.runImpl(DhcpListenerWorker.java:90)
at ru.bitel.common.worker.WorkerTask.run(WorkerTask.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:46)

Можете дать доступ?

К серверу по SSH?

Да.

Информацию о доступе отправил в лс.

Возможно потому что в дереве NAT-SERVER указан тоже как Access+Accounting.
Попробуйте указать у него тип Папка или создайте отдельный тип устройства.

Сменил у NAT-SERVER тип на ПАПКА, перезагрузил InetAccess и InetAccounting, теперь DHCP работает при параметре accounting.deviceTypeIds=1 в конфигурации модуля Inet.

Проблема с включением-отключением сессий осталась: при включении-выключении сервиса сессия не меняет свое состояние.

Вот connection.log из модуля InetAccess:


03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorSet - Connecting to device
03-11/14:17:35 DEBUG [sa-p-10-t-24] AcknowledgeConsumer - Caught BGBillingServer:Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 4; pluginId: no; cid: 9; scid: -1; userId: 0; deviceId: 4; inetServId: 1; connectionId: 0; state: 1; accessCode: 0; timestamp: 1457695055773
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Do task deviceId: 4; Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 4; pluginId: no; cid: 9; scid: -1; userId: 0; deviceId: 4; inetServId: 1; connectionId: 0; state: 1; accessCode: 0; timestamp: 1457695055773
03-11/14:17:35 DEBUG [sa-p-10-t-24] InetAccountingPeriodList - Create:
AccountingPeriod: 2: 01.02.2016 00:00:00.0 - 31.03.2030 00:00:00.999
03-11/14:17:35 INFO [sa-p-10-t-24] InetApplication - TariffOptionMap: {}
03-11/14:17:35 INFO [sa-p-10-t-24] InetApplication - inetServ[id=1] balance ok: 1.78 [0]
03-11/14:17:35 INFO [sa-p-10-t-24] InetApplication - OptionSet: [5]
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Command result event: ServiceActivatorEvent type=2; inetServId: 1; call: true; oldState: 0; newState: 1; oldOptionSet: 5; newOptionSet: 5
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Processing deviceId:4; command ServiceActivatorEvent type=2; inetServId: 1; call: true; oldState: 0; newState: 1; oldOptionSet: 5; newOptionSet: 5
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorSet - Invoking serviceModify
03-11/14:17:35 INFO [sa-p-10-t-24] AbstractTerminalServiceActivator - serviceModify
03-11/14:17:35 INFO [sa-p-10-t-24] AbstractTerminalServiceActivator - serviceEnable
03-11/14:17:35 INFO [sa-p-10-t-24] ExecServiceActivator - [ELTEX MES1124M: a8f94b78ed80 [192.168.21.55]] execute: /usr/local/BGScripts/testscript.sh SERV_ENABLE [IpAddress:null] 192.168.21.55 9 9 1 п≤пҐя┌п╣я─пҐп╣я┌ (п≤пҐя┌п╣я─я└п╣п╧я│ 9) Internet (Interfeis 9) 9 #1001 192.168.21.55 4 null null
03-11/14:17:35 INFO [sa-p-10-t-24] ExecServiceActivator -
03-11/14:17:35 INFO [sa-p-10-t-24] AbstractTerminalServiceActivator - switchOptions
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Process event type[2] result=true
03-11/14:17:35 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Changing InetServ:1 state and/or options
03-11/14:17:40 INFO [sa-p-10-t-24] ServiceActivatorSet - Disconnecting from device
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorSet - Connecting to device
03-11/14:17:42 DEBUG [sa-p-10-t-24] AcknowledgeConsumer - Caught BGInetAccounting:Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 4; pluginId: no; cid: 9; scid: -1; userId: 0; deviceId: 4; inetServId: 1; connectionId: 74; state: 1; accessCode: 0; timestamp: 1457695062374
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Do task deviceId: 4; Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 4; pluginId: no; cid: 9; scid: -1; userId: 0; deviceId: 4; inetServId: 1; connectionId: 74; state: 1; accessCode: 0; timestamp: 1457695062374
03-11/14:17:42 INFO [sa-p-10-t-24] InetApplication - TariffOptionMap: {}
03-11/14:17:42 INFO [sa-p-10-t-24] InetApplication - OptionSet: [5]
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Command result event: ServiceActivatorEvent type=2; inetServId: 1; call: true; oldState: 0; newState: 1; oldOptionSet: 5; newOptionSet: 5
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Processing deviceId:4; command ServiceActivatorEvent type=2; inetServId: 1; call: true; oldState: 0; newState: 1; oldOptionSet: 5; newOptionSet: 5
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorSet - Invoking connectionModify
03-11/14:17:42 INFO [sa-p-10-t-24] AbstractTerminalServiceActivator - connectionModify
03-11/14:17:42 INFO [sa-p-10-t-24] ExecServiceActivator - [ELTEX MES1124M: a8f94b78ed80 [192.168.21.55]] execute: /usr/local/BGScripts/testscript.sh CONNECTION_ENABLE 10.15.8.112 192.168.21.55 9 9 1 п≤пҐя┌п╣я─пҐп╣я┌ (п≤пҐя┌п╣я─я└п╣п╧я│ 9) Internet (Interfeis 9) 9 #1001 192.168.21.55 4 10.15.8.1 255.255.254.0
03-11/14:17:42 INFO [sa-p-10-t-24] ExecServiceActivator -
03-11/14:17:42 INFO [sa-p-10-t-24] AbstractTerminalServiceActivator - switchOptions
03-11/14:17:42 INFO [sa-p-10-t-24] ServiceActivatorDeviceWorker - Process event type[2] result=true
03-11/14:17:47 INFO [sa-p-10-t-24] ServiceActivatorSet - Disconnecting from device

При включении сервиса у нас работает скрипт testscript.sh, который вызывается обработчиком активации сервисов ExecServiceActivator.
Сначала срабатывает команда sa.command.serv.enable, затем sa.command.connection.enable, ошибок вроде нет, но состояние сервиса не меняется.

В connection.log модуля InetAccounting при этом постоянно пишется следующее:

03-11/14:17:42 INFO [accwrkr-1-p-10-t-2] connection - 74:74 inetServ[id=1] is active.
03-11/14:17:42 INFO [accwrkr-1-p-10-t-2] connection - 74:74 Sending event to enable session...
03-11/14:17:52 INFO [accwrkr-1-p-10-t-1] connection - 74:74 inetServ[id=1] is active.
03-11/14:17:52 INFO [accwrkr-1-p-10-t-1] connection - 74:74 Already sent event to enable session.
03-11/14:18:02 INFO [accwrkr-1-p-10-t-1] connection - 74:74 inetServ[id=1] is active.
03-11/14:18:02 INFO [accwrkr-1-p-10-t-1] connection - 74:74 Already sent event to enable session.
03-11/14:18:12 INFO [accwrkr-1-p-10-t-1] connection - 74:74 inetServ[id=1] is active.
03-11/14:18:12 INFO [accwrkr-1-p-10-t-1] connection - 74:74 Already sent event to enable session.
03-11/14:18:22 INFO [accwrkr-1-p-10-t-1] connection - 74:74 inetServ[id=1] is active.
03-11/14:18:22 INFO [accwrkr-1-p-10-t-1] connection - 74:74 Already sent event to enable session.
03-11/14:18:32 INFO [accwrkr-1-p-10-t-2] connection - 74:74 inetServ[id=1] is active.

Проблема решена.
В конфиге типа устройства надо было прописать:

sa.command.connection.stateModify=1

Я должен был сразу это предположить, но совсем из головы вылетело, пока другими подсистемами занимаюсь.
Выделили эту часть про сессии в документации в желтый блок.