mirror/icwmp
1
0
Fork 0
mirror of https://dev.iopsys.eu/bbf/icwmp.git synced 2026-01-27 17:17:17 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Design doc: XML, backup session, notifications parts and other enhancements

Browse source
This commit is contained in:
Omar Kallel 2023-02-23 19:01:10 +01:00
parent 02d1948c01
commit d135d87f65
9 changed files with 369 additions and 78 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

61
docs/design/design.md
View file

@ -28,7 +28,7 @@ As descibed in TR-069 standard, CWMP stack comprises several components that are
- Application: the application uses CWMP protocol on the CPE. In the icwmp client, the main application is defined in cwmp.c source file. It's based on uloop libubox functionality. Multiple timers are running under the main uloop of icwmp like session timer, ubus timer, heartbeat timer, ...
- RPC methods: The specific RPC methods that are defined by CWMP protocol. In icwmp client RPC methods are defined under the source file rpc.c.
- SOAP: A standard XML-based syntax used here to encode remote procedure calls. The SOAP part is developed in xml.c file and it's detailed in the section ...
- SOAP: A standard XML-based syntax used here to encode remote procedure calls. The SOAP part is developed in xml.c file.
- HTTP: this part is responsible to send SOAP messages over HTTP. In icwmp it's based on libcurl library. Its corresponding C functions are developed in the file http.c.
- SSL/TLS: The standard Internet transport layer security protocol. icwmp can work with openssl or mbedtls or wolfssl depending on the SSL library selection. Its corresponding functions are defined in ssl_utils.c file.
@ -58,9 +58,9 @@ class cwmp {
- cr_socket_des: is an integer attribute. This attribute contains the id of the socket used by the CR.
- pide_file: is a File type attribute. This file used by the app in order to garantuate a single app instance running.
- deviceid: its type is deviceid structure. This struct contains the device information important attributes values: OUI, Manufacturer, SerialNumber, ProductClass, SoftwareVersion.
- session: its type is session structure. This structure contains attributes related to the running application.
- session: its type is session structure. This structure contains attributes related to the running session.
```mermaid
```mermaid
classDiagram
class session {
head_rpc_cpe: list
@ -102,7 +102,8 @@ flowchart TD
C --> K[Start CR server thread]
K --> L[listen to coming HTTP requests in the CR port]
L --> M{CR is received}
M -- yes --> E
M -- yes --> N[execute the ubus method: tr069 inform]
N --> E
M -- no --> L
```
@ -119,9 +120,6 @@ flowchart TD
then the application start the uloop run by waiting uloop timeouts to come.
two kinds of timeouts can be detected:
2 - In the same time a thread is created. It permits a permenant listening of the port , in the purpose to receive connection requests.
In case a CR is received successfully "tr069 inform" ubus call is triggered from this thread in the purpose to trigger a new session with '6 CONNECTION REQUEST' event.
@ -136,48 +134,61 @@ The Inform ACS request is sent by the CPE to the ACS in the start of the CWMP se
In icwmp the corresponding function responsible to create the Inform message is cwmp_rpc_acs_prepare_message_inform. It starts by getting the device ID attributes and the list of events that needs to be included in the inform message and then parameters that are amended in the ParameterList including default Inform Parameter and other parameters like parameters related to the Value Change.
## Events manipulation
As described in TR069 standard, events in CWMP protocol must be sent by the CPE in an Inform request in order to notify the ACS when something of interest has happened.
In icwmp when creating the inform message events are loaded from events list_head attribute of the session structure attribute.
CWMP events are stored in the **events** list_head attribute of the session structure attribute. Each element of this list is an instance of the structure event_container that is the following:
```mermaid
classDiagram
class event_container {
code: integer
next_session: boolean
command_key: string
head_dm_parameter: list
id: integer
}
```
In icwmp when creating the inform message events are loaded from **events** list.
As soon as the event is reached, it's added to the list events. Different scenarios are presents to reach event in icwmp:
- Start app events: this scenario includes following events: "0 BOOTSTRAP" (if it's the first Inform to be sent to the specified ACS), "1 BOOT"
- Start app events: this scenario includes following events: "0 BOOTSTRAP" (if it's the first Inform to be sent to the specified ACS), "1 BOOT".
- Get the event from the backupSession in the start of the App: Just after starting the icwmp app in the init step, the app loads the backupsession events in events list from "cwmp_event" xml tag. Then add the to the events list. This case includes events that occurs before the restart of the icwmp or reboot/upgrade of the system. In this scenario events included are: "M Reboot", "M Download", "M ScheduleDownload", "7 TRANSFER COMPLETE".
- Events when running CWMP session. Events for this scenario are detected and added to the events while executing the CWMP session especially in RPC calls. Such as "3 SHEDULED" for ScheduleInform method, "7 TRANSFER COMPLETE" (in the call of Download, Upload), "8 DIAGNOSTIC COMPLETE" (after completing diagnostic execution triggered by the ACS), "11 DU STATE CHANGE COMPLETE" after completing CDU request execution triggered by the ACS), "M Download", "M Upload" ...
- Events are detected at specific time using uloop_timeout_set:"2 PERIODIC", "14 HEARTBEAT"
- External Events: "6 CONNECTION REQUEST" when receiving a connection request from the ACS in order to start a new session. CR thread is permenantly listening on the CR port in order to detect such event and then trigger a new session. "4 VALUE CHANGE" (check notifications part), "10 AUTONOMOUS Single TRANSFER COMPLETE", "12 AUTONOMOUS DU STATE CHANGE COMPLETE"
### Notifications
## Notifications
[Notifications in icwmp client](./notifications.md)
## XML in icwmp
__TODO__
xml structures: struct xml_node_data, struct xml_tag, struct xml_list_data, struct xml_data_struct, struct xml_tag_validation
struct xml_node_data xml_nodes_data[] array
xml load functions: load_xml_node_data, load_xml_list_node_data, load_single_xml_node_data
build_xml_node_data: build_xml_list_node_data, build_single_xml_node_data
[XML mechanism in icwmp client](./xml.md)
## Backup Session management
**TODO**
Backup session feature in icwmp is used to store data that should be conserved even after reboot or sysupgrad of the system. Those data are followings:
Methods that needs backupsession
- events
- download
- transfer complete
- schedule download
- schedule inform
- upload
- change du state
- autonomous change du state
- du state change complete
find node by id
Those data are stored in xml format in the file /etc/icwmpd/icwmpd_backup_session.xml. This data is loaded by the call of the function cwmp_load_saved_session in the start of the icwmp application.
insert functions
Backup session feature uses XML functions (check XML part) to build/load XML nodes that should be stored in the backup session file. So for each kind of backup session datas there are rows in **xml_nodes_data** that their index are definde in the enumaration **xml_node_references**.
All backup session indexes are successive in the enumaration and starts with "BKP_".
load functions
For each kind of backup session data, there are insert functions that calls build_xml_node_data and load functions that calls load_xml_node_data.
## UCI and config mangement

85
docs/design/notifications.md
View file

@ -37,7 +37,7 @@ The following decribe the algorithm of the function **update_notifications_list*
```mermaid
flowchart TD
A[Iterate notifications list => param_iter notif_iter] --> B{param_name == param_iter && notification != notif_iter}
A[Iterate notifications list => param_iter notif_iter] --> B{param_name == param_iter <br> && <br> notification != notif_iter}
B -- no --> C{param_iter is suboject of param_name}
B -- yes --> D[Delete param_iter from the notifications list]
C -- no --> E{End iterations?}
@ -64,19 +64,19 @@ cwmp_get_parameter_attributes is the C function that is executed in case the Ge
flowchart TD
A[check valid parameter path of param_name] --> B{valid?}
B -- yes --> C[get_parameter_family_notifications of param_name => ret_notif, children_notif]
B -- no --> D[END]
C --> E[GPV of param_name => list_params]
E --> F[iterate of list_params => param_iter]
F --> G{param_iter is forced notification => force_notif}
G -- no --> H{param_iter is among children notif => child_notif}
H -- yes --> I[Assign to param_iter child_notif as notification]
G -- yes --> J[Assign to param_iter for_notif as notification]
H -- no --> K[Assign to param_iter ret_notif as notification]
I --> L{End iterations?}
J --> L
K --> L
L -- no --> F
L -- yes --> M[return the list of parameters with notifications]
B -- no --> D[END]
C --> E[GPV of param_name => list_params]
E --> F[iterate of list_params => param_iter]
F --> G{param_iter is forced notification <br> => force_notif}
G -- no --> H{param_iter is among children notif <br> => child_notif}
H -- yes --> I[Assign to param_iter child_notif as notification]
G -- yes --> J[Assign to param_iter for_notif as notification]
H -- no --> K[Assign to param_iter ret_notif as notification]
I --> L{End iterations?}
J --> L
K --> L
L -- no --> F
L -- yes --> M[return the list of parameters with notifications]
```
@ -84,7 +84,7 @@ As a first step the GPA function check if the parameter path is valid, after tha
```mermaid
flowchart TD
A[iterate parameters_notifications list => param_iter notif_iter] --> B{param_name is subobject of param_iter or param_name == param_iter}
A[iterate parameters_notifications list => param_iter notif_iter] --> B{param_name is subobject of param_iter <br> or param_name == param_iter}
B -- no --> C{param_iter is subobject of param_name}
B -- yes --> D[notif_ret = notif_iter]
C -- yes --> E[Add param_iter,notif_ret to children_list]
@ -97,17 +97,56 @@ flowchart TD
The function trigger an iteration of parameters under the requested parameter parameter_name, for each parameter it gets its notification and the parameter with its notification to the result list.
## VALUE CHANGE event
**TODO**
'4 VALUE CHANGE' event is a CWMP event that is used to notify the ACS that an important parameter value changed. Such events are sent in an Inform message to the ACS with the corresponding parameters and values.
## check_value_change
In icwmp parameter value change is detect by permenant check parameters (with enabled notifications) values according to their last values. Last parameters with enabled notification values are stored in JSON lines in the /etc/icwmpd/dm_enabled_notify file.
**TODO**
The process to detect the parameters that has positive notifications values is done with the function **check_value_change**. Important parameters that are detected that their values changed are amended to the list **list_value_change**.
## update parameter notifications list
As soon as a parameter value si changed by the ACS or after check_value_change process is done, the /etc/icwmpd/dm_enabled_notify file needs to be updated according to last parameters values. This process is done with the function **cwmp_update_enabled_notify_file**.
**TODO**
Next sections describes those two features in notifications in icwmp:
- check_value_change
- cwmp_update_enabled_notify_file
## check value change function:
check_value_change is responsible to detect what parameters (with enabled notifications) values changed. This process algorithm is described in the following diagram
```mermaid
flowchart TD
A[get all leaf parameters values list corresponding <br>to parameters with enabled notification <br> => list_notify_params] -->B
B[parse dm_enabled_notify_file line by line]--param_json_obj-->C[get corresponding parameter/value from param_json_obj]
C --> D[get actual parameter value from the list list_notify_params]
D --> E[compare actual and last values]
E --> F{Values are different and notification is enabled?}
F -- yes --> G[add the parameter and its actual value to the list_value_change <br> and amend the notification value to notif_ret integer value]
G --> H[next line in the dm_enabled_notify file]
H --> I{End of file?}
I -- yes --> J[return notif_ret value]
I -- no => next line param_json_obj --> C
F -- no --> H
```
The algorithm starts by get actual values of all leaf parameters (**list_notify_params**)that are under all parameters with enabled notifications whether fored notification parameters or parameters notifications set by the ACS with SetParameterAttributes.
After that the function starts parsing the /etc/icwmpd/dm_enabled_notify file, that contains old leaf parameters values, line by line. Each line is a JSON object similar to **{"parameter":"Device.WiFi.SSID.1.SSID","notification":2,"type":"xsd:string","value":"60"}**. This JSON object contains the parameter name, its notification and its recent value. In the next step, it gets the actual value of the parameter from the list **list_notify_params**. Then it compares two values : actual one and recent one. If it's changed so the notification value is amended (with OR operator) to the notif_ret integer (initialised with 0), and in addition the parameter and its actual value is amended to the lis_value_change list.
In the end of the algorithm notif_ret value is returned by the function.
Using the returned value, the decision will be token to add '4 VALUE CHANGE' to the list of events of the next session.
## cwmp_update_enabled_notify_file function:
Two cases are present to enable the file /etc/icwmpd/dm_enabled_notify content with the actual parameters values:
- After the Set value of parameters by the ACS
- After the call of check_value_change
The update of the file is done by removing the old one and creating the new one using actual parameters values.
Such process that's responsible to create dm_enabled_notify file with actual values is done by the call of the function **create_list_param_leaf_notify**.

23
docs/design/session.md
View file

@ -11,16 +11,19 @@ flowchart TD
E --> D
D --> F[Receive Inform Response from the ACS]
F --> G[Parse rest of other ACS methods list]
G --> H{End of ACS methods list?}
H -- no --> G
H -- yes --> I[Send empty HTTP message to the ACS]
I --> J[Receive HTTP Request from the ACS]
J --> K[Is request body empty]
K -- yes --> N[Execute end session function]
N --> O[exit session]
K -- no --> L[Execute CPE method]
L --> M[Send CPE method response to the ACS]
M --> J
G --> H[Prepare next ACS method request]
H --> I[Send Acs method request]
I --> J[Receive ACS method response]
J --> K{End of ACS methods list?}
K -- no --> H
K -- yes --> L[Send empty HTTP message to the ACS]
L --> M[Receive HTTP Request from the ACS]
M --> N{Is request body empty?}
N -- yes --> O[Execute end session function]
O --> P[exit session]
N -- no --> Q[Execute CPE method]
Q --> R[Send CPE method response to the ACS]
R --> M
```

238
docs/design/xml.md Normal file
View file

@ -0,0 +1,238 @@
# XML mechanism in icwmp client
XML is an important component in icwmp. It's especially used to load and build SOAP messages and backup session nodes.
It's developed essentially with mxml library. It contains all needed structures and functions to load and build xml messages.
All xml nodes names that are needed in icwmp for both SOAP and backup session are defined in an array **xml_nodes_data**.
The type of the array xml_nodes_data is __xml_node_data__ :
```mermaid
classDiagram
class cwmp {
node_ms: integer
tag_node_ref: integer
tag_list_name: string
xml_tags: xml_tag array
}
```
- node_ms: is an integer that can have two values (XML_SINGLE 0 or XML_LIST 1). Is used to indicate if the corresponding XML node is present as list or just one time.
- tag_node_ref: this integer attribute is an index in the same array xml_nodes_date of the corresponding node in case of list. Its value is 0 if the component is Single.
- tag_list_name: in case of list this string is the tag parent name of each node. Its value is NULL if the component is Single.
- xml_tags: is an array of tags under the node. xml_tag is the type of this array. Its structure is the following:
```mermaid
classDiagram
class xml_tag {
tag_name: string
tag_type: integer
rec_ref: integer
xml_func: function
}
```
each xml node tag in XML mechanism developed in icwmp has as type the xml_tag structure that has presented attributes:
- tag_name: has as type string and it's the name of the tag
- tag_type: the type of the corresponding node and can be: XML_STRING, XML_BOOL, XML_INTEGER, XML_LINTEGER, XML_TIME, XML_FUNC, XML_REC, XML_ATTR
- rec_ref: is a reference to the XML node in the same array xml_nodes_data in case tag_type is XML_REC. Its value is 0 in case tag_type is different from XML_REC.
- xml_func: is a function that is a executed in case the corresponding node is reached and the tag_type is XML_FUNC. xml_func is NULL in case tag_type is different from XML_FUNC.
### xml_data_struct structure
The xml_data_struct is a structure used for both load and build xml messages. It contains two parts of attributes, the first part contains attributes used for xml leaf node values for both buld and load, the second part contains attributes used while executing load/build process:
```mermaid
classDiagram
class xml_data_struct {
//XML node leafs attributes
parameter_list: list
name: pointer to string
value: pointer to string
string: pointer to string;
......
......
//Useful attributes
data_list: list //Load/Build XML list nodes
xml_env: pointer to xml_node
counter: ponter to integer
validations: array of xml_tag_validation structure
nbre_validations: integer
...
//Processing attributes
cdu_type: integer
rpc_enum: integer
inc_counter: boolean
..........
}
```
- XML leafs attributes are used by load process to return leaf nodes values
- validations and nbre_validations attributes are used by the function **validate_xml_node_opaque_value** if the found value of a leaf XML node is valide.
- Processing attributes are used while executing load/build features
### XML Load mechanism
XML load mechanism in icwmp client is responsible to load values from an XML node. The main function that is responsible to do such feature is **load_xml_node_data**.
This function needs to know the XML node that we need to load values, and what XML tags we need to load value basing on a reference **node_ref** to a row in the array **xml_nodes_data**.
The referenced row in the array **xml_nodes_data** can be Single or List depends on the tag_node_ref attribute value.
Therefore xml_load_node_data function will check if the corresponding row row is a Single node or a List node, and then will execute one of the following functions:
- load_single_xml_node_data
- load_xml_list_node_data
Loaded results are returned in the corresponding attributes of the structure xml_data_struct. The corresponding attribute for each tag name in the XML is found using their index in the tags names array **xml_tags_names**.
#### load_single_xml_node_data function:
Single rows in the table define a node or a group of nodes that appears just one time under the requested node. load_single_xml_nodes_data function is responsible to load values under such kind of nodes.
The process of loading a single row node is done by the following algorithm:
```mermaid
flowchart TD
A[parse the requested xml node elements] -- reached_node --> B{is reached node NULL}
B -- NULL --> S[END of algorithm]
B -- not NULL --> C[get the name of reached_node]
C --> D[check if reached_node name exists in xml_tags array]
D --> E{Exist?}
E -- no --> F[access to next xml node => reached_node]
F --> B
E --> G[get the tag type of reached_node]
G --> H{nod_type?}
H --> I{node_type is XML_FUNC}
I --> J[Execute the corresponding function]
J --> F
H --> K{node_type is XML_REC <br> => reference to an other row in xml_nodes_data}
K --> L[execute load_xml_data for reached node using the reference]
L --> F
H --> M[get xml tag_index in xml_tags_names array]
M --> N{no REC and no FUNC and <br> reached_node name not present in xml_tags_names}
N -- yes --> F
N -- no --> O[get opaque value of reached_node]
O --> P[validation of the opaque value]
P --> Q[Find the right memory address xml_data_struct to store the opaque value]
Q --> R[Store the opaque value in xml_data_struct]
R --> F
```
The load of a single by the parse of the input node tree. Basing on the type of reached_node the mechanism executes the need process.
While loading values from the XML node, the mechanism is checking the validations of those values. Validation is done using the function **validate_xml_node_opaque_value** and the **validations** array. Each XML load call has its validations attributes that are input to the load function in xml_data_struct.
Validations attribute is an array of the structure **xml_tag_validation** that has the following diagram:
```mermaid
classDiagram
class xml_tag_validation {
tag_name: string
validation_type: integer
min: integer
max: integer
}
```
- tag_name: a sting that has as value the XML node tag name.
- validation_type: integer that its value is used to choose the suitable validation function
- min: integer used to validate if value is in a range
- max: integer used to validate if value is in a range
For each XM node, **validate_xml_node_opaque_value** function is called. It find find suitable validation elemeent in **validations** array by the tag_name attribute, then it calls the right validation function basing on the validation_type attribute.
If the node is not validated it returns 9003 error.
The supported validation functions that are supported:
- icwmp_validate_string_length
- icwmp_validate_unsignedint
- icwmp_validate_boolean_value
- icwmp_validate_int_in_range
#### load_xml_list_node_data function:
List rows in the table **xml_nodes_data** define a node or a group of nodes that appears multiple times in a sequence list under the requested node. load_xml_list_node_data function is responsible to load values under such kind of nodes.
The process of loading a list row node is done by the following algorithm:
```mermaid
flowchart TD
A[parse the requested xml node elements] -- reached_node --> B{is reached node NULL}
B -- no --> C{is tag_list_name of corresponding xml_node_data <br> equal to the reached_node name}
C -- yes --> D[prepare new xmt_data_struct instance: xml_attrs_args]
D --> E[trigger load_xml_node_data with inputs: reference index in xml_nodes_data array reached_node and xml_attrs_args]
E --> F[access to next xml node => reached_node]
C -- no --> F
F --> B
B -- yes --> G[End of iteration]
```
The load of XML list is done by the parse of all xml elements in the corresponding node. For each node element that its name is the same as the tag list name in question, the function prepare a nex xml_data_struct instance that will be used to return nodes values under.
After that this instance is used to make a recursive call of **load_xml_node_data** function for the referenced row in the table **xml_nodes_data**
### XML build mechanism
XML build mechanism in icwmp client is responsible to build an XML node using input nodes values. The main function that is responsible to do such feature is **build_xml_node_data**.
This function needs to know the XML node that we need to build the node, and what XML tags and their values we need in the build basing on a reference **node_ref** to a row in the array **xml_nodes_data**.
The referenced row in the array **xml_nodes_data** can be Single or List depends on the tag_node_ref attribute value.
Therefore build_xml_node_data function will check if the corresponding row is a Single node or a List node, and then will execute one of the following functions:
- build_single_xml_node_data
- build_xml_list_node_data
Nodes attributes needed for the build are assigned to corresponding attributes in an instance in an xml_data_struct structure instance that is an input to the function build_xml_node_data. The corresponding attribute for each tag name in the XML is found using their index in the tags names array **xml_tags_names**.
#### build_single_xml_node_data function:
build_single_xml_node_data function is responsible to build XML nodes that contains nodes or group of nodes that appears just one time.
The algorithm of such feature is described in following diagram:
```mermaid
flowchart TD
A[parse xml tags array of corresponding row xml_nodes_data]-->B{End of Array?}
B-- yes -->N[End of iteration]
B -- no => xml_tag -->C{corresponding tag name is not empty}
C -- yes -->D[create new xml node x_node with the xml_tag name]
D -->E{xml_tag reference is of xml attribute}
C -- no -->E
E-- yes -->F{set corresponding node attributes <br>to referenced row attributes}
F-->G[-]
E -- no -->G
G -->H{xml_tag type is XML_REC}
G -->I{xml_tag type is XML_FUNC}
H -->J[execute build_xml_node_data for the referenced row]
I -->K[execute corresponding function]
J -->C
K -->C
G -->L[find the opaque value of corresponding xml_tag]
L -->M[set the opaque value to the x_node xml node]
M -->C
```
the build of a single node of xml_nodes_data array is done by the parse of the corresponding xml_tags array one by one. For each element the function creates the xml node and then set its opaque value basing on its type XML_REC, XML_FUNC, or otherwise.
#### build_xml_list_node_data
build_xml_list_node_data function is responsible to build XML nodes that contains nodes or group of nodes that appears multiple times in sequence list.
The algorithm of such feature is described in following diagram:
```mermaid
flowchart TD
A[parse the input data_list of xml_data_struct]--list_element-->A1[create xm node element with the name tag_list_name of referenced row]
A1-->B[create xml_data_struct instance with list_element attributes values]
B --> C[execute build_xml_node_data function for referenced row]
C --> D[increment counter if needed]
D --> E{End iteration}
E -- no => list_element -->A1
E -- yes -->F[End]
```
The algorithm is a parse of the data_list attribute of the structure xml_data_struct. For each element it creates an xml node with the name tag_list_name of the referenced row. Then it calls build_xml_node_data in order to build nodes under the created one.

3
src/autonomous_complpolicy.c
View file

@ -3,7 +3,8 @@
*
* Copyright (C) 2021-2022, IOPSYS Software Solutions AB.
*
* Author Suvendhu Hansa <suvendhu.hansa@iopsys.eu>
* Author: Suvendhu Hansa <suvendhu.hansa@iopsys.eu>
* Author: Omar Kallel <omar.kallel@pivasoftware.com>
*
* See LICENSE file for license related information.
*

12
src/notifications.c
View file

@ -571,14 +571,14 @@ int check_value_change(void)
FILE *fp;
char buf[1280];
char *dm_value = NULL, *dm_type = NULL;
int int_ret = 0;
int notif_ret = 0;
struct blob_buf bbuf;
char *parameter = NULL, *value = NULL;
int notification = 0;
fp = fopen(DM_ENABLED_NOTIFY, "r");
if (fp == NULL)
return int_ret;
return notif_ret;
LIST_HEAD(list_notify_params);
create_list_param_leaf_notify(&list_notify_params, NULL, NULL);
@ -618,12 +618,12 @@ int check_value_change(void)
add_lw_list_value_change(parameter, dm_value, dm_type);
if (notification == 1)
int_ret |= NOTIF_PASSIVE;
notif_ret |= NOTIF_PASSIVE;
if (notification == 2)
int_ret |= NOTIF_ACTIVE;
notif_ret |= NOTIF_ACTIVE;
if (notification == 5 || notification == 6)
int_ret |= NOTIF_LW_ACTIVE;
notif_ret |= NOTIF_LW_ACTIVE;
}
FREE(dm_value);
FREE(dm_type);
@ -635,7 +635,7 @@ int check_value_change(void)
}
fclose(fp);
cwmp_free_all_dm_parameter_list(&list_notify_params);
return int_ret;
return notif_ret;
}
void cwmp_prepare_value_change()

2
src/rpc.c
View file

@ -263,8 +263,6 @@ static void load_inform_xml_schema(mxml_node_t **tree)
struct xml_data_struct env_xml_attrs = {0};
env_xml_attrs.xml_env = &envelope;
env_xml_attrs.amd_version = &cwmp_main->conf.supported_amd_version;
env_xml_attrs.session_timeout = &cwmp_main->conf.session_timeout;
int fault = build_xml_node_data(SOAP_ENV, xml, &env_xml_attrs);

4
src/xml.c
View file

@ -477,7 +477,7 @@ int build_inform_env_header(mxml_node_t *b, struct xml_data_struct *xml_attrs)
{
if (b == NULL || xml_attrs == NULL)
return FAULT_CPE_INTERNAL_ERROR;
int amd_version = xml_attrs->amd_version ? *(xml_attrs->amd_version) : 2;
int amd_version = cwmp_main->conf.supported_amd_version ? cwmp_main->conf.supported_amd_version : DEFAULT_AMD_VERSION;
mxml_node_t **envelope = xml_attrs->xml_env;
*envelope = b;
@ -505,7 +505,7 @@ int build_inform_env_header(mxml_node_t *b, struct xml_data_struct *xml_attrs)
return FAULT_CPE_INTERNAL_ERROR;
mxmlElementSetAttr(node, "soap_env:mustUnderstand", "0");
node = mxmlNewInteger(node, *(xml_attrs->session_timeout));
node = mxmlNewInteger(node, cwmp_main->conf.session_timeout ? cwmp_main->conf.session_timeout : 60);
if (!node)
return FAULT_CPE_INTERNAL_ERROR;
}

19
src/xml.h
View file

@ -11,7 +11,7 @@
#define XML2(A,B) {A, B, 0, NULL}
#define XML3(A,B,C) {A, B, C, NULL}
#define XML4(A,B,D) {A, B, 0, D}
enum soap_methods {
enum xml_nodes_references {
SOAP_REQ_SPV = 1,
SOAP_REQ_GPV,
SOAP_REQ_GPN,
@ -159,6 +159,7 @@ struct xml_tag_validation {
};
struct xml_data_struct {
//XML node leafs attributes
mxml_node_t **parameter_list;
char **name;
char **value;
@ -232,18 +233,18 @@ struct xml_data_struct {
bool *writable;
bool *is_download;
struct change_du_state *cdu;
struct du_state_change_complete *cdu_complete;
//Useful attributes
struct list_head *data_list; //Load/Build XML list nodes
mxml_node_t **xml_env;
struct list_head *data_list;
char **xcwmp;
int *amd_version;
struct event_container *event_save;
unsigned int *session_timeout;
int *cdu_type;
int *counter;
struct xml_tag_validation *validations;
int nbre_validations;
//Processing attributes
struct du_state_change_complete *cdu_complete;
struct change_du_state *cdu;
struct event_container *event_save;
int *cdu_type;
int rpc_enum;
bool inc_counter;
};