On 05/02/14 23:18, Thorsten Bonck wrote:
> On Fri, May 02, 2014 at 08:14:40PM +0000, Peter J. Philipp wrote:
>> On Fri, May 02, 2014 at 09:14:16PM +0200, [email protected] wrote:
>>>> maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
>>>> where rl0 is connected and tag other vlans on the same port ...
>>>
>>> Sadly, that is not possible for me.
>>> rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
>>> a blackbox transparent bridge by my ISP.
>>> vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
>>> I could put a tagging switch in between rl0 and the bridge as a last
>>> resort, but for right now I am still looking for a reason why 5.4 works
>>> and 5.5 seems to answer to a wrong MAC.
>>>
>>> Looking through the changes from 5.4 I found "Stop defining
>>> SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
>>> pppoe(4)-specific ioctls and vice versa without smashing the stack of
>>> the caller". Is it possible my problem is somehow connected to that?
>>
>> Hello,
>>
>> I'd probably do a tcpdump -v -n -e -s 200 -X -i rl0 as well.. perhaps you
>> can see somewhere where the aa:aa:aa:aa:aa:aa is coming from. Perhaps there
>> is an offset logic error somewhere as the pppoe driver reads the PADO source
>> address from the mbuf etherheader which was prepended. If you can't make
>> out any AAAAAAAAAAAA's in the frame then that's further suspicous.
>
> After some staring at the dumped frames, I can describe the problem more
> detailed.
> Assume listed devices to have following macs:
>
> rl0 11:22:33:44:55:66
> PPPoE server aa:bb:cc:dd:ee:ff
>
> rl0 broadcasts PADI to ff:ff:ff:ff:ff:ff.
> PPPoE servers mac sends a PADO to rl0 mac.
> rl0 sends a PADR to mac aa:bb:55:66:aa:bb.
> timeout happens, since no device with aa:bb:55:66:aa:bb exists in the
> network.
>
> Now change rl0 mac to 11:22:33:44:77:88:
> PADI,PADO phase unchanged.
> rl0 sends a PADR to mac aa:bb:77:88:aa:bb.
>
> I only have a very basic understanding of C and basically no
> understanding of the OpenBSD kernel.
> The PADR should be assembled around line 703 in src/sys/net/if_pppoe.c
> but I could not find any clues where this mix up happens.
>
> Best Regards,
> Thorsten
>
Hi,
I'm seeing something that may be similar as you, but I can't track it
down, so I'm going to put out what I got.
In my test environment I set up a QEMU host that has a NIC on bridge0
and vether0 on my main host. On the main host I have configured vlan0
to be a member of vether0 like so:
vlan0: flags=8947<UP,BROADCAST,DEBUG,RUNNING,PROMISC,SIMPLEX,MULTICAST>
mtu 1500
lladdr fe:e1:ba:d0:65:cd
priority: 0
vlan: 10 parent interface: vether0
groups: vlan
status: active
inet6 fe80::fce1:baff:fed0:65cd%vlan0 prefixlen 64 scopeid 0x16
inside the qemu I run pppoe0 inside a vlan with the same tag on its
interface that faces bridge0.
When I sniff then simultaneously with tcpdump on vether0 and vlan0 on
the main host then I get the following:
----
vether0:
12:02:18.008513 48:01:09:03:04:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid
10 pri 3 PPPoE-Discovery
code Initiation, version 1, type 1, id 0x0000, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \005^\334G
0000: ffff ffff ffff 4801 0903 0407 8100 600a ......H.......`.
0010: 8863 1109 0000 000c 0101 0000 0103 0004 .c..............
0020: 055e dc47 .^.G
vlan0:
12:04:18.009041 48:01:09:03:04:07 60:0a:88:63:ff:ff 8863 32: PPPoE-Discovery
code Initiation, version 1, type 1, id 0x0000, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \005^\334G
0000: 600a 8863 ffff 4801 0903 0407 8863 1109 `..c..H......c..
0010: 0000 000c 0101 0000 0103 0004 055e dc47 .............^.G
----
As you probably can see on the first glance is that the MAC address for
the received changed. It took 600a 8863, which is the vlan tag and the
ethernet type, and overwrote the ethernet dest address with those 4
bytes resulting in 60:0a:88:63:ff:ff. My npppd that I had set up on
vlan0 on the main host doesn't see it as a broadcast anymore and thus it
can't offer a PADO.
Yours, Thorsten, is probably the same concept almost just it's reversed.
Now to my environment.
The mainhost is OpenBSD-current...
vether0 looks like this:
vether0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d0:65:cd
priority: 0
groups: vether
media: Ethernet autoselect
status: active
inet6 fe80::fce1:baff:fed0:65cd%vether0 prefixlen 64 scopeid 0x5
...
I'm sorry for being all over the place with the data. And I have an
inquiry to the vlan responsible person at OpenBSD:
in /sys/net/if_vlan.c: vlan_input() I see this:
----
/*
* Having found a valid vlan interface corresponding to
* the given source interface and vlan tag, remove the
* encapsulation, and run the real packet through
* ether_input() a second time (it had better be
* reentrant!).
*/
m->m_pkthdr.rcvif = &ifv->ifv_if;
if (m->m_flags & M_VLANTAG) {
m->m_flags &= ~M_VLANTAG;
} else {
eh->ether_type = mtod(m, u_int16_t *)[1];
m->m_len -= EVL_ENCAPLEN;
m->m_data += EVL_ENCAPLEN;
m->m_pkthdr.len -= EVL_ENCAPLEN;
}
----
in the else statement, isn't the manipulation of the mbuf the same as an
m_adj(m, EVL_ENCAPLEN); ?
If not, pardon my ignorance/newbishness.
Regards,
-peter
