> Jerome Borsboom wrote: > > in4_pton converts a textual representation of an ip4 address into an > > integer representation. However, when the textual representation is of > > in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1, > > the function bails out when parsing the colon. > > > > It makes sense to allow the colon as a delimiting character without > > explicitly having to set it through the 'delim' variable as there can be > > no ambiguity in the point where the ip address is completely parsed. > > Furthermore, this function is indeed called from nf_conntrack_sip.c in > > this way to parse textual ip:port combinations which fails as stated above. > > > What about IPv6? in6_pton behaves similar and is also used by > nf_conntrack_sip. >
I have looked a bit more into this. The current behaviour of in6_pton is correct. As I said before, the colon is the separator within the IPv6 address and hence cannot be used to indicate a tcp or udp port. RFC 2732 states that when a tcp or udp port is included in an IPv6 URL it must be in the form '[IPv6-address]:port'. Here the rectangular braces make clear where the ip-address part ends and the port part begins. However, in[46]_pton are made to only change the representation of an ip-address and do not and should not bother about any other stuff like the rectangular braces in an IPv6 reference or the colon in an IPv4+port combination. My patch corrects the unnecessary error in the case in an IPv4-address+port combination. Related to this is the fact that nf_conntrack_sip wrongly assumes unbraced IPv6 adresses. RFC 3261 states that in all cases where an IPv6 reference is used, it should be enclosed in rectangular braces. Current behaviour is clearly wrong. I will see if I can come up with a patch to correct this error in nf_conntrack_sip. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
