Odd webGui issue
-
Not really sure about that one. I haven't noticed it. Try firefox and see if it does the same.
-
Ok - I've got the main index.php page up on firefox and will leave it there a while to see if it happens in this browser also.
Just for kicks, I'll do the same with Safari.
-
Remember, each open browser uses AJAX. Don't overload your poor 266 :)
-
I'm not doing too much online now anyhow.. :)
So far, both Omniweb and Safari have given me the text rendering of that screen since my last post. Firefox hasn't yet, so I'll give it some more time.
-
Well, Firefox has been refreshing away for hours now without a problem…
I can't understand why I didn't see this issue before when I used Omniweb with my PC-based install of pfSense.
-
I have thought of one other change that might be related. I believe that I was using HTTP while using the PC version of pfSense, but I switched to HTTPS either just before or just after switching to the embedded version.
I've reverted to HTTP for the webGui and am testing now with Omniweb…
-
Ok - It's been refreshing on the index page all night and hasn't gone into the "plain text" rendering of it, so I'm thinking it has something to do with Safari's SSL.
I'll probably just to run it in HTTP mode, since I will only remotely get into the box via SSH, plus SSL takes more processing power for each request.
-
I use SSL + Safari all the time and I have never seen this problem. It sounds like its even more isolated than this.
Wish we had a way to reproduce it every time, I really have no idea what extra text is being injected into the HTTP(s) stream.
-
Actually, I did some Ethereal traces…
It looks like the 1f1a is the content length in hex. I say this because for an AJAX call, the number there is 19... 19 hex is 25 decimal, which is the size of the content of the AJAX response. (The line after that is a 0)
Now, previously I've mostly done traces of IIS web applications. With IIS, the last line of the response header specifically states "Content-length:" and the number there appears to be in decimal.
I quickly performed a few traces of an apache server, and it too does not have the "Content-length" header and after the closing HTML tag, there is also a zero. It looks like lighttpd is adhering to the standard used by Apache.
The information just above and below the content looks like it's just fine.
So, I did some more looking.. Days before I switched to embedded, I backed-up my config.xml file. In it, I was using SSL, so the problem really didn't appear until I started using pfSense on my Soekris...
-
Oh thats strange. I have a 4801 here as my backup carp node and I've never noticed it with Firefox. Let me fire up Safari and run it for a bit on my backup node.
-
A Mac user too? Great - Just park it on the index.php page, as that is the one that I could most readily recreate the issue on. With both Omniweb and Safari (on the index page), the problem recreated itself within 10 minutes or so (though seemed to happen faster on Omniweb, but that could just be a coincidence).
I'm using an Intel iMac.
-
I let it run for a good couple of hours last night and it never did anything strange. Strange.
-
Well, I re-enabled SSL and within minutes of parking Omniweb on the index page it happened again… Very strange...
-
I started looking at my pfSense webGui today to troubleshoot something and this issue jumped right up at me again… The only other odd thing about my installation is that my Soekris has a dual port NIC (sis) in the PCI slot and I'm using 4 of the 5 NICs. (WAN, LAN, DMZ, and WIRELESS segments)
I've enabled polling on the NICs, as I thought this might help, especially if the issue is related to processor load. (but I'm not even sure if SIS is supported for that feature)
Other than that, in looking through a config.xml file, I'm not really doing anything unusual... I'm running traffic shaping between my LAN and WAN interfaces (mainly for Vonage VoIP), running DHCP on the three inside interfaces, running zoneedit DynDNS, and that's about it...
Paul
-
Well, that's the only change I've made and I'm not seeing the issue now… I've left it overnight on the index.php page and it hasn't been a problem since...
-
Ok - I spoke too soon… It still happened, but it took much longer than it previous did... So, I'm back to the drawing board on this problem... I may just drop back to not using SSL since that seems to get around the problem for me...