kismet_log_devices_to_kml.py bugs?

[mo8Zomo0]

Hi!

https://github.com/kismetwireless/kismet/tree/master/log_tools shows at the end to use: --strongest-location but that seems now to be strongest point

usage: kismet_log_to_kml.py [-h] [--in INFILE] [--out OUTFILE] [--start-time STARTTIME] [--min-signal MINSIGNAL] [--strongest-point] [--title TITLE] [--ssid SSID]

Then if I try to use --min-signal -40 it fails with:

_./kismet_log_to_kml.py --in Kismet-20180331-17-33-02-1.kismet --strongest-point --min-signal -40  --out test2.kml_
Traceback (most recent call last):
  File "/root/git/kismet/log_tools/./kismet_log_to_kml.py", line 84, in <module>
    for row in c.execute(sql, replacements):
sqlite3.OperationalError: no such column: max_signal

At list at the end examples do not mention any --out, but not supplying it fails:

_./kismet_log_to_kml.py --in Kismet-20180331-17-33-02-1.kismet_ 
Traceback (most recent call last):
  File "/root/git/kismet/log_tools/./kismet_log_to_kml.py", line 138, in <module>
    kml.save(results.outfile)
  File "/usr/local/lib/python2.7/dist-packages/simplekml/kml.py", line 325, in save
    f = codecs.open(path, 'wb', 'utf-8')
  File "/usr/lib/python2.7/codecs.py", line 896, in open
    file = __builtin__.open(filename, mode, buffering)
TypeError: coercing to Unicode: need string or buffer, NoneType found

I am on: kismet# git log --pretty=format:'%h' -n 1 cd4d6a85 on a Raspbian GNU/Linux 9

[chris408]

I'm using a4f9c5f5 and when i try to export to KML I get: Exported 0 devices to test.kml

I had to change:

dev = json.loads(row[0])

to

dev = json.loads(str(row[0]))

And now I'm able to export devices properly. I don't know if this breaks something else, but I was able to export to KML and the import worked properly into Google Earth.

I would re-test this again as they've made some updates since you first posted this issue.

[felixth3cat]

Hi!

https://github.com/kismetwireless/kismet/tree/master/log_tools shows at the end to use: --strongest-location but that seems now to be strongest point

usage: kismet_log_to_kml.py [-h] [--in INFILE] [--out OUTFILE] [--start-time STARTTIME] [--min-signal MINSIGNAL] [--strongest-point] [--title TITLE] [--ssid SSID]

Then if I try to use --min-signal -40 it fails with:

_./kismet_log_to_kml.py --in Kismet-20180331-17-33-02-1.kismet --strongest-point --min-signal -40  --out test2.kml_
Traceback (most recent call last):
  File "/root/git/kismet/log_tools/./kismet_log_to_kml.py", line 84, in <module>
    for row in c.execute(sql, replacements):
sqlite3.OperationalError: no such column: max_signal

I have no idea if this was intended to be implemented, but that data is stored inside of a JSON value in the "device" column of the "devices" table in the DB, which means we cannot run a SQL query against the DB file for values greater than a certain amount. I can implement this functionality in python inside the script, and send a pull request if you would like, though.

At list at the end examples do not mention any --out, but not supplying it fails:

_./kismet_log_to_kml.py --in Kismet-20180331-17-33-02-1.kismet_ 
Traceback (most recent call last):
  File "/root/git/kismet/log_tools/./kismet_log_to_kml.py", line 138, in <module>
    kml.save(results.outfile)
  File "/usr/local/lib/python2.7/dist-packages/simplekml/kml.py", line 325, in save
    f = codecs.open(path, 'wb', 'utf-8')
  File "/usr/lib/python2.7/codecs.py", line 896, in open
    file = __builtin__.open(filename, mode, buffering)
TypeError: coercing to Unicode: need string or buffer, NoneType found

I am on: kismet# git log --pretty=format:'%h' -n 1 cd4d6a8 on a Raspbian GNU/Linux 9

Yeah, I noticed this too, maybe we can supply a default filename based on input filename?

[felixth3cat]

I'm using a4f9c5f5 and when i try to export to KML I get: Exported 0 devices to test.kml

I had to change:

dev = json.loads(row[0])

to

dev = json.loads(str(row[0]))

And now I'm able to export devices properly. I don't know if this breaks something else, but I was able to export to KML and the import worked properly into Google Earth.

I would re-test this again as they've made some updates since you first posted this issue.

I fixed this in pull request #112 ;-)