pcap parsing issue

[GoogleCodeExporter]

What steps will reproduce the problem?
import dpkt

f = open('C:\\Users\\engintop\\Desktop\\staj\\denemeler\\test3.pcap')
pcap = dpkt.pcap.Reader(f)

# load HTTP pcap file n' link to dpkt attributes

for ts,buf in pcap:
        eth = dpkt.ethernet.Ethernet(buf)
        ip = eth.data
        tcp = ip.data
        if tcp.dport == 80 and len(tcp.data) > 0:
                http_req = dpkt.http.Request(tcp.data)
        if tcp.sport == 80 and len(tcp.data) > 0:
                http_res = dpkt.http.Response(tcp.data)

# HTTP request parser

print "\r\n"

print "HTTP Request\r\n"
print tcp.dport
print http_req.method
print http_req.uri
print http_req.version
print http_req.headers

print "\r\n"
print "\r\n"

# HTTP response parser

print "HTTP Response\r\n"
print tcp.sport
print http_res.status
print http_res.reason
print http_res.version
print http_res.headers
print http_res.body

f.close() 

What is the expected output? What do you see instead?

my error message is :

if tcp.dport == 80 and len(tcp.data)> 0 :
AttributeError : 'ICMP' object has no attribute 'dport'

What version of the product are you using? On what operating system?

python 2.6
windows7 64 bit 

Please provide any additional information below.

how can i fix this problem ? 

Original issue reported on code.google.com by engn...@gmail.com on 3 Jul 2012 at 2:27

[GoogleCodeExporter]

Maybe, test3.pcap contained ICMP packet.

You should ignore what exclude TCP packet.

code example:

for ts,buf in pcap:
    eth = dpkt.ethernet.Ethernet(buf)
    if type(eth.data) != dpkt.ip.IP:
        print 'not ip packet.'
        continue
    ip = eth.data
    if type(ip.data) != dpkt.tcp.TCP:
        print 'not tcp packet.'
        continue
    tcp = ip.data
    if tcp.dport == 80 and len(tcp.data) > 0:
        http_req = dpkt.http.Request(tcp.data)
    if tcp.sport == 80 and len(tcp.data) > 0:
        http_res = dpkt.http.Response(tcp.data)

Original comment by ruy.su...@gmail.com on 6 Jul 2012 at 7:31

[GoogleCodeExporter]

Closing, as this is not actually a bug.

Original comment by timur.al...@gmail.com on 24 Aug 2012 at 9:47

• Changed state: Invalid