Post by thread:[PIC] 414 Request-URI Too Long: Buffer overflow de

I'm occasionally getting this message from the TCP/IP stack. It seems to happen more if I use a domain name to reach the PIC32 web page as opposed to using an IP address directly. Microchip Forums (which are looking very strange today) discuss this error message on a redirect, but not on a initial access of the page. I'm running the Microchip Solutions library version 2010-10-19, which appears to be the latest ( www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 ). Any ideas as to how to avoid this error message? THANKS! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available

On Fri, May 20, 2011 at 3:37 PM, Harold Hallikainen <spam_OUTharoldTakeThisOuThallikainen.org> wrote: > I'm occasionally getting this message from the TCP/IP stack. It seems to > happen more if I use a domain name to reach the PIC32 web page as opposed > to using an IP address directly. Microchip Forums (which are looking very > strange today) discuss this error message on a redirect, but not on a > initial access of the page. > > I'm running the Microchip Solutions library version 2010-10-19, which > appears to be the latest ( > www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 > ). > > Any ideas as to how to avoid this error message? > > THANKS! > > Harold > I don't mean to be a smart-ass here - but use a shorter URI? -- Martin K

{Quote hidden}> On Fri, May 20, 2011 at 3:37 PM, Harold Hallikainen > <.....haroldKILLspam@spam@hallikainen.org> wrote: >> I'm occasionally getting this message from the TCP/IP stack. It seems to >> happen more if I use a domain name to reach the PIC32 web page as >> opposed >> to using an IP address directly. Microchip Forums (which are looking >> very >> strange today) discuss this error message on a redirect, but not on a >> initial access of the page. >> >> I'm running the Microchip Solutions library version 2010-10-19, which >> appears to be the latest ( >> www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 >> ). >> >> Any ideas as to how to avoid this error message? >> >> THANKS! >> >> Harold >> > > I don't mean to be a smart-ass here - but use a shorter URI? > That does work fine. If I do the URI as http://192.168.1.159 , it works fine. But sometimes we want to reach it using DNS. So, http://example.com:8081 often, not always, returns the buffer overflow error. It SEEMS like the size of the buffer should be set somewhere in the code, but I'm not finding it. A search on the error message returns an array of error messages, so it's difficult to determine the code that is sending it. Thanks! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available

On 5/20/2011 5:30 PM, Harold Hallikainen wrote: {Quote hidden}> >> On Fri, May 20, 2011 at 3:37 PM, Harold Hallikainen >> <haroldKILLspamhallikainen.org> wrote: >> >>> I'm occasionally getting this message from the TCP/IP stack. It seems to >>> happen more if I use a domain name to reach the PIC32 web page as >>> opposed >>> to using an IP address directly. Microchip Forums (which are looking >>> very >>> strange today) discuss this error message on a redirect, but not on a >>> initial access of the page. >>> >>> I'm running the Microchip Solutions library version 2010-10-19, which >>> appears to be the latest ( >>> www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 >>> ). >>> >>> Any ideas as to how to avoid this error message? >>> >>> THANKS! >>> >>> Harold >>> >>> >> I don't mean to be a smart-ass here - but use a shorter URI? >> >> > That does work fine. If I do the URI as http://192.168.1.159 , it works > fine. But sometimes we want to reach it using DNS. So, > http://example.com:8081 often, not always, returns the buffer overflow > error. It SEEMS like the size of the buffer should be set somewhere in the > code, but I'm not finding it. A search on the error message returns an > array of error messages, so it's difficult to determine the code that is > sending it. > > Thanks! > > Harold > > > > http://192.168.1.159 defaults to port 80? http://example.com:8081 is a on port 8081?

> > > > That does work fine. If I do the URI as http://192.168.1.159 , it works > fine. But sometimes we want to reach it using DNS. So, > http://example.com:8081 often, not always, returns the buffer overflow > error. It SEEMS like the size of the buffer should be set somewhere in the > code, but I'm not finding it. A search on the error message returns an > array of error messages, so it's difficult to determine the code that is > sending it. > > Thanks! > > Harold > > Is the overflow before or after the DNS query? I would think a malformed DNS response could legitimately overflow the buffer. It shouldn't, but.... Can you retrieve from http://198.162.1.159/arbitrarysubfoldernametomakeitlong/ ? How about a really short domain name? IBM.com ,AA.com or some such? -Denn

{Quote hidden}>> >> >> >> That does work fine. If I do the URI as http://192.168.1.159 , it works >> fine. But sometimes we want to reach it using DNS. So, >> http://example.com:8081 often, not always, returns the buffer overflow >> error. It SEEMS like the size of the buffer should be set somewhere in >> the >> code, but I'm not finding it. A search on the error message returns an >> array of error messages, so it's difficult to determine the code that is >> sending it. >> >> Thanks! >> >> Harold >> >> > > > Is the overflow before or after the DNS query? I would think a malformed > DNS > response could legitimately overflow the buffer. It shouldn't, but.... > > Can you retrieve from > http://198.162.1.159/arbitrarysubfoldernametomakeitlong/ ? > How about a really short domain name? IBM.com ,AA.com or some such? > > -Denny > -- The error message is generated by the HTTP server in the Microchip TCP/IP stack. I can find the text there, but am not sure where it is being sent from. This URL (which is pretty long and is on our internal network) works reliably: http://192.168.1.155/log.cgi?rn=288&n=100&GuiTz=-25200&GuiTzName=Pacific%20Daylight%20Time&DST=1 A shorter URL, which goes through a NAT router, works sometimes, and sometimes returns the URI too long message: http://uslinc.com:8081/ This URI is, of course, considerably shorter than the first one, but I have never seen the first one fail. Thanks! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available

{Quote hidden}> The error message is generated by the HTTP server in the Microchip TCP/IP > stack. I can find the text there, but am not sure where it is being sent > from. > > This URL (which is pretty long and is on our internal network) works > reliably: > > http://192.168.1.155/log.cgi?rn=288&n=100&GuiTz=-25200&GuiTzName=Pacific%20Daylight%20Time&DST=1 > > A shorter URL, which goes through a NAT router, works sometimes, and > sometimes returns the URI too long message: > > http://uslinc.com:8081/ > > This URI is, of course, considerably shorter than the first one, but I > have never seen the first one fail. > > Thanks! > > Harold > > > Can you stick Wireshark on the subnet the PIC is attached to? Maybe that will show how the requests differ when they reach the PIC.

On Fri, 20 May 2011, Harold Hallikainen wrote: {Quote hidden}> >> On Fri, May 20, 2011 at 3:37 PM, Harold Hallikainen >> <.....haroldKILLspam.....hallikainen.org> wrote: >>> I'm occasionally getting this message from the TCP/IP stack. It seems to >>> happen more if I use a domain name to reach the PIC32 web page as >>> opposed >>> to using an IP address directly. Microchip Forums (which are looking >>> very >>> strange today) discuss this error message on a redirect, but not on a >>> initial access of the page. >>> >>> I'm running the Microchip Solutions library version 2010-10-19, which >>> appears to be the latest ( >>> www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 >>> ). >>> >>> Any ideas as to how to avoid this error message? >>> >>> THANKS! >>> >>> Harold >>> >> >> I don't mean to be a smart-ass here - but use a shorter URI? >> > > That does work fine. If I do the URI as http://192.168.1.159 , it works > fine. But sometimes we want to reach it using DNS. So, > http://example.com:8081 often, not always, returns the buffer overflow > error. It SEEMS like the size of the buffer should be set somewhere in the > code, but I'm not finding it. A search on the error message returns an > array of error messages, so it's difficult to determine the code that is > sending it. (not knowing much about this code but trying to help anyway) Can't you just get the function that is outputing the 414 message to check that it is being asked to handle a 414 error and in that case print the return address of the function (maybe even just dump part of the runtime stack so you can unwind the call path). Regards Sergio Masc

Harold Hallikainen wrote: > This URL (which is pretty long and is on our internal network) works > reliably: > > 192.168.1.155/log.cgi?rn=288&n=100&GuiTz=-25200&GuiTzName=Pacific%20Daylight%20Time&DST=1 > > A shorter URL, which goes through a NAT router, works sometimes, and > sometimes returns the URI too long message: > > http://uslinc.com:8081/ > > This URI is, of course, considerably shorter than the first one, but I > have never seen the first one fail. Is it possible that in the server's TCP/IP stack, ports 80 and 8081 use different sets of buffers? -- Dave Twee

part 1 1650 bytes content-type:text/plain; charset="us-ascii" (decoded quoted-printable) On Fri, May 20, 2011 at 12:37:14PM -0700, Harold Hallikainen wrote: > To: Pic List <EraseMEpiclistspam_OUTTakeThisOuTmit.edu> > Subject: [PIC] 414 Request-URI Too Long: Buffer overflow detected > User-Agent: SquirrelMail/1.4.20-2.fc11 > > I'm occasionally getting this message from the TCP/IP stack. It seems to > happen more if I use a domain name to reach the PIC32 web page as opposed > to using an IP address directly. Microchip Forums (which are looking very > strange today) discuss this error message on a redirect, but not on a > initial access of the page. > > I'm running the Microchip Solutions library version 2010-10-19, which > appears to be the latest ( > www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 > ). > > Any ideas as to how to avoid this error message? > Just define HTTP_MAX_DATA_LEN to something enough large. If you don't define it, it will be defined in Microchip/Includes/TCPIP Stack/HTTP2.c and default to 100, that mean an uri can't be larger than 100 chars (totally). -- Franco (nextime) Lanza Busto Arsizio - Italy SIP://casaspam_OUTcasa.nexlab.it NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- part 2 181 bytes content-type:text/plain; name="ATT00001.txt" (decoded base64) -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at mailman.mit.edu/mailman/listinfo/piclist

> > Just define HTTP_MAX_DATA_LEN to something enough large. > > If you don't define it, it will be defined in Microchip/Includes/TCPIP > Stack/HTTP2.c and default to 100, > that mean an uri can't be larger than 100 chars (totally). Thanks to all that have commented! This looks like what I'm looking for. Because all the message strings are in an array at the beginning of HTTP2.c, it is difficult to determine what code is actually outputting that string. But, this HTTP_MAX_DATA_LEN looks interesting. I'll give that a try. THANKS! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available

This is the first time I have seen this on a PIC but it is a common error if the URI processing is not done correctly. Taking a wild stab in the dark I'd start looking at the hostname processing. Not saying this is your problem but I have seen instances where people assume the URI is always going to be an IP address so simply count the number of '.' before trying to process the path. If this is what is happening the you could get a 414 because it could walk off the end of the string before finding the last '.'.. I've seen comments about using Wireshark but this is internal to the PIC so all you are going to see is the 414 response which is not going to tell you any more than what you know already. Anyway I have taken a peek in the Microchip code and I suspect your error is coming from HTTP_OVERFLOW is defined in HTTP2.h and is use three times. Might I suggest a break point at each place where it is used and take a look at the curHTTP structure. Alan Melia w: http://www.melmac.co.uk {Original Message removed}

On 5/21/2011 12:37 PM, Alan Melia wrote: > This is the first time I have seen this on a PIC but it is a common error if > the URI processing is not done correctly. Taking a wild stab in the dark > I'd start looking at the hostname processing. Not saying this is your > problem but I have seen instances where people assume the URI is always > going to be an IP address so simply count the number of '.' before trying to > process the path. If this is what is happening the you could get a 414 > because it could walk off the end of the string before finding the last '..'. > > I've seen comments about using Wireshark but this is internal to the PIC so > all you are going to see is the 414 response which is not going to tell you > any more than what you know already. > > I don't think the browser making the request is internal to the PIC. May be but don't think so. Wireshark the input side and see what the NAT and DNS are doing to the HTTP request. If one input works and the other doesn't then determining the difference in packets may help. chuck

Alan Melia wrote: > I've seen comments about using Wireshark but this is internal to the > PIC so all you are going to see is the 414 response which is not > going to tell you any more than what you know already. Wireshark could show you the URI the PIC is actually sending out with the request that elicts the 414 response. That could be illuminating in tracing down the bug. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Olin Lathrop wrote: > Alan Melia wrote: > >> I've seen comments about using Wireshark but this is internal to the >> PIC so all you are going to see is the 414 response which is not >> going to tell you any more than what you know already. >> > > Wireshark could show you the URI the PIC is actually sending out with the > request that elicts the 414 response. That could be illuminating in tracing > down the bug. > Indeed it would also show you what is in the request OTHER than the URI (since the same URI sometimes causes the request). In particular it will show you what changes between a successful request and a failed request. What it WON'T really help you with is finding out where in the code the error is generated so the buffer in question can be made bigger. My gut feeling is that this is a bad error message and it really means "request too large for buffer" (there is more to a HTTP request than the URL). I suspect the buffers were made very tight to fit in an 18F and were never expanded when the stack was ported to processors that actually have the memory to do it properly. > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. >