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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 11 Mar 2011 16:39:02 -0800
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 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.  Do you know if this
worked at some point in the past?

> 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?

> 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.

Where was this trace captured?
--
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