<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 February 2014 16:53, Simon Horman <span dir="ltr"><<a href="mailto:horms@verge.net.au" target="_blank">horms@verge.net.au</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe that the reason you are seeing a VLAN tagged packet come out is<br>
that you are sending a VLAN tagged packet in. This is because of<br>
eth_type(0x8100), which I believe should be eth_type(0x8847).</blockquote><div><br></div><div>I see, that makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The packet dump below starts with "40 45" after the MPLS label stack, but<br>
I believe it and all the data after it should be zero. This is because the<br>
input packet only has an L2 header followed by an MPLS LSE. This will be<br>
padded to 64 bytes with zeroes by OVS when it is received.<br></blockquote><div><br></div><div>Right, this is the type of thing that I knew was wrong. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the course of looking at this I realised there is a bug which can be<br>
exercised by a variant of this patch. The bug is that push_mpls() only<br>
updates the ethertype if the input packet is not MPLS. But this does not<br>
take into account that there are two MPLS ethertypes and an MPLS push may<br>
change a packet from one to another.<br>
<br>
I will post a patch that fixes that problem and adds a test-case for it.<br></blockquote><div><br></div><div>Glad that the patch had the intended effect, even if it was trivially wrong. Thanks for picking this up.</div></div>
</div></div>