none
Не передается опция 43 для телефонов Lync RRS feed

  • Вопрос

  • Друзья, помогите.

    Решил сменить DHCP пул,  вернее маску, для этого пришлось снести весь пул, завести все заново.

    Завел, и теперь телефоны напрочь отказываются получать OPTION 43,

    Телефоны у которых не протухла аренда исправно запрашивают нужные опции

    Option: (55) Parameter Request List

    120 = SIP Servers [TODO]

    43 = Vendor-Specific Information

    Option: (t=60,l=12) Vendor class identifier = "MS-UC-Client"

    И передают идентификатор MS-UC-Client.

    А вот которые я перезагрузил, передают идентификатор Option: (t=60,l=11) Vendor class identifier = "CPE-OCPHONE" и запрашивают только дефолт гейтвей, DNS и прочую лабуду.

    В чем может быть проблема??


    Ни что не вечно под луной...

    16 августа 2012 г. 8:12

Ответы

  • Вообщем все оказалось гораздо тривиальней! Я проводил анализ с помощью wireshark и фильтра bootp, и не видел что происходит помимо запросов dhcp. Я видел что телефон благополучно находил свой голосовой vlan , делал запрос на получении ip адреса, вместе с котором получал еще и адреса ntp серверов, фактически адреса dc, которые были недоступны! Не спрашивайте почему и как, виновные уже найдены! Просто что мне удалось выяснить благодаря этому, так это то что телефон не делает запрос dhcp inform для запроса опций 43, 120 до тех пор пока не проведет синхронизацию времени с ntp серверами или пока не истечет какой то таймер, равный приблизительно 180 секундам!  После этого запрос dhcp inform всегда осуществляется, однако он уже не имеет никакого значения если синхронизация времени оказалась неудачной . Ssl handshake уже будет неудачным. Еще один важный момент который может пригодится так это то что при сбросе в factory defaults , телефоны не смогли синхронизироваться с контроллерами домена, так как первичный timestamp был очень большой, телефоны выставляли в запросе 2010 год, подозреваю дата  их выпуска. И для успешной синхронизации в этом случае по любому требовалась дополнительная настройка.

    Установка минимальной положительной и отрицательной коррекции Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]

    "MaxPosPhaseCorrection"=dword:FFFFFFFF

    "MaxNegPhaseCorrection"=dword:FFFFFFFF

    Я поднял на freebsd свой ntp  и засинхрил телефоны оттуда, и все зашуршало как надо!

    А dhcp pool  и изменения в нем никакой роли и не играли!  


    Ни что не вечно под луной...



    • Изменено Nikita Sokolov 20 августа 2012 г. 8:24
    • Помечено в качестве ответа Yuriy Lenchenkov 30 августа 2012 г. 11:35
    20 августа 2012 г. 8:15

Все ответы

  • На свитчах запущен LLDP.

    Вот лог с проблемного Polycom CX500

    Как видно нет запроса опций 43 и 120. Вопрос - почему???

    Вот ответ сервера



    Ни что не вечно под луной...




    16 августа 2012 г. 8:14
  • А вот телефоны которые еще не перегружались, и обновляют свои записи корректно.

    Но при перезагрузке возникает та же самая ситуация.


    Ни что не вечно под луной...

    16 августа 2012 г. 11:00
  • Вообще не понимаю что произошло. Поменял только адреса и маску внутри пула. Но теперь не запрашиваются опции 43 и 120.

    Подскажите люди добрые что делать.... а то меня порешат ))))


    Ни что не вечно под луной...

    16 августа 2012 г. 11:01
  • Вот что выдает test-CsPhoneBootstrap

    test-CsPhoneBootstrap -TargetFQDN XXXXX-lync.astel.kz -PhoneOrExt XXXXXX  -PIN 123123  -verb
    VERBOSE: Workflow Instance Id 80f642ec-a069-4d63-8a5f-40d97f49e2ed, started.
            Constructing a dhcp packet
            Adding dhcp option PARAMETER_REQUEST_LIST
            Successfully added dhcp option
            Adding dhcp option VENDOR_CLASS_IDENTIFIER
            Successfully added dhcp option
            Successfully constructed dhcp packet
            =======================PACKET BEGIN==============================
            op: 1
            htype: 1
            hlen: 6
            hops: 0
            xid: 136
            secs: 0
            flags: 0
            ciaddr: 192.168.105.15
            yiaddr: 0.0.0.0
            siaddr: 0.0.0.0
            giaddr: 0.0.0.0
            chaddr:  PV?←&
            sname:
            file:
            magic: 99.130.83.99
            Message Type : DHCPINFORM
            Option43 :
            Option55 : 7☻x+
            Option60 : <♀MS-UC-Client
            Option120 :
            Other options :
            =======================PACKET END================================
            Trying to open an udp connection
            Remote IP : 255.255.255.255
            Local IP : 192.168.105.15
            Disconnecting


    TargetUri  :
    TargetFqdn : xxxxxx-lync.astel.kz
    Result     : Failure
    Latency    : 00:00:00
    Error      : Only one usage of each socket address (protocol/network address/port) is normally permitted

    Diagnosis  :

    VERBOSE: Target server fqdn or web service url not provided. Will have to do DHCP Registrar
    Discovery.
    'DHCPDiscovery' activity started.
    Starting DHCP registrar discovery...
    ERROR during DHCP registrar discovery.
    Starting cleanup...
    An exception 'Only one usage of each socket address (protocol/network address/port) is normally
    permitted' occurred during Workflow
    Microsoft.Rtc.SyntheticTransactions.Workflows.STPhoneBootstrapWorkflow execution.
    Exception Call Stack:    at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot,
    SocketAddress socketAddress)
       at System.Net.Sockets.Socket.Bind(EndPoint localEP)
       at Microsoft.Rtc.SyntheticTransactions.DHCPClient.Connect(String serverIP, String clientIP)
       at
    Microsoft.Rtc.SyntheticTransactions.Activities.DHCPDiscoverActivity.InternalExecute(ActivityExec
    utionContext executionContext)
       at Microsoft.Rtc.SyntheticTransactions.Activities.STActivity.Execute(ActivityExecutionContext
     executionContext)
       at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity,
    ActivityExecutionContext executionContext)
       at System.Workflow.ComponentModel.CompositeActivityExecutor`1.Execute(T activity,
    ActivityExecutionContext executionContext)
       at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity,
    ActivityExecutionContext executionContext)
       at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime
    workflowCoreRuntime)
       at System.Workflow.Runtime.Scheduler.Run()

    'UnRegisterActivity' activity started.
    'UnRegisterActivity' activity completed in '0,0002375' secs.
    VERBOSE: Workflow Instance Id 80f642ec-a069-4d63-8a5f-40d97f49e2ed, completed.
    VERBOSE: Workflow Execution Time (sec): 0.051003



     

    Ни что не вечно под луной...


    17 августа 2012 г. 3:32
  • Вообщем победил я эту беду. Можно закрывать тему.

    Ни что не вечно под луной...

    17 августа 2012 г. 6:25
  • Прделитесь с другими.

    Сазонов Илья http://isazonov.wordpress.com/

    17 августа 2012 г. 8:43
    Модератор
  • Вообщем все оказалось гораздо тривиальней! Я проводил анализ с помощью wireshark и фильтра bootp, и не видел что происходит помимо запросов dhcp. Я видел что телефон благополучно находил свой голосовой vlan , делал запрос на получении ip адреса, вместе с котором получал еще и адреса ntp серверов, фактически адреса dc, которые были недоступны! Не спрашивайте почему и как, виновные уже найдены! Просто что мне удалось выяснить благодаря этому, так это то что телефон не делает запрос dhcp inform для запроса опций 43, 120 до тех пор пока не проведет синхронизацию времени с ntp серверами или пока не истечет какой то таймер, равный приблизительно 180 секундам!  После этого запрос dhcp inform всегда осуществляется, однако он уже не имеет никакого значения если синхронизация времени оказалась неудачной . Ssl handshake уже будет неудачным. Еще один важный момент который может пригодится так это то что при сбросе в factory defaults , телефоны не смогли синхронизироваться с контроллерами домена, так как первичный timestamp был очень большой, телефоны выставляли в запросе 2010 год, подозреваю дата  их выпуска. И для успешной синхронизации в этом случае по любому требовалась дополнительная настройка.

    Установка минимальной положительной и отрицательной коррекции Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]

    "MaxPosPhaseCorrection"=dword:FFFFFFFF

    "MaxNegPhaseCorrection"=dword:FFFFFFFF

    Я поднял на freebsd свой ntp  и засинхрил телефоны оттуда, и все зашуршало как надо!

    А dhcp pool  и изменения в нем никакой роли и не играли!  


    Ни что не вечно под луной...



    • Изменено Nikita Sokolov 20 августа 2012 г. 8:24
    • Помечено в качестве ответа Yuriy Lenchenkov 30 августа 2012 г. 11:35
    20 августа 2012 г. 8:15