IPTraf does not display unicode terminal graphics properly. (It's very possible iftop has a similar problem but I don't know if the fix is the same. If iftop is started in a unicode terminal/gnu screen session, iftop displays the same terminal graphics abnormality. Disabiling the unicode feature for the terminal resolves the problem.) Reproducible: Always For fixing, information can be found here: http://bugs.centos.org/view.php?id=2676 http://bugs.centos.org/print_bug_page.php?bug_id=2676 According to the above posts, the solution is to set locale within iptraf with: #include <locale.h> [...] setlocale(LC_ALL, ""); Pretty simple patch if anybody else has time to create the patch/diff!
roger, please, describe what problem do you experience. Also what iptraf version are you talking about. We already have this patch for very long time: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/iptraf/files/iptraf-3.0.0-setlocale.patch?rev=1.1&view=markup ... or what's wrong with this patch?
I just know, iptraf, as well as iftop, distributes problems displaying (ncurses) graphics when GNU screen is started using the unicode flag. ie. $ screen -DR -U vs. $ screen -DR (Took me awhile to find this problem with the GNU Screen -U flag)
Please attach screen shot. Also give me step by step instructions how to reproduce this problem, because I've tried iptraf inside screen many times but failed to see any problem.
Seen the problem on 2 or 3 diff boxes here. It's how I found the problem. ... attaching screenshot now.
Created attachment 165604 [details] GNU Screen with Urxvt & IPTraf using unicode GNU Screen with Urxvt & IPTraf using unicode What's causing this graphic/ncurses anomaly is "screen -U" switch. urxvt -g 125x61+200+0 -rv -sbt 15 -si -sk -sr \ -fn '-adobe-courier-medium-r-normal--17-120-100-100-m-100-iso10646-1' \ -n "GNU Screen: Localhost2" -title "GNU Screen: Localhost2" \ -e sh -c "screen -URD -S roger ; sleep 2s &"
This looks like font problem. Please, set your console to use e.g. terminus fonts. "emerge -va media-fonts/terminus-font" and then configure your terminal to use that. Does this fixes problem for you?
Already have terminus fonts installed... used: $ screen -URD -S roger ... and it looks even cr*ppier. Wanna screenshot? ;-) (If you must, I also tried w/o using "-S". ... I'm sure this is an issue directly related with the "screen -U" switch. I have several diff boxes here and use multiple types of terminals, all display similar stuff with the "-U" arg.) But when "screen -URD" is started via tty, it display ncurses IPTraf graphics just fine. Then I switch back to X, and the terminal is stuck at the small size, but does display ncurses graphics fine. (Attaching screenshot.)
Created attachment 165750 [details] Screen started in tty Started GNU Screen in tty using "screen -URD" and then went to X and got this. Displays graphics fine here... whether or not starting "screen -URD" actually uses the "-U" switch while in tty is questionable?
Verified tty drops the "-U" $ ps -ax |grep screen 1240 pts/0 S+ 0:00 screen -RD And starting with "-URD" in X $ ps -ax |grep screen 1447 pts/0 S+ 0:00 screen -URD (... some interesting stuff to note.)
Ah, now I got, what your are talking about. So if you start screen in console and then start iptraf inside screen, then detach screen session and attach it in X-terminal - iptraf window will be corrupted. But the same problem occurs if you start iptraf in X-terminal of one size e.g. in konsole with 80x24 size and then change size e.g. to 119x46: at this point iptraf still thinks that window still have same 80x24 size. This problem has nothing to do with screen and utf8. At this point somebody should sit and write patch for iptraf :)
Sorry. Forgot to delete "Screen started in tty" ... as that too was being run w/o the "-U" (unicode) flag for screen. (Slight anomaly & oversight on my part.) Simply put, running screen -RDU gives me the stated attached screenshot.
roger have you read what I wrote? This issue has nothing to do with screen.
No where did I state the problem was explicitly with screen. All I said was "screen -DRU" produces this problem on this box, as well as others here on my pentium3 network. Now if you're saying I'm getting handy with The Gimp at creating the attached Screenshot.png, all I can say is, thanks for the compliment.
I also said "delete" what I said about resizing or running screen -U within terminal & then resizing. I just did some more debugging. I finally was able to get "screen -URD" & iptraf running w/i the tty (console) without a corrupted display. I then switched to Xorg and ran "screen -URD" within XFCE terminal. I could have sworn iptraf display fine at this point. I ps -ax before and after to verfiy "screen -URD" was present (and not "screen -RD"), and it was "screen -URD". I then, again, detached went back to tty/console and ran screen -URD (reattaching) and iptraf was just fine and then detached. Switched back to Xorg and reattached using "screen -URD" within XFCE terminal and then this display bug with iptraf was present, including the screen of iptraf being resized to the size of tty/console, similar to the attached obsolete Screenshot-tty.png, but with a corrupted screen. (Golly. After all this typing, could have probably tried applying one of 'dem old patches & recompiled to see if it works.)
(In reply to comment #14) > (Golly. After all this typing, could have probably tried applying one of 'dem > old patches & recompiled to see if it works.) And again, may be I don't understand what you wrote here (English is not my native language after all) but I already stated (see comment 1), that the patches you told us about in comment 0 *are already applied* in iptraf. Or are you talking about some different patches? If so, then please attach them to this bug and I'll be happy to review them.
I understand. Well, I'm going to try to see if I can't further find the cause of this. In the process of setting up a Gentoo beta test box to build gcc-4.3, etc. If anybody has any other ideas, post them here.
Roger, could you check whether iptraf-ng (bug #305781) fixes this problem?
Ok. I checked by unmasking iptraf-ng and running it within a "screen -URD" session and then connecting to it from my other boxes. I'm not sure if I followed the testing scenario I described previously step-by-step, but to me this bug looks fixed now. No real corruption of screen graphics except for a few character spacing & color issues when moving/connection from other sized terminals. Marking as fixed?
