FS#15747 - [kismet] kismet_client - blank

Attached to Project: Arch Linux
Opened by orbisvicis (orbisvicis) - Friday, 31 July 2009, 19:25 GMT
Last edited by Allan McRae (Allan) - Friday, 16 November 2012, 11:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jürgen Hötzel (juergen)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
When I start kismet_client I am presented with a blank screen (whether or not kismet_server is running)


Additional info:
extra/kismet 2009_06_R1-1
* with a pristine/unchanged kismet.conf file
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 16 November 2012, 11:31 GMT
Reason for closing:  Upstream
Additional comments about closing:  Upstream issue - although no-one admits it is theirs...
Comment by Laszlo Papp (djszapi) - Saturday, 07 November 2009, 21:02 GMT
Status ? Can you show any log files ? Wifi connection is okay ?
Comment by orbisvicis (orbisvicis) - Tuesday, 17 November 2009, 18:21 GMT
I've attached the kismet_ui.conf file automatically created by kismet in ~/.kismet
I am presented a blank screen whether or not I run kismet_client as root.
In all cases, control-c causes the client to disconnect (the only time I can get letters to appear on the kismet_client screen)
After disconnecting, kismet_server reports "ERROR: TCP server client read() ended for 127.0.0.1"
Possibly I thought this could be caused by kismet_server being not properly configured to capture packets. So I manually create a monitor interface (after disabling networkmanager) and modify the ncsource line in /etc/kismet.conf. Now kismet_server reports detecting networks and decrypting data, but kismet_client is still blank. The /var/log/Kismet*.{alert,gpsxml,netxml,nettxt,pcapdump} are all normal (they have nothing to do with the kismet_client interface).
Also, kismet_client does not report anything out of the ordinary. No log files are created at ~/.kismet.
Also, running kismet as root (instead of separating the process into kismet_server/kismet_client) does not work properly - no server is created, only a client.

.. So, this is about as much information as I have
Comment by orbisvicis (orbisvicis) - Monday, 15 March 2010, 18:16 GMT
well, now that I'm actually trying to use kismet ... I've learned it's because of xterm. Not sure why yet, the 256 color test scripts work fine (all colors visible)
Comment by orbisvicis (orbisvicis) - Monday, 15 March 2010, 18:24 GMT
has to do with:
xterm*termName: xterm-256color
Comment by orbisvicis (orbisvicis) - Monday, 15 March 2010, 23:16 GMT
This is a curses/kismet problem. I would file as upstream.
Comment by Greg (dolby) - Friday, 04 March 2011, 05:46 GMT
Still a problem? News from upstream kismet?
Comment by Jeff Cook (cookiecaper) - Saturday, 12 March 2011, 07:59 GMT
This must have resurfaced recently as I'm also getting blank Kismet interfaces now on two separate machines, and I know they were working in 2010.
Comment by Jeff Cook (cookiecaper) - Saturday, 12 March 2011, 08:02 GMT
Confirmed that a downgrade to ncurses 5.7-4 from the Arch Rollback Machine fixes the blanked text problem for me.
Comment by Greg (dolby) - Saturday, 12 March 2011, 11:52 GMT
https://www.kismetwireless.net/Forum/General/Messages/1299596777.8878591

edit: Although this has been open since 2009 so its not an ncurses 5.8 issue. Has anyone tried Kismet-2011-01-R1?
edit2: @Jeff Cook: your bug is  FS#23190 
Comment by Maciej Sitarz (macieks2) - Friday, 22 April 2011, 15:56 GMT
I tried kismet from testing, current and AUR but all of them are unusable.
testing/kismet 2011_03_R2-1
extra/kismet 2010_07_R1-1
kismet-full-svn-3137-1

I just get a black console, with dark grey text saying: "Dark grey text".
Comment by Maciej Sitarz (macieks2) - Friday, 22 April 2011, 18:14 GMT
As a workaround I switch from TERM=xterm-256color to TERM=xterm-color.
Works for me.
Comment by Greg (dolby) - Thursday, 28 April 2011, 20:43 GMT
Did you notify upstream that kismet doesnt work with 256 coloured terminals?
Comment by orbisvicis (orbisvicis) - Thursday, 05 May 2011, 05:21 GMT
I spoke to one of the devs on irc, freenode/#kismet. According to them the terminfo package is broken, a problem with "/usr/share/terminfo/x/xterm-256color" which is why TERM="xterm-color" works. Also the "offending grey color" will be removed from the default color scheme; which I think means resolving the illegible/hidden text - for people with issues when TERM="xterm-color".

Anyway, can anyone confirm that the terminfo package is broken, as well as provide knowledge towards fixing it?
Comment by Allan McRae (Allan) - Sunday, 16 October 2011, 00:17 GMT
removing myself from assignees... if it is a genuine ncurses/terminfo bug as the kismet devs claim and it actually gets reported to ncurses upstream and it gets fixed, then reassign me...
Comment by Swift Geek (swiftgeek) - Sunday, 15 July 2012, 06:46 GMT
Please add this:
TERM=`echo $TERM | sed "s/-256color//;s/+256color//"`

to /usr/bin/kismet below this section:
prefix=/usr
exec_prefix=${prefix}
ETC=/etc
BIN=${exec_prefix}/bin
Comment by Jelle van der Waa (jelly) - Saturday, 28 July 2012, 13:39 GMT
This problem only exists when using -256color TERM variables?
since xterm , xterm-color works fine, but screen-256color seems to break.
Comment by Swift Geek (swiftgeek) - Saturday, 28 July 2012, 14:34 GMT
yes ;) (I can confirm for vte xterm urxvt and screen/tmux)

Loading...