netdev - Re: sky2, vlan and nat/masquerading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Mar 2011 18:55:17 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Christian Hesse <mail@...rm.de>
Cc:	netdev@...r.kernel.org
Subject: Re: sky2, vlan and nat/masquerading

On Mon, Mar 14, 2011 at 3:11 AM, Christian Hesse <mail@...rm.de> wrote:
> On Fri, 11 Mar 2011 16:39:02 -0800 Jesse Gross <jesse@...ira.com> wrote:
>> On Wed, Mar 9, 2011 at 9:15 AM, Christian Hesse <mail@...rm.de> wrote:
>> > Hello everybody,
>> >
>> > I have a Samsung NF310, running kernel 2.6.37.3 with a patch to make my
>> > ethernet controller work for vlans. It was discussed with the subject
>> > "sky2: convert to new VLAN model (v0.2)" and made it to to kernel tree
>> > with commit 86aa77854f47ab6f5f9c687507af1f57d2b89004.
>>
>> Does that commit actually change the behavior that you are seeing?  It
>> shouldn't be necessary for correct functionality.
>
> Plain 2.6.37 did not work at all. Received packets with vlan tag did not make
> it to the vlan interface but ended on the native ethernet interface iirc.

Hmm, that is very odd.  I don't see anything in the patch that would
change behavior in that regard.

>
>> Do you know if this
>> worked at some point in the past?
>
> This was the first time I used nat with two vlan interfaces.
>
>> > However it does not work properly, here are the details:
>> >
>> > * Switch with one trunk port and several port in corresponding vlan ports
>> > * Host connected to one of the vlan ports
>> > * Samsung Netbook (see above) connected to the trunk port.
>> >
>> > I get an IP address 192.168.x.x/24 via DHCP on interface connected to
>> > vlan 1. The interface connected to vlan 2 has 172.16.0.1/24 and serves
>> > addresses via DHCP. The system is set up to masquerade from 172.16.0.1/24.
>> >
>> > I can access my netbook from the host in vlan 2, however I can not access
>> > anything behind. The packets contain a broken vlan tag and the host does
>> > not recognize them.
>>
>> When you say "the host does not recognize them", what host do you
>> mean?  This is a different host on vlan 1?
>
> No, this is the host in vlan2.
> The packet contains the vlan tag with vid 0. It should not. The host discards
> it as it does not have a vlan interface with vid 0.
>
>> > I've attached a tcpdump log. Please take a look at the icmp echo request
>> > and reply packets, especially the last one.
>>
>> What do you mean by broken?  I only see one tag in the trace, which is
>> on the packet originating from 192.168.100.3 and it has a vid of 0.
>
> The tag itself is valid. But it should not be there as it comes from
> a native ethernet port.
>
>> Where was this trace captured?
>
> This trace was captured on the host in vlan2.
>
> Ok, let me explain step by step:

Thank you, this helps a lot in understanding your setup.

>
> * Host sends icmp echo request (172.16.0.21 -> 192.168.100.3) to router
>  172.16.0.1, the packet is untagged.
> * Switch receives the packet on native interface with vid 2, tags it and sends
>  it to the trunk)
> * Netbook receives the packet from trunk, untags it an queues it to vlan
>  interface 2.
> * Netbook nats the packet (192.168.x.140 > 192.168.100.3), tags it with vlan
>  2 and sends it to the trunk.

For clarity, I'm assuming that this is supposed to be vlan 1?

> * Switch receives the packet from trunk, untags it and sends it to native
>  interface with vlan 1.
> * The packet and its answer (192.168.100.3 -> 192.168.x.140) make their way
>  through the network.
> * Switch receives the icmp echo reply on native interface with vlan 1, tags
>  it and sends it to the trunk
> * Netbook receives the packet from trunk, untags it an queues it to vlan
>  interface 1.
> * Netbooks restores the original addresses from nat (192.168.100.3 ->
>  172.16.0.21), _tags_it_with_vlan_0_, tags it with vlan 2 and sends it to the
>  trunk

Can you capture a packet trace on the netbook's Ethernet interface to
see what it thinks it is sending?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html