Open GoogleCodeExporter opened 8 years ago
I can confirm this for svn308 on linux using a kismet dump file as a source as
well.
pyrit -r kismet*.dump -o /home/otkaz/2WIRE772.cap stripLive
Pyrit 0.4.1-dev (svn r308) (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Parsing packets from 'kismet-Apr-23-2011-1.dump'...
1/1: New AccessPoint 00:1a:70:ec:df:41 ('jay')
2/2: New AccessPoint 68:7f:74:29:35:07 ('FastFish-guest')
3/3: New AccessPoint 68:7f:74:29:35:06 ('FastFish')
4/4: New AccessPoint 00:13:10:97:17:24 ('Home Router')
5/5: New AccessPoint 00:1f:33:e9:a1:7e ('2WIRE1019')
6/6: New AccessPoint 00:25:3c:d5:61:69 ('2WIRE383')
7/7: New AccessPoint 00:1d:5a:17:f2:59 ('2WIRE772')
8/8: New AccessPoint 00:22:a4:d3:9b:f1 ('2WIRE081')
8/9: New Station 00:1e:64:53:9d:f8 (AP 00:1d:5a:17:f2:59)
9/10: New AccessPoint 00:21:7c:78:ad:f9 ('2WIRE171')
9/11: New Station 00:21:6a:66:67:52 (AP 00:1d:5a:17:f2:59)
10/12: New AccessPoint 00:25:3c:60:51:d9 ('Sayers')
11/13: New AccessPoint 00:21:7c:24:b6:01 ('2WIRE137')
12/14: New AccessPoint 34:ef:44:67:26:31 ('2WIRE426')
13/15: New AccessPoint 00:1d:5a:3d:e3:29 ('2WIRE104')
14/16: New AccessPoint 3c:ea:4f:c1:a6:f9 ('2WIRE039')
15/19: New AccessPoint 00:21:91:04:4c:c7 ('gb123')
16/21: New AccessPoint 00:25:3c:5e:a2:01 ('2WIRE622')
17/30: New AccessPoint c0:83:0a:eb:5d:89 ('UVERSE731')
18/39: New AccessPoint 00:21:7c:94:6d:21 ('2WIRE169')
19/52: New AccessPoint 00:24:01:3f:85:f8 ('candace')
20/193: New AccessPoint 00:24:36:aa:de:9b ('Apple Network aade9c')
21/309: New AccessPoint 00:21:7c:a5:73:61 ('031wire')
21/310: New Station 00:20:00:3f:74:e3 (AP 00:21:7c:a5:73:61)
21/349: New Station 7c:61:93:02:d8:6b (AP 00:1d:5a:17:f2:59)
21/836: New Station 4c:0f:6e:0f:d0:da (AP 00:21:7c:78:ad:f9)
22/2634: New AccessPoint 00:26:50:45:07:f9 ('2WIRE904')
22/3211: New Station 00:21:6a:65:86:c2 (AP 00:1d:5a:17:f2:59)
22/3443: New Station 00:1a:70:ea:5a:0c (AP 00:1d:5a:17:f2:59)
Traceback (most recent call last):
File "/usr/local/bin/pyrit", line 6, in <module>
pyrit_cli.Pyrit_CLI().initFromArgv()
File "/usr/local/lib/python2.6/dist-packages/pyrit_cli.py", line 117, in initFromArgv
func(self, **options)
File "/usr/local/lib/python2.6/dist-packages/pyrit_cli.py", line 165, in new_f
f(*args, **kwds)
File "/usr/local/lib/python2.6/dist-packages/pyrit_cli.py", line 582, in stripLive
parser.parse_pcapdevice(pckt_rdr)
File "/usr/local/lib/python2.6/dist-packages/cpyrit/pckttools.py", line 696, in parse_pcapdevice
for pckt in reader:
File "/usr/local/lib/python2.6/dist-packages/cpyrit/pckttools.py", line 589, in next
pckt = self.read()
File "/usr/local/lib/python2.6/dist-packages/cpyrit/pckttools.py", line 577, in read
r = _cpyrit_cpu.PcapDevice.read(self)
IOError: libpcap-error while reading: truncated dump file; tried to read 122
captured bytes, only got 63
Original comment by lsell...@gmail.com
on 24 Apr 2011 at 3:38
For dumpfiles on the disk (comment #1) there is nothing we can do about this.
The dump is truncated and libpcap is unable (in fact: unwilling) to read from
it and pass the truncated data upstream. The only thing that we could so is to
close the file and consider it an EOF-situation. This however would leave the
user without the information that the original file is truncated. It *is* an
error and it is treated as one.
For live-captures (comment #0): I will further investigate if we can at least
work around this problem. It is an error on the driver's side to let a partial
packet leak to userspace instead of blocking the I/O-call.
Original comment by lukas.l...@gmail.com
on 24 Apr 2011 at 8:23
ahh my first time using the stripLive command guess I misunderstood the
description of it on the wiki. Put my card into monitor mode and ran
pyrit -r mon0 -o /home/otkaz/2WIRE772.cap stripLive
Everything works as expected. Thanks!
Original comment by lsell...@gmail.com
on 25 Apr 2011 at 4:15
Original issue reported on code.google.com by
nikf...@gmail.com
on 16 Apr 2011 at 11:41