Closed GoogleCodeExporter closed 9 years ago
Got it -- I saw your note on issue 53 but only saw this one now.
Can you attach an Action frame packet? I'll look into adding the support for
action frames and a unit test for them.
Original comment by timur.al...@gmail.com
on 2 Jul 2014 at 5:13
I'll handle this one.
Original comment by timur.al...@gmail.com
on 2 Jul 2014 at 5:17
[deleted comment]
Charles, if you can, please attach packets on which the parser breaks for each
issue -- it makes it much easier to debug the code.
dpkt is an open source project and I think all of the maintainers/committers
are spending time on it on best effort basis. Unfortunately, sometimes issues
take a very long time to be resolved. Sometimes it can happen quite quickly. In
terms of the next release of dpkt, I'm not sure what the plan is. As far as I
know, not many changes have been made in the project.
Original comment by timur.al...@gmail.com
on 2 Jul 2014 at 5:39
That makes complete sense and I must say, this is one of the best Python
Pcap Libraries I've come across in my research. The members of your group
have done an amazing job.
I have created a new issue (#125) that has all my attached files for the
random crashing I mentioned in my last e-mail. If there is additional
information I can provide or something I can do to help, please let me
know.
Thanks again,
Charles
Original comment by kokopell...@gmail.com
on 2 Jul 2014 at 5:50
[deleted comment]
Please see the attached file "Capture-06302014.pcap".
Packet #'s 3375 and 3371 are both "Management --> Action" packets for which
there is no supporting structure in the 'ieee80211.py' source file for parsing
the packet.
Original comment by kokopell...@gmail.com
on 2 Jul 2014 at 6:45
Attachments:
Great! Thanks for the pcap file. I will look at adding action frame support
today.
Original comment by timur.al...@gmail.com
on 3 Jul 2014 at 11:24
Charles, I committed a number of changes to the trunk. Please check it out and
try it. You should be able to do the following now:
import dpkt
f = open('/home/timur/Downloads/Capture-06302014.pcap')
pc = dpkt.pcap.Reader(f)
for ts, buf in pc:
rt = dpkt.radiotap.Radiotap(buf)
ieee = rt.data
print ieee.type, ieee.subtype
Meaning, that you no longer need to manually parse the Radiotap header or to
explicitly call the IEEE80211 parser. This will also auto-detect the presence
of the FCS field (indicated in the RT header), which will be propagated to the
IEEE80211 parser. Let me know if this works/doesn't work for you.
Lastly, I also added support for one action frame category and one code:
BlockAck:Request and BlockAck:Response. I couldn't find the documentation on
the rest of the possible Action frames. I know there are a bunch, but without
it handy and no packets to look at, could not implement it.
Original comment by timur.al...@gmail.com
on 4 Jul 2014 at 6:49
So I just wanted to say that I imported the fixes for bugs #124 and #125
and it appears everything seems to parse correctly (at least creating
ieee80211 packets for each packet in the pcap file). Thank you so much for
all the help and support in getting my problems corrected!
On that note I am running into a problem when trying to parse RTS/CTS
packets. I'm trying to capture the destination and source addresses for the
RTS/CTS packets but I'm having trouble converting from a general 80211
packet to a specific RTS/CTS packet. I'm not sure if it's just me doing the
wrong thing....or if it's something else. Any general pointers you could
provide would be extremely helpful.
Thanks!
Original comment by kokopell...@gmail.com
on 7 Jul 2014 at 5:29
Submitted some sample code (and the problem) as issue #127.
Just requesting some example to help fill in the missing logic.
On Mon, Jul 7, 2014 at 1:28 PM, Charles Carnley <kokopelli23@gmail.com>
wrote:
Original comment by kokopell...@gmail.com
on 7 Jul 2014 at 7:19
Original issue reported on code.google.com by
kokopell...@gmail.com
on 1 Jul 2014 at 6:01