**Description**
The `secfilter` module in `kamcmd` currently allows duplicate entries when adding values to certain lists (e.g., blacklists, whitelists). This can lead to unexpected behavior and potential inconsistencies. Could you clarify the reason behind accepting duplicate values?
Recently, I submitted a pull request to add delete commands to the `secfilter` module #4089. When a user, for example, executes:
`kamcmd secfilter.del_bl user 1005`
I iterate through the entire list to ensure all occurrences of `1005` are removed, as I realized duplicates might exist. This is inefficient and could be avoided by preventing duplicates in the first place.
**Proposed Solutions**
1. **Prevent Duplicates in Existing `add` Commands:**
* I can modify existing `add` commands to directly prevent the addition of duplicate values. This would simplify future operations and improve performance.
2. **Introduce New `add_unique` Commands:**
* I can maintain the current `add` commands for backward compatibility.
* I can introduce new `add_unique` commands (e.g., `secfilter.add_bl_unique`) that explicitly reject duplicate entries.
**Recommendation**
I recommend implementing the first solution (preventing duplicates in existing `add` commands) as it provides the most straightforward and efficient approach.
**Further Considerations**
* Consider adding a check for duplicates during the `add` operation and returning an appropriate error message if a duplicate is encountered.
* Document the behavior of duplicate values in the `secfilter` module's documentation.
**I would appreciate your feedback and guidance on the best course of action.**
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4091
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4091(a)github.com>
sergey-safarov created an issue (kamailio/kamailio#4290)
### Description
According to [RFC3261](https://www.ietf.org/rfc/rfc3261.html#section-18.3) Section 18.3
```
In the case of message-oriented transports (such as UDP), if the
message has a Content-Length header field, the message body is
assumed to contain that many bytes. If there are additional bytes in
the transport packet beyond the end of the body, they MUST be
discarded.
```
In the current Kamailio implementation, extra bytes are analyzed, and this triggers a failed sanity check.
### Troubleshooting
#### Reproduction
To reproduce required prepare config file
```
listen=udp:127.0.0.1:5060
loadmodule "xlog.so"
loadmodule "sl.so"
loadmodule "sanity.so"
modparam("sanity", "autodrop", 0)
modparam("sanity", "noreply", 1)
route{
if(sanity_check()) {
sl_send_reply("200", "OK");
exit;
}
xerr("sanity checks failed\n");
sanity_reply();
drop;
}
```
And start using a command like
```
kamailio -DD -E -f kamailio.cfg
```
Then need to send options using a command like
```
cat options-extra.txt | nc -u 127.0.0.1 5060
```
Where `options-extra.txt` is a file from the attached archive
[options.tar.gz](https://github.com/user-attachments/files/20838024/options.…
If you remove extra bytes after the OPTIONS message, then Kamailio does not generate an error.
This can be tested using the command
```
cat options-normal.txt | nc -u 127.0.0.1 5060
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4290
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4290(a)github.com>