<!-- Kamailio Project uses GitHub Issues only for bugs in the code or feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement), you can delete the text of the template and only add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment). -->
### Description
<!-- Explain what you did, what you expected to happen, and what actually happened. --> When making end-to-end IMS voice call over IPv6, Kamailio PCSCF doesn't send the Sip Invite to callee. I saw the following error in PCSCF logs:
4(32107) DEBUG: <core> [parser/parse_uri.c:1258]: parse_uri(): parse_uri: bad char ':' in state 2 parsed: sip:FC00:1234 (13) / sip:FC00:1234:3:2:0:0:0:0:5060 (30) 4(32107) ERROR: tm [ut.h:254]: uri2dst2(): ERROR: uri2dst: bad_uri: [sip:FC00:1234:3:2:0:0:0:0:5060] 4(32107) ERROR: tm [t_fwd.c:1737]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches 4(32107) DEBUG: tm [t_funcs.c:331]: t_relay_to(): t_forward_nonack returned error -478 (-478) 4(32107) DEBUG: tm [t_funcs.c:348]: t_relay_to(): -478 error reply generation delayed
I saw a similar issue in your database: nat_traversal: Builds wrong URI for IPv6, bad URI parsing #362. Have you fixed this issue?
### Troubleshooting
To me, sip:FC00:1234:3:2:0:0:0:0:5060 should be sip:[FC00:1234:3:2:0:0:0:0]:5060. After I added the workarround to change it to sip:[FC00:1234:3:2:0:0:0:0]:5060, PCSCF can send the Sip Invite to callee and the IMS voice call can be established.
#### Reproduction
<!-- If the issue can be reproduced, describe how it can be done. -->
I can reproduce this issue using two soft phones: Linphone and Jitsi.
#### Debugging Data
<!-- If you got a core dump, use gdb to extract troubleshooting data - full backtrace, local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile bt full info locals list
If you are familiar with gdb, feel free to attach more of what you consider to be relevant. -->
``` (paste your debugging data here) ```
#### Log Messages
<!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` (paste your log messages here) ```
4(32107) DEBUG: <core> [parser/parse_uri.c:1258]: parse_uri(): parse_uri: bad char ':' in state 2 parsed: sip:FC00:1234 (13) / sip:FC00:1234:3:2:0:0:0:0:5060 (30) 4(32107) ERROR: tm [ut.h:254]: uri2dst2(): ERROR: uri2dst: bad_uri: [sip:FC00:1234:3:2:0:0:0:0:5060] 4(32107) ERROR: tm [t_fwd.c:1737]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches 4(32107) DEBUG: tm [t_funcs.c:331]: t_relay_to(): t_forward_nonack returned error -478 (-478) 4(32107) DEBUG: tm [t_funcs.c:348]: t_relay_to(): -478 error reply generation delayed
#### SIP Traffic
<!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` (paste your sip traffic here) ```
INVITE sip:bob@[fc00:1234:3:2:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org SIP/2.0 Record-Route: sip:mt@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=be2790bd;did=557.1972 Route: sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;nat=yes;received=sip:FC00:1234:3:2:0:0:0:0:5060;lr Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=be2790bd;did=557.1972 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:45];lr=on;ftag=be2790bd;nat=yes;did=557.f271 Call-ID: 16a983b6edc2370ad08370112a800d98@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=be2790bd To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bKc87.6294094b4129fdf733069ffd6625d303.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:46];branch=z9hG4bKc87.66958ffdcce62f80024bf5913086e312.1 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bKc87.5d9a7aae58830978432d73b25057fb39.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:45];branch=z9hG4bKc87.b56bcd8f177f65d2b1ec20ccca46519a.0 Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;rport=5060;branch=z9hG4bK-363237-5db2dc2ac95e17a0c589ae29eb75a0ce Max-Forwards: 66 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910 X-RTP: mo P-Asserted-Identity: sip:alice@ims.mnc001.mcc001.3gppnetwork.org
v=0 o=alice-jitsi.org 0 0 IN IP6 fc00:1234:3:1:0:0:0:0 s=- c=IN IP6 fc00:1234:3:1:0:0:0:0 t=0 0 m=audio 5056 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101 a=rtpmap:96 opus/48000/2 a=fmtp:96 usedtx=1 a=ptime:20 a=rtpmap:97 SILK/24000 a=rtpmap:98 SILK/16000 a=rtpmap:9 G722/8000 a=rtpmap:100 speex/32000 a=rtpmap:102 speex/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:103 iLBC/8000 a=rtpmap:3 GSM/8000 a=rtpmap:104 speex/8000 a=rtpmap:101 telephone-event/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=rtcp-xr:voip-metrics m=video 5058 RTP/AVP 105 99 a=recvonly a=rtpmap:105 H264/90000 a=fmtp:105 profile-level-id=4DE01f;packetization-mode=1 a=imageattr:105 send * recv [x=[1:1376],y=[1:883]] a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=4DE01f a=imageattr:99 send * recv [x=[1:1376],y=[1:883]]
### Possible Solutions
<!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` (paste your output here) ``` version: kamailio 5.0.0-dev5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 21:48:42 Feb 21 2017 with gcc 5.4.0
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) -->
``` (paste your output here) ``` Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial
Do you set the r-uri value inside kamailio.cfg via some assignment operations? Or it is updated only by the ims modules you are using?
If later, maybe @jaybeepee, @ngvoice or @richardgood can comment more on what happens in the c code for the modules.
Thank you, miconda. We don't set r-uri value in pcscf.cfg, icscf.cfg or scscf.cfg. I will show more details below using the logs with Jitsi. I will omit SDP to save space.
1. When PCSCF received the Sip Invite from caller, the Sip headers look fine:
INVITE sip:bob@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Call-ID: 0b23b2ee62c061ae9f3cc1569b7824b3@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=94b2833a To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;branch=z9hG4bK-393032-567b1c47371a83386f685807100ab5bd Max-Forwards: 70 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910
2. Then PCSCF sent it to SCSCF:
INVITE sip:bob@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Route: sip:orig@scscf.ims.mnc001.mcc001.3gppnetwork.org:5060;lr Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:45];lr=on;ftag=94b2833a;nat=yes;did=991.9181 Call-ID: 0b23b2ee62c061ae9f3cc1569b7824b3@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=94b2833a To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:45];branch=z9hG4bK0d1b.9247221bd3cd63299ff9b3e1486a94e0.0 Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;rport=5060;branch=z9hG4bK-393032-567b1c47371a83386f685807100ab5bd Max-Forwards: 69 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910 P-Asserted-Identity: sip:alice@ims.mnc001.mcc001.3gppnetwork.org X-RTP: mo
3. The SCSCF sent to ICSCF:
INVITE sip:bob@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=94b2833a;did=991.b322 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:45];lr=on;ftag=94b2833a;nat=yes;did=991.9181 Call-ID: 0b23b2ee62c061ae9f3cc1569b7824b3@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=94b2833a To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bK0d1b.3b5263a0a9b70cdde23243c3423be371.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:45];branch=z9hG4bK0d1b.9247221bd3cd63299ff9b3e1486a94e0.0 Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;rport=5060;branch=z9hG4bK-393032-567b1c47371a83386f685807100ab5bd Max-Forwards: 68 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910 X-RTP: mo P-Asserted-Identity: sip:alice@ims.mnc001.mcc001.3gppnetwork.org
4. Then ICSCF sent it to SCSCF:
INVITE sip:bob@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Route: sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:5060 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=94b2833a;did=991.b322 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:45];lr=on;ftag=94b2833a;nat=yes;did=991.9181 Call-ID: 0b23b2ee62c061ae9f3cc1569b7824b3@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=94b2833a To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:46];branch=z9hG4bK0d1b.acefb88ca4d295d2bd315467f0670d7f.1 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bK0d1b.3b5263a0a9b70cdde23243c3423be371.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:45];branch=z9hG4bK0d1b.9247221bd3cd63299ff9b3e1486a94e0.0 Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;rport=5060;branch=z9hG4bK-393032-567b1c47371a83386f685807100ab5bd Max-Forwards: 67 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910 X-RTP: mo P-Asserted-Identity: sip:alice@ims.mnc001.mcc001.3gppnetwork.org
5. Then SCSCF sent it to the PCSCF of the callee:
INVITE sip:bob@[fc00:1234:3:2:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org SIP/2.0 Record-Route: sip:mt@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=94b2833a;did=991.b322 Route: sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;nat=yes;received=sip:FC00:1234:3:2:0:0:0:0:5060;lr Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:47];lr=on;ftag=94b2833a;did=991.b322 Record-Route: sip:mo@[FC00:1234:1:0:0:0:0:45];lr=on;ftag=94b2833a;nat=yes;did=991.9181 Call-ID: 0b23b2ee62c061ae9f3cc1569b7824b3@0:0:0:0:0:0:0:0 CSeq: 1 INVITE From: "alice" sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=94b2833a To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bK0d1b.da418b33c49aee4296db5cf6393c2c36.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:46];branch=z9hG4bK0d1b.acefb88ca4d295d2bd315467f0670d7f.1 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:47];branch=z9hG4bK0d1b.3b5263a0a9b70cdde23243c3423be371.0 Via: SIP/2.0/UDP [FC00:1234:1:0:0:0:0:45];branch=z9hG4bK0d1b.9247221bd3cd63299ff9b3e1486a94e0.0 Via: SIP/2.0/UDP [fc00:1234:3:1:0:0:0:0]:5060;rport=5060;branch=z9hG4bK-393032-567b1c47371a83386f685807100ab5bd Max-Forwards: 66 Contact: "alice" sip:alice@[fc00:1234:3:1:0:0:0:0]:5060;transport=udp;registering_acc=ims_mnc001_mcc001_3gppnetwork_org User-Agent: Jitsi2.10.5550Linux Content-Type: application/sdp Content-Length: 910 X-RTP: mo P-Asserted-Identity: sip:alice@ims.mnc001.mcc001.3gppnetwork.org
In the last invite message, there is sip:FC00:1234:3:2:0:0:0:0:5060 which doesn't have [ ] and probably cause this issue.
Any thoughts?
Attached is wireshark log. Thank you!
[ipv6 Jitsi parse error.pcapng.zip](https://github.com/kamailio/kamailio/files/1055707/ipv6.Jitsi.parse.error.pc...)
It seems like this issue is introduced by PCSCF when Soft Phone registers. The SIP Register from PCSCF to ICSCF is as below:
REGISTER sip:ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP [FC00:1235:1:0:0:0:0:45];branch=z9hG4bK9fc5.213ad03f122aa3a2b0840eae36a852ba.1 Via: SIP/2.0/UDP [fc00:1235:3:1::]:5060;rport=5060;received=FC00:1235:3:1:0:0:0:0;branch=z9hG4bK2107430722 From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=60956342 To: sip:alice@ims.mnc001.mcc001.3gppnetwork.org Call-ID: 2069996946 CSeq: 1 REGISTER Contact: sip:alice@[fc00:1235:3:1::];line=572ba75522c0a87;alias=[FC00:1235:3:1:0:0:0:0]~5060~1 Max-Forwards: 69 User-Agent: Linphone/3.6.1 (eXosip2/4.1.0) Expires: 3600 Content-Length: 0 Path: sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;nat=yes;received=**sip:FC00:1235:3:1:0:0:0:0:5060**;lr Supported: path Require: path P-Visited-Network-ID: ims.mnc001.mcc001.3gppnetwork.org
The SIP Register from Soft Phone is fine:
REGISTER sip:ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP [fc00:1235:3:1::]:5060;branch=z9hG4bK2107430722 From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org;tag=60956342 To: sip:alice@ims.mnc001.mcc001.3gppnetwork.org Call-ID: 2069996946 CSeq: 1 REGISTER Contact: sip:alice@[fc00:1235:3:1::];line=572ba75522c0a87 Max-Forwards: 70 User-Agent: Linphone/3.6.1 (eXosip2/4.1.0) Expires: 3600 Content-Length: 0
@davidxbwang please use markdown format when pasting.
@linuxmaniac Thank you. I corrected a format issue in my previous post. How to select "markdown format"?
@linuxmaniac, @miconda, I work with @davidxbwang
I found the issue in modules/pv/pv_core.c. Function pv_get_srcip(). We should substitute the function ip_addr2strz() for ip_addr2a(). ip_addr2strz() correctly inserts the [] in the string when the address is IPv6. Also, I noticed that both of these functions use a static buffer that is one character too small. Since they put a null terminator, if you have a maximum size IPv6 address (no leading zeros) you will overwrite the end of the buffer.
We tested the fix, and, it appears to not affect other parts of the code that might not expect the brackets [] added.
Below the fix is shown with the old line commented out.
int pv_get_srcip(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) { str s; if(msg==NULL) return -1;
//s.s = ip_addr2a(&msg->rcv.src_ip); s.s = ip_addr2strz(&msg->rcv.src_ip); s.len = strlen(s.s); return pv_get_strval(msg, param, res, &s); }
Don.
This function is behind `$si` variable that is supposed to return plain source ip address. The `[]` around IPv6 is required in URIs, but the IP address itself is without `[]`.
The function is not used from other modules, therefore you use `$si` in your configuration file somewhere. Can you check that?
You can replace do:
``` if(af==INET6) { $var(si) = "[" + $si + "]"; } else { $var(si) = $si; } ```
Then use $var(si) instead of $si. Maybe a variable to get the source ip with square brackets would be useful, but that will be a new feature, $si will stay as it is, because it is useful in many cases.
Anyhow, it looks like an issue in kamailio.cfg, not in code.
@miconda Thank you so much for your advice! We will try your suggestion.
Btw, where is the issue with the null termination, the buffers seem to be defined with `max_address_len + 1`? Can you point in the source code (file path and line)?
Is there any reason for an IPv6 address string without brackets? Really, any IPv6 address floating around in text format without the brackets is a danger, and will require extra case switch or if-then-else. It might be good to eliminate functions that create the IP address strings without brackets. The code also does not use the standard system call to convert IP addresses to string, and gives a legal, but non-standard string. We will take a look at your suggested solution and provide feedback. We could also change the documentation if it is not yet used anywhere where it it expected without brackets.
The $si is one of the oldest variables, being in this form from beginning. Not sure about others, but I use it in many API requests or sqlops queries. Moreover, the definition of an IPv6 address is without brackets. The brackets are in the grammar of an address or URI. The $si won't change, I can bet is going to break a lot of configs. I added $siz to master branch that should return the ipv6 address in between brackets.
I am closing this one being a config issue, not a code problem. If you still think there is not enough space in the static buffer, open a new issue pointing in the code where you think the problem is.
Closed #1136.
My opinion is it is better to just change the existing code, and all existing installations will start working with IPv6 when they upgrade. It is also much simpler.
However, the following has been tested and also works to add a $ function that returns a correct IP string for IPv6:
The following would need to be added to the table in modules/pv/pv.c {{"sibr", (sizeof("sibr")-1)}, /* */ PVT_OTHER, pv_get_srcip_bracket, 0, 0, 0, 0, 0},
Then a new function in modules/pv/pv.c /* The following fundtion gets the source IP with brackets for IPv6 */ int pv_get_srcip_bracket(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) { str s; if(msg==NULL) return -1;
s.s = ip_addr2strz(&msg->rcv.src_ip); s.len = strlen(s.s); return pv_get_strval(msg, param, res, &s); }
Finally, a change to the config file line: append_hf("Path: sip:term@HOSTNAME:"+PORT+";nat=yes;received=sip:$sibr:$sp;$var(ws_transport)lr\r\n")
Ok, sorry, I posted about the same time. We will use your fix using "siz" as the function name. Not sure there is any place you need it without brackets . . . Thanks.
I have installations with IPv6 since 2002 and they work. I don't get what you mean by "all existing installations will start working with IPv6 when they upgrade".
And as I said, I use bare IPv6 in a lot of database tables that I query with sqlops or do HTTP API requests to external systems that expect standard IPv6 format.
Ok, if you are saying your configuration fix would correctly work to check the address type at run-time, then I guess it would work. Otherwise, it would be all IPv6 or all IPv4.
The fix you added that adds the brackets automatically at run-time for $siz is the best way actually, as then you do not need cryptic configuration files.
So, in any case, thanks very much for adding the new function that automatically adds the brackets when needed.
If I have permission from Verizon, I might like to contribute in the future. I can see a need to immediately parse the incoming messages and immediately reject any message with any part not formed correctly, rather than passing bad things through the code and crashing later. Also, would be good to switch to not use the old depricated system calls for networking (avoids dangerous mucking with the IP address structures and also avoid case switches for IPv4 vs IPv6). The new calls reduce the specific code for IPv4 vs IPv6 to an absolute minimum. I would also use the system calls to convert IP address to string instead of the hand written ones, etc.
Don.
-
Daniel-Constantin Mierla -
David Wang
-
davidxbwang
-
Donald Carr
-
doncarr
-
Victor Seva