Requested scope CLIENT has not been enabled

本文介绍了解决ColdFusion中出现的客户端变量错误的方法。通过在application.cfc文件中启用客户端管理或调整ColdFusion管理器中的设置,可以避免Requested scope CLIENT has not been enabled的错误。

when I do some Practice about the client variables, have meet this error

 

 

 Requested scope CLIENT has not been enabled

 

searchForm.cfm

 

you can solve this mistake by do this

 

 

put this code in your application.cfc file

 

  <cfset THIS.clientmanagement="yes">

also you can do the following:(this is another method)

check your settings in CF Admin -> Server Settings -> Client Variables

 

<!---


 Filename: SearchForm2.cfm
 Created by: Nate Weiss (NMW)
 Please Note Maintains ÒlastÓ search via Client variables
--->

<!---
  When user submits form, save search criteria in Client variable
--->
<cfif isDefined("FORM.searchCriteria")>
 <cfset CLIENT.lastSearch = FORM.searchCriteria>
 <cfset CLIENT.lastMaxRows = FORM.searchMaxRows>
<!--- if not submitting yet, get prior search word (if possible) --->
<cfelseif isDefined("CLIENT.lastSearch") and
          isDefined("CLIENT.lastMaxRows")>
 <cfset searchCriteria = CLIENT.lastSearch>
 <cfset searchMaxRows = CLIENT.lastMaxRows>
<!--- if no prior search criteria exists, just show empty string --->
<cfelse>
 <cfset searchCriteria = "">
 <cfset searchMaxRows = 10>
</cfif>

<html>
<head><title>Search Orange Whip</title></head>
<body>

<h2>Search Orange Whip</h2>

<!--- Simple search form, which submits back to this page --->
<cfform action="#cgi.script_name#" method="post">

<!--- "Search Criteria" field --->
Search For:
<cfinput name="SearchCriteria" value="#searchCriteria#"
required="Yes"
message="You must type something to search for!">

<!--- Submit button --->
<input type="Submit" value="Search"><br>

<!--- "Max Matches" field --->
<i>show up to
<cfinput name="SearchMaxRows" value="#searchMaxRows#" size="2"
required="Yes" validate="integer" range="1,500"
message="Provide a number from 1-500 for search maximum.">
matches</i><br>
</cfform>
<!--- If we have something to search for, do it now --->
<cfif searchCriteria neq "">
  <!--- Get matching film entries from database --->
  <cfquery name="getMatches" datasource="ows">
  SELECT FilmID, MovieTitle, Summary
  FROM Films
  WHERE MovieTitle LIKE '%#SearchCriteria#%'
  OR Summary LIKE '%#SearchCriteria#%'
  ORDER BY MovieTitle
  </cfquery>

  <!--- Show number of matches --->
  <cfoutput>
  <hr><i>#getMatches.recordCount# records found for
  "#searchCriteria#"</i><br>
  </cfoutput>

  <!--- Show matches, up to maximum number of rows --->
  <cfoutput query="getMatches" maxrows="#searchMaxRows#">
  <p><b>#MovieTitle#</b><br>
  #Summary#<br>
  </cfoutput>
</cfif>

</body>
</html>

握手和证书验证在httpd模块请求入口那里就已经实现了对https的处理,这里是不是可以不用修改?基本上只要考虑事件推送pull point和basic notify相关,基于我前面给你的onvif协议上对此的规范,能不能重新给出完整的修改,分步骤,对每一步修改繇指出是根据协议规范上的哪一点来修改的?原因是什么?怎么修改?请根据协议重新对soap_tev.c和soap_event.c的代码进行修改——Real-time Pull-Point Notification Interface This section introduces the Real-time Pull-Point Notification Interface. This interface provides a firewall friendly notification interface that enables real-time polling and initiates all client communications. This interface is used in the following way: The client asks the device for a pull point with the CreatePullPointSubscriptionRequest message. The device evaluates the subscription request and returns either a CreatePullPointSubscriptionResponse or one of the Fault codes. If the subscription is accepted, the response contains a WS-EndpointReference to the instantiated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in Figure 6. Client Event Service CreatePullPoint SubscriptionRequest Instantiate CreatePullPoint SubscriptionResponse PullMessages Request PullPoint PullMessages Response Unsubscribe Request Unsubscribe Response Figure 6: Sequence diagram for the Real-time Pull-Point Notification Interface The device immediately responds with notifications that have been aggregated on behalf of the client. If there are no aggregated notifications, the device waits to respond until either a notification is produced for the client or the specified Timeout has exceeded. In any case, the response will contain, at most, the number of notifications specified by the MessageLimit parameter. The client can poll the notifications in real-time when it starts a new PullMessagesRequest immediately after each PullMessagesResponse. For a device implementation it is important to support multiple pull points (including multiple pullpoints per client) in order to allow precise event generation. If a device would only support one subscription at a time a client would need to subscribe without any scope restriction, because changing of event subscription is not possible. Hence this would require the device to serve all available events for which the device would have to activate all subsystems that generate events. This may cause unnecessary load by e.g. activating multiple motion detectors and similar without need. Additionally the traffic produced by all these events may cause a substantial network load. ONVIF™– 86 ONVIF Core Spec – Ver. 24.12 If the device supports persistent notification storage, see 9.1.7, the WS-Endpoint also provides a Seek opera tion. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to reverse the pull direction. There is also a BeginOfBuffer event, as defined in 9.11.1, that signals the start of the buffer. An ONVIF compliant device shall implement the Real Time Pull-Point Notification Interface. 9.1.1 Create pull point subscription An ONVIF compliant device shall provide the CreatePullPointSubscription command. If no Filter element is specified the pullpoint shall notify all occurring events to the client. By default the pull point keep alive is controlled via the PullMessages operation. In this case, after a PullMes sages response is returned, the subscription should be active for at least the timeout specified in the PullMes sages request. A device shall support an absolute time value specified in utc as well as a relative time value for the InitialTer minationTime parameter. A device shall respond both parameters CurrentTime and TerminationTime as utc using the ‘Z’ indicator. The following optional subscription policy elements are defined in tev:SubscriptionPolicy: • tev:ChangedOnly A pullpoint should not provide Initialized nor Deleted events for Properties. Both request and response message contain the same elements as the SubscriptionRequest and Response of [WS-BaseNotification] without the ConsumerReference. REQUEST: • Filter - optional [wsnt:FilterType] Optional filtering for e.g. topics. • InitialTerminationTime - optional [wsnt:AbsoluteOrRelativeTimeType] Initial termination time. • SubscriptionPolicy - optional [xs:any] RESPONSE: • SubscriptionReference [wsa:EndpointReferenceType] Endpoint reference of the subscription to be used for pulling the messages. • CurrentTime [xs:dateTime] Current time of the server for synchronization purposes. • TerminationTime [xs:dateTime] Date time when the PullPoint will be shut down without further pull requests. FAULTS: • The same faults as for Subscription Request of the [WS-BaseNotification] are used. ACCESS CLASS: READ_MEDIA 9.1.2 Pull messages The device shall provide the following PullMessages command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. ONVIF™– 87 ONVIF Core Spec – Ver. 24.12 The device shall support a Timeout of at least one minute. The device shall not respond with a PullMessages FaultResponse when the MessageLimit is greater than the device supports. Instead, the device shall return up to the supported messages in the response. The response behavior shall be one of three types: • If there are one or more messages waiting (i.e., aggregated) when the request arrives, the device shall immediately respond with the waiting messages, up to the MessageLimit. The device shall not discard unsent messages, but shall await the next PullMessages request to send remaining messages. • If there are no messages waiting, and the device generates a message (or multiple simultaneous messages) prior to reaching the Timeout, the device shall immediately respond with the generated messages, up to the MessageLimit. The device shall not wait for additional messages before returning the response. • If there are no messages waiting, and the device does not generate any message prior to reaching the Timeout, the device shall respond with zero messages. The device shall not return a response with zero messages prior to reaching the Timeout. A device shall respond both parameters CurrentTime and TerminationTime as utc using the ‘Z’ indicator. After a seek operation the device shall return the messages in strict message utc time order. Note that this requirement is not applicable to standard realtime message delivery where the delivery order may be affected by device internal computations. A device should return an error (UnableToGetMessagesFault) when receiving a PullMessages request for a subscription where a blocking PullMessage request already exists. REQUEST: • Timeout [xs:duration] Maximum time to block until this method returns. • MessageLimit [xs:int] Upper limit for the number of messages to return at once. A server implementation may decide to return less messages. RESPONSE: • CurrentTime [xs:dateTime] The date and time when the messages have been delivered by the web server to the client. • TerminationTime [xs:dateTime] Date time when the PullPoint will be shut down without further pull requests.NotificationMessage - optional, unbounded [wsnt:NotificationMessageHolderType] List of messages. This list shall be empty in case of a timeout. PULLMESSAGESFAULTRESPONSE: • MaxTimeout [xs:duration] Only when the Timeout exceeds the upper limit supported by the device. Not sent when the Message Limit is exceeded. The Fault Message shall contain the upper limits for both parameters. • MaxMessageLimit [xs:int] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA ONVIF™– 88 ONVIF Core Spec – Ver. 24.12 9.1.3 Renew An ONVIF compliant device shall support this command if it signals support for [WS-Base Notification] via the MaxNotificationProducers capability. The command shall at least support a Timeout of one minute. A device shall respond both parameters Cur rentTime and TerminationTime as utc using the ‘Z’ indicator. REQUEST: • TerminationTime [wsnt:AbsoluteOrRelativeTimeType] The new relative or absolute termination time. RESPONSE: • CurrentTime [xs:dateTime] The current server time. • TerminationTime [xs:dateTime] The updated TerminationTime for the SubscriptionManager. RESOURCEUNKNOWNFAULTRESPONSE: • Timestamp [xs:dateTime] The pull point reference is invalid • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] UNACCEPTABLETERMINATIONTIMEFAULTRESPONSE: • Timestamp [xs:dateTime] The Timeout exceeds the upper limit supported by the device. • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.4 Unsubscribe The device shall provide the following Unsubscribe command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. The command is defined in section 6.1.2 of [OASIS Web Ser vices Base Notification 1.3 [http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf]]. This command shall terminate the lifetime of a pull point. REQUEST: This is an empty message. RESPONSE: This is an empty message. ONVIF™– 89 ONVIF Core Spec – Ver. 24.12 RESOURCEUNKNOWNFAULTRESPONSE: • Timestamp [xs:dateTime] The pull point reference is invalid • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.5 Seek A device supporting persistent notification storage as defined in section 9.1.7 shall provide the following Seek command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. On a Seek a pullpoint shall abort any event delivery including any initial states of properties. Furthermore the pullpoint should flush events not already queued for transmission from the transmit queue. After a Seek request a pullpoint shall ignore the behavior described in section 9.6 for properties. A device shall only set the subscription in reverse pull mode if the Reverse argument is present and set to “true”. The UtcTime argument of the Seek request shall be matched against the UtcTime attribute of the notifications in the persistent notification storage. When Seek is used in the forward mode a device shall position the pull pointer to include all NotificationMes sages in the persistent storage with a UtcTime attribute greater than or equal to the Seek argument. When Seek is used in reverse mode a device shall position the pull pointer to include all NotificationMessages in the in the persistent storage with a UtcTime attribute less than or equal to the Seek argument. A device shall not provide information of the initial generate property state as response to a call to the Seek method. REQUEST: • UtcTime [xs:datetime] This message shall be addressed to a PullPoint in order to readjust the pull position: • Reverse - optional [xs:bool] RESPONSE: This is an empty message. FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.6 Pull Point Lifecycle Figure 6 depicts the basic operation of a pull point. This chapter states the requirements on the pull point lifecycle. ONVIF™– 90 ONVIF Core Spec – Ver. 24.12 A device shall create a new pull point on each CreatePullPointSubscription command as long as the number of instantiated pull points does not exceed the capability MaxPullPoints. Each pull point shall have a unique endpoint reference to which the client can direct its consecutive operations on the pull point. A pull point shall exist until either its termination time has elapsed or the client has requested its disposal via an Unsubscribe request. There are no requirements regarding persistency of a pull point across a power cycle of a device. 9.1.7 Persistent notification storage To ensure that no notifications are lost by a client a device may store its notifications. The stored notifications can at any time be retrieved by a client. The device shall indicate if its support persistent notification storage with the PersistentNotificationStorage capability. See section 9.8. This specification defines that the interface to the persistent storage allows linear access via the originating message event time. This holds also for events that are delivered out of order in the live streaming case due to e.g. computational delay. The details of what notification and how and where those notifications actually are stored are outside the scope of this specification. Removal policy of stored notifications to get room for new ones is also out of scope. 9.2 Notification Streaming Interface This section defines the transmission of events via RTP streaming packets. For details regarding the configu ration see section “Metadata Configuration“ of the ONVIF Media Service Specification. The following requirements apply if a devices supports transmission of events via RTP streaming packets: • The events shall be encoded as wsnt:NotificationMessage as defined in [WS-BaseNotification] to trans port the Message Payload, the Topic and the ProducerReference. • Multiple instances of the wsnt:NotificationMessage elements can be placed within a metadata docu ment. • Since there is no explicit SubscriptionReference with streaming notifications, the wsnt:NotificationMes sage shall not contain the SubscriptionReference element. 9.3 Basic Notification Interface Section 9.3.1 briefly introduces the Basic Notification Interface of the [WS-BaseNotification] specification. Sec tion 9.3.2 summarizes the mandatory and the optional interfaces of the [WS-BaseNotification] specification. Please refer for a full documentation of the Basic Notification Interface to the [WS-BaseNotification] specifica tion. 9.3.1 Introduction The following logical entities participate in the notification pattern: Client: implements the NotificationConsumer interface. Event Service: implements the NotificationProducer interface. Subscription Manager: implements the BaseSubscriptionManager interface. The Event Service and the Subscription Manager should be instantiated on a device. Typical messages exchanged between the entities are shown in the sequence diagram in Figure 7. First, the client establishes a connection to the Event Service. The client can then subscribe for certain notifications by sending a SubscriptionRequest. If the Event Service accepts the Subscription, it dynamically instantiates a SubscriptionManager representing the Subscription. The Event Service shall return the WS-Endpoint-Address of the SubscriptionManager in the SubscriptionResponse. ONVIF™– 91 ONVIF Core Spec – Ver. 24.12 In order to transmit notifications matching the Subscription, another connection is established from the Event Service to the client. Via this connection, the Event Service sends a one-way Notify message to the Notifica tionConsumer interface of the client. Corresponding notifications can be sent at any time by the Event Service to the client, while the Subscription is active. To control the Subscription, the client directly addresses the SubscriptionManager returned in the Subscrip tionResponse. In the SubscriptionRequest the client can specify a termination time. The SubscriptionManager is automatically destroyed when the termination time is reached. RenewRequests can be initiated by the client in order to postpone the termination time. The client can also explicitly terminate the SubscriptionManager by sending an UnsubscribeRequest. After a successful Unsubscription, the SubscriptionManager no longer exists. The interaction between EventService and SubscriptionManager is not further specified by the [WS-BaseNo tification] and is up to the implementation of the device. Client Event Service SubscriptionRequest Instantiate SubscriptionResponse Notify RenewRequest RenewResponse Subscription Manager Notify UnsubscribeRequest UnsubscribeResponse Figure 7: Sequence diagram for the Base Notification Interface 9.3.2 Requirements This section details those interfaces of the [WS-BaseNotification] that a device shall provide. An ONVIF compliant device shall support the NotificationProducer Interface of the [WS-BaseNotification] if the capability MaxNotificationProducers is non-zero. The device shall support TopicExpression filters with the dialects described in 9.6.3. The support for MessageContent filters is signalled via the GetEventProperties method. If the device does not accept the InitialTerminationTime of a subscription, it shall provide a valid Ini tialTerminationTime within the Fault Message. The device shall be able to provide notifications using the Noti fy wrapper of the [WS-BaseNotification] specification. The SubscriptionPolicy wsnt:UseRaw is optional for the device. Although the [WS-BaseNotification] has CurrentTime and TerminationTime as optional elements in a SubscribeResponse and RenewResponse, an ONVIF compliant device shall list them in both SubscribeRe sponses and RenewResponse. The device may respond to any GetCurrentMessage request with a Fault mes sage indicating that no current message is available on the requested topic. An ONVIF compliant device shall implement the Base Subscription Manager Interface of the [WS-BaseNotifi cation] specification consisting of the Renew and Unsubscribe operations. The Pausable Subscription Manager Interface is optional. The implementation of Subscriptions as WS-Resources is optional. ONVIF™– 92 ONVIF Core Spec – Ver. 24.12 An ONVIF compliant device shall support time values in request parameters that are given in utc with the ‘Z’ indicator and respond all time values as utc including the ‘Z’ indicator
10-10
Bug Description Before I start: I know that the author of Dibbler considers this software unmaintained (https://klub.com.pl/dhcpv6/); yet it is included in the repositories, so here I am with this bug report. == Issue #1: Dibbler binds to incorrect link-local address of a ppp(oe) interface == After upgrading my home router from Ubuntu 20.04 to Ubuntu 22.04, I have noticed that dibbler-client is no longer capable of starting up and binding to the PPPoE (PPP) interface created as part of my connection set-up process. This is how the link local addresses look like: rzajic@router:/home/work/dibbler/dibbler-1.0.1$ ip -6 a s dev ppp999 scope link 28: ppp999: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc cake state UNKNOWN group default qlen 3 inet6 fe80::8157:b42e:45ec:96ae peer fe80::427c:7dff:fe93:d231/128 scope link valid_lft forever preferred_lft forever fe80::8157:b42e:45ec:96ae is my side of the point to point link fe80::427c:7dff:fe93:d231 is the ISP side of the point to point link (The addresses change on every reconnection, it's nothing sensitive.) The error logs from Dibbler-client were: Apr 25 11:00:39 router.local systemd[1]: Starting LSB: Starts DHCPv6 client... Apr 25 11:00:39 router.local dibbler-client[86944]: Starting DHCPv6 client: dibbler-client. Apr 25 11:00:39 router.local systemd[1]: Started LSB: Starts DHCPv6 client. Apr 25 11:00:39 router.local DibblerClient[86950]: PD: Following interfaces marked as downlink: br0.2 Apr 25 11:00:39 router.local DibblerClient[86950]: Prefix delegation option (no parameters) found. Apr 25 11:00:39 router.local DibblerClient[86950]: Parsing /etc/dibbler/client.conf done, result=0(success) Apr 25 11:00:39 router.local DibblerClient[86950]: 1 interface(s) specified in /etc/dibbler/client.conf Apr 25 11:00:39 router.local DibblerClient[86950]: Interface ppp999/28 configuration has been loaded. Apr 25 11:00:39 router.local DibblerClient[86950]: DUID's value = 00:01:00:01:27:3c:48:99:40:8d:5c:b3:2a:ab was loaded from client-duid file. Apr 25 11:00:39 router.local DibblerClient[86950]: My DUID is 00:01:00:01:27:3c:48:99:40:8d:5c:b3:2a:ab. Apr 25 11:00:39 router.local DibblerClient[86950]: Loading old address database (client-AddrMgr.xml), using built-in routines. Apr 25 11:00:39 router.local DibblerClient[86950]: Unable to open client-AddrMgr.xml. Apr 25 11:00:39 router.local DibblerClient[86950]: Bind reuse enabled (multiple instances allowed). Apr 25 11:00:39 router.local DibblerClient[86950]: Creating control (::) socket on the lo/1 interface. Apr 25 11:00:39 router.local DibblerClient[86950]: Creating socket (addr=fe80::427c:7dff:fe93:d231) on ppp999/28 interface. Apr 25 11:00:39 router.local DibblerClient[86950]: Unable to bind socket (iface=ppp999/28, addr=fe80::427c:7dff:fe93:d231, port=546). Apr 25 11:00:39 router.local DibblerClient[86950]: Low-level layer error message: Unable to bind socket: Cannot assign requested address Apr 25 11:00:39 router.local DibblerClient[86950]: Socket creation (addr=fe80::427c:7dff:fe93:d231) on ppp999/28 interface failed. Apr 25 11:00:39 router.local DibblerClient[86950]: Fatal error during TransMgr initialization. After a quick review, it became clear that the dibbler-client attempts to bind to incorrect IPv6 link local address. This might be related to how the new(er?) clients present the link local addresses. Using the script from https://raw.githubusercontent.com/d0u9/examples/master/C/netlink/ip_show.c, I can see that the link local address on my side of the point to point link is now represented as "local address", while on non-point to point links the link local addresses are represented as interface addresses. ================================== family: 6 dev: ppp999 prefix length: 128 local address: fe80::8157:b42e:45ec:96ae (flags 128, scope 253) if address: fe80::427c:7dff:fe93:d231 (flags 128, scope 253) ================================== family: 6 dev: tap4 prefix length: 64 if address: fe80::4048:1aff:fe2e:64f4 (flags 128, scope 253) This can be worked around by modifying the low level Linux code (note that there seems to be a bug in Dibbler code, which uses IFLA_ADDRESS [belongs to layer 2, e.g. MAC address] instead of IFA_ADDRESS): --- lowlevel-linux.c 2022-04-25 23:56:08.736090768 +0200 +++ dibbler-1.0.1/Port-linux/lowlevel-linux.c 2022-04-25 23:30:35.889052974 +0200 @@ -277,7 +277,7 @@ if (!rta_tb[IFA_LOCAL]) rta_tb[IFA_LOCAL] = rta_tb[IFA_ADDRESS]; if (!rta_tb[IFA_ADDRESS]) rta_tb[IFA_ADDRESS] = rta_tb[IFA_LOCAL]; - memcpy(addr,(char*)RTA_DATA(rta_tb[IFLA_ADDRESS]),16); + memcpy(addr,(char*)RTA_DATA(rta_tb[IFA_LOCAL]),16); if (addr[0]!=0xfe || addr[1]!=0x80) { continue; /* ignore non link-scoped addrs */ } The local address is always set a few lines above the memcpy() call. After rebuild (see Issue #3 below), the process starts, binds and request a prefix (which was my goal at the beginning): Apr 25 23:39:45 router.local systemd[1]: Starting LSB: Starts DHCPv6 client... Apr 25 23:39:45 router.local dibbler-client[243724]: Starting DHCPv6 client: dibbler-client. Apr 25 23:39:45 router.local systemd[1]: Started LSB: Starts DHCPv6 client. Apr 25 23:39:45 router.local DibblerClient[243730]: PD: Following interfaces marked as downlink: br0.2 Apr 25 23:39:45 router.local DibblerClient[243730]: Prefix delegation option (no parameters) found. Apr 25 23:39:45 router.local DibblerClient[243730]: Parsing /etc/dibbler/client.conf done, result=0(success) Apr 25 23:39:45 router.local DibblerClient[243730]: 1 interface(s) specified in /etc/dibbler/client.conf Apr 25 23:39:45 router.local DibblerClient[243730]: Interface ppp999/28 configuration has been loaded. Apr 25 23:39:45 router.local DibblerClient[243730]: DUID's value = 00:01:00:01:27:3c:48:99:40:8d:5c:b3:2a:ab was loaded from client-duid file. Apr 25 23:39:45 router.local DibblerClient[243730]: My DUID is 00:01:00:01:27:3c:48:99:40:8d:5c:b3:2a:ab. Apr 25 23:39:45 router.local DibblerClient[243730]: Loading old address database (client-AddrMgr.xml), using built-in routines. Apr 25 23:39:45 router.local DibblerClient[243730]: DB timestamp:1650922785, now()=1650922785, db is 0 second(s) old. Apr 25 23:39:45 router.local DibblerClient[243730]: Auth: Replay detection value loaded 0 Apr 25 23:39:45 router.local DibblerClient[243730]: All client's 00:01:00:01:27:3c:48:99:40:8d:5c:b3:2a:ab leases are not valid. Apr 25 23:39:45 router.local DibblerClient[243730]: Bind reuse enabled (multiple instances allowed). Apr 25 23:39:45 router.local DibblerClient[243730]: Creating control (::) socket on the lo/1 interface. Apr 25 23:39:45 router.local DibblerClient[243730]: DEBUG: realIface: <IfaceIface name="ppp999" ifindex="28" hwType="512" flags="0x110d1" mBit="0" oBit="0"> <!-- no-loopback running multicast --> <!-- PrefixLength configured to 128 --> <!-- 1 link scoped addrs --> <Addr>fe80::8157:b42e:45ec:96ae</Addr> <!-- 3 non-local addrs --> 2001:1ae9:ff2:xxxx::1 2001:1ae9:ff2:xxxx:faf0:100c:edd5:ed6d 2001:1ae9:ff2:xxxx:8157:b42e:45ec:96ae <Mac></Mac> </IfaceIface> , Interface Apr 25 23:39:45 router.local DibblerClient[243730]: Creating socket (addr=fe80::8157:b42e:45ec:96ae) on ppp999/28 interface. Apr 25 23:39:45 router.local DibblerClient[243730]: Initialising link-state detection for interfaces: ppp999/28 Apr 25 23:39:45 router.local DibblerClient[243730]: CONFIRM support compiled in. Apr 25 23:39:45 router.local DibblerClient[243730]: Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on ppp999/28 interface. Apr 25 23:39:45 router.local DibblerClient[243730]: Sending SOLICIT(opts:1 25 8 ) on ppp999/28 to multicast. Apr 25 23:39:45 router.local DibblerClient[243730]: Sleeping for 1 second(s). Apr 25 23:39:45 router.local DibblerClient[243730]: Received 81 bytes on interface ppp999/28 (socket=3, addr=fe80::427c:7dff:fe93:d231). Apr 25 23:39:45 router.local DibblerClient[243730]: Received ADVERTISE on ppp999/28,trans-id=0x655732, 3 opts: 2 1 25 Apr 25 23:39:45 router.local DibblerClient[243730]: Script execution skipped for ADVERTISE response to SOLICIT. No action needed for this message type. Apr 25 23:39:45 router.local DibblerClient[243730]: Sleeping for 1 second(s). Apr 25 23:39:46 router.local DibblerClient[243730]: Processing msg (SOLICIT,transID=0x655732,opts: 1 25 8) Apr 25 23:39:46 router.local DibblerClient[243730]: Creating REQUEST. Backup server list contains 1 server(s). Apr 25 23:39:46 router.local DibblerClient[243730]: Advertise from Server ID=00:03:00:01:40:7c:7d:93:d2:31, no preference option, assumed 0.[using this] Apr 25 23:39:46 router.local DibblerClient[243730]: Sending REQUEST(opts:1 25 2 8 ) on ppp999/28 to multicast. Apr 25 23:39:46 router.local DibblerClient[243730]: Sleeping for 1 second(s). Apr 25 23:39:46 router.local DibblerClient[243730]: Received 81 bytes on interface ppp999/28 (socket=3, addr=fe80::427c:7dff:fe93:d231). Apr 25 23:39:46 router.local DibblerClient[243730]: Received REPLY on ppp999/28,trans-id=0xd529db, 3 opts: 2 1 25 Apr 25 23:39:46 router.local DibblerClient[243730]: PD: Adding 2001:1ae9:xxxx:xx00:: prefix to PD (iaid=1) to addrDB. Apr 25 23:39:46 router.local DibblerClient[243730]: PD: Adding prefix 2001:1ae9:xxxx:xx00::/56 to all interfaces (prefix will be split to /64 prefixes if necessary). Apr 25 23:39:46 router.local DibblerClient[243730]: PD: Using 1 suitable interface(s):br0.2 Apr 25 23:39:46 router.local DibblerClient[243730]: PD: Adding prefix 2001:1ae9:xxxx:xx00::/56 on the br0.2/13 interface. Apr 25 23:39:46 router.local DibblerClient[243730]: RENEW(IA_PD) will be sent (T1) after 1800, REBIND (T2) after 2880 seconds. Apr 25 23:39:46 router.local DibblerClient[243730]: About to execute /etc/dibbler/client-notify.sh script, 15 variables. Apr 25 23:39:46 router.local DibblerClient[243730]: Script execution complete, return code=0 Apr 25 23:39:46 router.local DibblerClient[243730]: Sleeping for 1799 second(s). == Issue #2: Post-install script fails == This is yet another issue spotted as part of the installation. Maybe it would deserve a separate bug report - who knows. Anyway, here it is: The postinst script fails, causing the whole installation to fail: Preparing to unpack .../dibbler-client_1.0.1-1build2_amd64.deb ... Unpacking dibbler-client (1.0.1-1build2) over (1.0.1-1build2) ... Setting up dibbler-client (1.0.1-1build2) ... Error: The new file /etc/dibbler/client.conf-dpkg-new does not exist! dpkg: error processing package dibbler-client (--install): installed dibbler-client package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.10.2-1) ... Errors were encountered while processing: dibbler-client This can be fixed by creating the conf-new version at all times: --- dibbler-client.postinst 2022-04-25 23:52:28.891596403 +0200 +++ /home/work/dibbler/dibbler-1.0.1/debian/dibbler-client.postinst 2022-04-25 23:39:40.203950174 +0200 @@ -30,6 +30,8 @@ rm ${CONFFILE_NEW} fi +touch ${CONFFILE_NEW} + db_version 2.0 #db_capb backup db_settitle dibbler-client/title == Issue #3: Dibbler rebuild fails == To rebuild the package on Ubuntu 22.04 with the latest gcc, I had to supply the "-fcommon" flag explicitly: apt-get source dibbler-client apt-get build-deps dibbler-client cd dibbler-1.0.1/ DEB_CPPFLAGS_SET="-fcommon" DEB_CFLAGS_SET="-fcommon" debuild -us -uc -i -b Without that backwards compatibility flag, build fails on this error: /usr/bin/ld: libLowLevel_a-interface.o (symbol from plugin): in function `daemon_log': (.text+0x0): multiple definition of `interface_do_message'; libLowLevel_a-lowlevel-linux-link-state.o (symbol from plugin):(.text+0x0): first defined here /usr/bin/ld: libLowLevel_a-interface.o (symbol from plugin): in function `daemon_log': (.text+0x0): multiple definition of `interface_auto_up'; libLowLevel_a-lowlevel-linux-link-state.o (symbol from plugin):(.text+0x0): first defined here ./Port-linux/daemon.h:30:5: warning: 'die' violates the C++ One Definition Rule [-Wodr] 30 | int die(const char * pidfile); | ^ Port-linux/daemon.cpp:191:6: note: return value type mismatch 191 | void die(const char * pidfile) { | ^ Port-linux/daemon.cpp:191:6: note: type 'void' should match type 'int' Port-linux/daemon.cpp:191:6: note: 'die' was previously declared here collect2: error: ld returned 1 exit status make[2]: *** [Makefile:629: dibbler-client] Error 1 make[2]: Leaving directory '/home/work/dibbler/dibbler-1.0.1' make[1]: *** [Makefile:816: all-recursive] Error 1 make[1]: Leaving directory '/home/work/dibbler/dibbler-1.0.1' dh_auto_build: error: make -j1 returned exit code 2 make: *** [debian/rules:16: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui -i -b failed == System info == # lsb_release -rd Description: Ubuntu 22.04 LTS Release: 22.04 # Shows my rebuild/patched version # apt-cache policy dibbler-client dibbler-client: Installed: 1.0.1-1build2 Candidate: 1.0.1-1.1 Version table: 1.0.1-1.1 500 500 http://cz.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages *** 1.0.1-1build2 100 100 /var/lib/dpkg/status 翻译
最新发布
10-24
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值