Comments (17)
Not currently being worked on. Feel free to submit a patch when you're ready.
Original comment by [email protected]
on 24 Mar 2010 at 3:10
from dpkt.
I just committed support for decoding MPLS labels, Cisco ISL VLAN tags, and
802.2 LLC
fields, but not for encoding them. Feel free to post what code you have and we
can try
to adapt it, if you want.
Original comment by dugsong
on 26 Mar 2010 at 3:06
- Changed state: Accepted
from dpkt.
dugsong: Yes I think I saw that. My code extends Ethernet class to create one
which
is adds an extra header to tag the packet. (After all, all it needs is an extra
4
bytes after the ethernet header). Currently it's extremely crude so I
definitely want
to tidy it up.
Also I'm not sure using a subclass is necessarily the best idea, but I couldn't
see a
way to make __hdr__ in Ethernet be different depending on if the packets are
meant to
be tagged or not.
Original comment by [email protected]
on 26 Mar 2010 at 9:19
from dpkt.
Meh, here we go so far.
Like I say, it's extremely crude and was just something I knocked up as I
needed to
quickly send out some VLAN tagged packets. It's by no means the best solution. I
really hope to get some more time to look at it soon.
Original comment by [email protected]
on 26 Mar 2010 at 9:33
Attachments:
from dpkt.
So, the true fix for this...
The problem is that __hdr__ can't be dynamic depending on some condition. For
VLAN
tagged packets we need __hdr__ to be 4 bytes longer, if we've selected the
packet to
be tagged. So, we'd need __hdr__ to be a function which returns the headers.
Or we stick with the idea of my patch and have a separate class for it. That's
not
all that bad and it works and stays with the same paradigm that dpkt already
has.
What do you think?
Original comment by [email protected]
on 30 Mar 2010 at 8:23
from dpkt.
Hello,
Instead of modifying ethernet.py, why not add a new script for ieee802.1q
header? By
doing that all one has to do is construct ieee802.1q header and pass it to
ethernet
as it's data. I am attaching the script that I created (ieee8021q.py) along
with this
comment. I have tested it and it does serve the purpose; attaching the test
script(tag150_rarpRequest.py) that makes use of my ieee8021q.py script.
What do you all think?
Original comment by [email protected]
on 2 May 2010 at 9:06
Attachments:
from dpkt.
Sounds like a good idea to me. Although it feel like it should really be in
Ethernet.py. We need to form the VLAN
header field properly.
Original comment by [email protected]
on 3 May 2010 at 11:10
from dpkt.
I do agree about the fact that we need to form the VLAN header field properly.
I am
still not able to find a way to set Priority and CFI field in 802.1q header.
May be
when passing the Tag I can set it. For instance if the tag is 4094 it's
equivalent
hex is 0x0ffe, so if I want priority as '1' instead of '0' I will be passing
0x2ffe
instead of 0x0ffe.
I think your suggested change does not take that into consideration either,
right?
That's one area where we are lacking flexibility.
Original comment by [email protected]
on 3 May 2010 at 5:29
from dpkt.
Sure, you're right that my patch doesn't handle the header correctly either.
The problem is that some bits of the
header are not easily packed using struct.pack. The current dpkt way of doing
things doesn't lend itself to this.
This is why I suggest the notion of the header field being generated by calling
a function.
Original comment by [email protected]
on 3 May 2010 at 8:00
from dpkt.
Forgive me if this is a stupid question. How do you extract the VLAN tag from
an Ethernet packet using dpkt? I understand that the 802.1q VLAN tag is 4
additional bytes in the header, that you can tell a packet is tagged because
bytes 13 and 14 contain 0x8100, and that moves the ethertype or length field
and the payload 4 bytes back.
Thank you
Original comment by [email protected]
on 27 Dec 2010 at 5:25
from dpkt.
Hi,
I have dpkt-1.7 and I don't see a way to extract vlan tags. Is there some way
to do it that someone can point me to?
Thanks
Original comment by [email protected]
on 11 Jan 2012 at 7:09
from dpkt.
Any progress on this?
If necessary, I'm willing to test/more code/unit tests.
How can I help?
Original comment by [email protected]
on 8 Jun 2012 at 2:10
from dpkt.
Does this issue been solved?
Original comment by [email protected]
on 6 Aug 2012 at 11:04
from dpkt.
Hey guys,
I'd like to propose this patch for vlans. The Vlan file and ethernet/llc patch
are included. I created it for a project I am working on, and everything is
running smoothly.
Vlan is just another layer, so you can create stack of Ethernet > IEEE8021Q >
IP.
This also supports 802.1QinQ natively which is nice.
Best,
Omid
Original comment by [email protected]
on 22 Jul 2013 at 7:33
Attachments:
from dpkt.
Hi Omid,
I also created a patch to support 802.1q headers in dpkt for a project I'm
working on.
It can be found here.
https://github.com/smutt/hexcap/blob/master/dpkt-read-only/dpkt/dot1q.py
https://github.com/smutt/hexcap/blob/master/dpkt-read-only/dpkt/ethernet.py
https://github.com/smutt/hexcap/blob/master/dpkt-read-only/dpkt/llc.py
ethernet.py also has changes for EDP and 802.3 SNAP.
A couple things I noticed about your patch.
1) It does not support writing.
2) I don't think your llc.py change will work. Check mine.
I don't care what dpkt eventually implements so long as it supports arbitrary
reading/writing of 802.1q headers at any layer of the packet. You mention
802.1ad(QinQ) which is good. There is also 802.1ah and various VPN services
that require 802.1q headers at different places in the packet. We shouldn't
assume 802.1q headers will always appear between the OSI data-link and network
layers.
Thanks,
Andrew
Original comment by [email protected]
on 24 Jul 2013 at 4:54
from dpkt.
Hello Andrew,
1. The patch I have included does supports writing, although the packing is
done at the final stage.
2. Thank you for the second point, I fixed the LLC. I guess I forgot all about
it while I was working on it.
About your third point,
While I agree that we shouldn't always assume that VLANs occur at L2, until
someone implements 802.1ah or something similar we should be fine using either
of our patches.
It all ends up whether anyone from the dpkt team would like to discuss this
issue.
Also, in your patch, Is there any reason that you don't enforce ethernet.type
when you have a vlan for next layer? E.g. if next layer is VLAN just enforce
0x8100 as ethtype.
It would be a really nice feature if there was a "back pointer" to upper
layers, just like pox.lib.packet, so some of the headers could automatically be
inferred from next layers.
E.g. When I create
ethernet() -> ip() -> udp()
I shouldn't need to set eth.type OR ip.p.
But I believe that's for another issue.
Best,
Omid
Original comment by [email protected]
on 1 Aug 2013 at 7:05
from dpkt.
Hi Omid,
> 1. The patch I have included does supports writing, although the packing is
done at the final stage.
[AM] Yes, I see it now.
> 2. Thank you for the second point, I fixed the LLC. I guess I forgot all
about it while I was working on it.
[AM] After looking more into it, I'm not even sure this matters. Perhaps in a
previous version of dpkt llc deconstruction was done in llc.py. But I can't
really see how llc.py gets called now. In my ethernet.py you can see I hacked
in support for 802.2 SNAP headers without touching llc.py. So I suspect llc.py
is not used anymore. Anyone from dpkt core team want to comment on this?
Bueller? Bueller?
> Also, in your patch, Is there any reason that you don't enforce ethernet.type
when you have a vlan for next layer? E.g. if next layer is VLAN just enforce
0x8100 as ethtype.
[AM] Not sure exactly what you mean. But be careful with "type" variable in
ethernet.py. If packet is LLC then ethernet.type actually refers to llc.pid
since it occupies the same offset as Ethernet II etype field.
> It would be a really nice feature if there was a "back pointer" to upper
layers, just like pox.lib.packet, so some of the headers could automatically be
inferred from next layers.
>
> E.g. When I create
>
> ethernet() -> ip() -> udp()
>
> I shouldn't need to set eth.type OR ip.p.
[AM] I hear what you're saying, but I kinda like the ability to create broken
packets with dpkt ;) Even when I create packets that cannot be read back into
dpkt successfully. I like the control.
Thanks,
Andrew
Original comment by [email protected]
on 5 Aug 2013 at 1:33
from dpkt.
Related Issues (20)
- [patch] dns.unpack_name improvements
- Common DNS RR types missing (patch included)
- FCS field on dpkt.ethernet.Ethernet HOT 4
- ssl.py TLSMultiFactory recursion causes stack overflow HOT 2
- IEEE80211 - Management Frame Subtype Support HOT 11
- IEEE 802.11 Packets - Random Parsing Crashing HOT 2
- cannot install HOT 3
- Example Request - Control Type Packets - Destination/Source Addresses HOT 4
- Unsupported Control Packet Subtypes HOT 3
- Time stamp problem in dpkt HOT 3
- ip total length header field not stored correctly
- Patch for /trunk/dpkt/pcap.py
- IPv6 doesn't handle ESP packets sanely
- multiple IPv6 extension headers of the same type aren't handled
- time and size of packet HOT 3
- Contents of the pkt is cut
- Record Fragmentation not handled in TLSMultiFactory(buf)
- lldp parser should stop at end tlv HOT 1
- [patch] Made http.py return ordered headers
- Check if a given dpkt-layer is part of the packet
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dpkt.