Issue 32 in dpkt: VLAN tagging of Ethernet frames

[codesite...@google.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

It would be great if there was support for VLAN tagging of Ethernet frames.
There seems to be support for understanding a tagged packet, but not for
actually tagging them.

I've roughly added support myself, but no where near ready for a patch. But
I will keep going and hopefully submit something.

I just wanted to lodge here in case it was already being worked on?

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Comment #1 on issue 32 by jon.oberheide: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

Not currently being worked on. Feel free to submit a patch when you're
ready.

[dp...@googlecode.com]

Updates:
Status: Accepted

Comment #2 on issue 32 by dugsong: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

[dp...@googlecode.com]

Comment #3 on issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

[dp...@googlecode.com]

Comment #4 on issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

Attachments:
vlan.patch 594 bytes

[dp...@googlecode.com]

Comment #5 on issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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?

[dp...@googlecode.com]

Comment #6 on issue 32 by pratik.mankad: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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?

Attachments:
ieee8021q.py 1004 bytes
tag150_rarpRequest.py 1.7 KB

--
You received this message because you are subscribed to the Google Groups "dpkt" group.
To post to this group, send email to dp...@googlegroups.com.
To unsubscribe from this group, send email to dpkt+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dpkt?hl=en.

[dp...@googlecode.com]

Comment #7 on issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

[dp...@googlecode.com]

Comment #8 on issue 32 by pratik.mankad: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

[dp...@googlecode.com]

Comment #9 on issue 32 by m...@galloway.me.uk: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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.

[dp...@googlecode.com]

Comment #10 on issue 32 by jeffsilverm: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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

[dp...@googlecode.com]

Comment #11 on issue 32 by rvaid...@gmail.com: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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

[dp...@googlecode.com]

Comment #12 on issue 32 by isaku.ya...@gmail.com: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

Any progress on this?
If necessary, I'm willing to test/more code/unit tests.
How can I help?

[dp...@googlecode.com]

Comment #13 on issue 32 by salvador...@gmail.com: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

Does this issue been solved?

[dp...@googlecode.com]

Comment #14 on issue 32 by eCyn...@gmail.com: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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

Attachments:
ethernet.patch 1.3 KB
llc.patch 424 bytes
ieee8021q.py 821 bytes

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[dp...@googlecode.com]

Comment #15 on issue 32 by sm...@depht.com: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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

[dp...@googlecode.com]

Comment #16 on issue 32 by eCyn...@gmail.com: VLAN tagging of Ethernet
frames
http://code.google.com/p/dpkt/issues/detail?id=32

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

[dp...@googlecode.com]

Comment #17 on issue 32 by sm...@depht.com: VLAN tagging of Ethernet frames
http://code.google.com/p/dpkt/issues/detail?id=32

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