[PATCH] parse ip:port strings correctly in in4_pton

[PATCH] parse ip:port strings correctly in in4_pton

[Jerome Borsboom]

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.

Signed-off-by: Jerome Borsboom <j.borsboom@erasmusmc.nl>

--- linux-2.6.20/net/core/utils.c	2007-02-04 19:44:54.000000000 +0100
+++ linux-2.6.20/net/core/utils.c	2007-04-15 21:08:55.000000000 +0200
@@ -137,16 +137,16 @@
  	while(1) {
  		int c;
  		c = xdigit2bin(srclen > 0 ? *s : '\0', delim);
-		if (!(c & (IN6PTON_DIGIT | IN6PTON_DOT | IN6PTON_DELIM))) {
+		if (!(c & (IN6PTON_DIGIT | IN6PTON_DOT | IN6PTON_DELIM | IN6PTON_COLON_MASK))) {
  			goto out;
  		}
-		if (c & (IN6PTON_DOT | IN6PTON_DELIM)) {
+		if (c & (IN6PTON_DOT | IN6PTON_DELIM | IN6PTON_COLON_MASK)) {
  			if (w == 0)
  				goto out;
  			*d++ = w & 0xff;
  			w = 0;
  			i++;
-			if (c & IN6PTON_DELIM) {
+			if (c & (IN6PTON_DELIM | IN6PTON_COLON_MASK)) {
  				if (i != 4)
  					goto out;
  				break;

Re: [PATCH] parse ip:port strings correctly in in4_pton

[Patrick McHardy]

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.

Re: [PATCH] parse ip:port strings correctly in in4_pton

[Jerome Borsboom]

> 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.
> 

Don't think that in6_pton should be changed as a colon is the 
separator within the address. Maybe in6_pton should be changed to 
also parse IPv6 URI addresses of the form '[ipv6-addres]:port' which 
it currently cannot handle.

Re: [PATCH] parse ip:port strings correctly in in4_pton

[Jerome Borsboom]

> 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.