-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BGP (v4) Open typed packet failing to parse. #118
Comments
I have the same error |
data from https://packetlife.net/captures/protocol/bgp/
error thrown
same frame when opened using Wireshark is opened properly and shows capabilities |
ack. looking into this |
So after spending some time looking at this issue, it looks like the packet has multiple capabilities in one Optional Parameter, which the code is not able to handle. DetailsThe Open message packet has an optional parameter type called Capabilities (Parameter Type 2).
You can see this in the wireshark screenshot you posted, where the optional parameter length is 36 bytes, which includes 6 capabilities, but the current code when parsing Open parameters only consumes the first capability:
Even consuming this one capabilty has a bug while calculating the length, which is the bug you filed. Add a
Real FixSo the fix needs updating the code to parse all the mulitiple capability fields. The correct output should be:
Parsing the
and the corresponding unittest would then become:
PR coming with the changes. |
* Fixes #118 (please see issue for details) * Introduce `capabilities` property (for cases where there are >1 capablity) * Keep older `capability` property for backward compatibility * Added `__bgp10` unittest, which broke the original parser
From Mawr...@gmail.com on June 22, 2012 11:38:15
What steps will reproduce the problem? 1. Packet received was:
\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00'\x01\x04\xfd\xe8\x00\xb4\xc0\xa8\x02\x01\n\x02\x08\x01\x04\x00\x01\x00\x01\x02\x00
call dpkt.bgp.BGP(buf)
Raises exception:
Traceback (most recent call last):$Id: bgp.py 52 2008-08-25 22:22:34Z jon.oberheide $
File "bgp_dump.py", line 11, in
p = bgp.BGP(data)
File "/usr/local/lib/python2.7/site-packages/dpkt/dpkt.py", line 75, in init
self.unpack(args[0])
File "/usr/local/lib/python2.7/site-packages/dpkt/bgp.py", line 130, in unpack
self.data = self.open = self.Open(self.data)
File "/usr/local/lib/python2.7/site-packages/dpkt/dpkt.py", line 75, in init
self.unpack(args[0])
File "/usr/local/lib/python2.7/site-packages/dpkt/bgp.py", line 157, in unpack
param = self.Parameter(self.data)
File "/usr/local/lib/python2.7/site-packages/dpkt/dpkt.py", line 75, in init
self.unpack(args[0])
File "/usr/local/lib/python2.7/site-packages/dpkt/bgp.py", line 188, in unpack
self.data = self.capability = self.Capability(self.data)
File "/usr/local/lib/python2.7/site-packages/dpkt/dpkt.py", line 78, in init
raise NeedData
dpkt.dpkt.NeedData What is the expected output? What do you see instead? The expected output is that the packet is parsed, with the ROUTE REFRESH capability enabled. What version of the product are you using? On what operating system? #
On Ubuntu, but I don't think it's a platform dependent issue. Please provide any additional information below. I believe the cause to be is if the packet contains a zero-length capabilities (route refresh), the resulting data is 0, but it tries to unpack it anyways, causing the exception.
According to the RFC ( http://tools.ietf.org/html/rfc2918 ) the zero-length capabilities is expected.
A solution I came up with was to check if self.data is length 0, and if so, return before calling unpack. Added this to line 183 in bgp.py:
Original issue: http://code.google.com/p/dpkt/issues/detail?id=91
The text was updated successfully, but these errors were encountered: