My Setup:

WirelessClient--MT(AP)--<Ethernet>--MT(AC)

Both 2.9.5, EoIP-Tunnel between the 2 MTs
AP-interface is in the same Bridge-Group as the EoIP-tunnel
on the other side (AC) EoIP-tunnel is in a bridge-group. On top of this bridge-group is the pppoe-server.

Now something strange happens:
Client (wireless) sends PADI, AC sends PADO (I can see this on AC),
but the PADO-packet doesn´t seem to reach the AP (set up "passthrough-filter" on bridge for testing purposes)

If I set up a PPPoE-Client on the AP on top of the sam bridge (where AP-device and EoIP-tunnel is in) it connects.

If I put (on both sides) the LAN-IF (instead of the EoIP-tunnel) into the bridge-group it works also with the wireless-client.

I don´t know, if the problem is the bridge, the tunnel or something else.....

Hope, you understand, what I mean

PS: I need this setup (with EoIP) because I have several APs on a routed network and I want to centralize the AC

??? ANY IDEA ???

May be I had the same problem and after some testing I found that problem occures only if there are more interfaces in the bridge. Let's suppose that client is connected through wlan1 and output interface is ether1. Just add wlan1 and EoIP interfaces to bridge and it should work fine. (IP is assigned to ether1 of course) I suppose it is a bug.

THX for your reply. I will test this out tomorrow.

Has been already configured like this

Any other ideas?

I tested a little bit with ethereal:

Client sent PADI, passed through AP, EoIP-tunnel, reached pppoe-server on AC
pppoe-server on AC responded with PADO, passed through EoIP-tunnel, is visible in packet-sniffer on AP, but within ethereal on the client I can´t see the PADO packet.

AP-Interface an EoIP are in one bridgegroup and the pppoe-server resides on the a bridgegroup where the EoIP-tunnel is within (also testet pppoe-server dirct on EoIP-tunnel).

???

Is there really nobody who can help schorsch with his/our problem?
If you need more details - here they are:

Current situation:
~~~~~~~~~~~~~~~~~~

We have a simple bridged network set up with a /24 subnet as our network's backbone on top. The backbone's IP adresses are on the bridge interfaces at each router.
Our "backbone" is working fine and all machines on the bridged network are able to ping and telnet/ssh to each other without even the slightest problem.
We do have our central router (core_mz) connected to the internet and several other routers are connected to this router via our bridged backbone (see above scheme).
We do have two access points (ap1 and ap2) on remote sites and our customers dial in via pppoe. Both APs are on the bridged backbone network and are additionally connected by an EoIP tunnel (without IP adresses on the tunnel interface).

The PPPoE dialin server is currently NOT on our central router but on ap1. The PPPoE connections from customers connected to ap2 are being bridged over the additional EoIP tunnel to ap1 where the PPPoE server is located.

We do have a private network for our customers which is being NAT'ed to a common public IP.

All this is working fine.


Planned:
~~~~~~~~

What we want to do now is to provide our customers with public IPs without the need to route the public network through our backbone infrastructure. So we need to move the PPPoE server from the remote site (ap1) to our core router (core_mz).

But that is just where our problem with the EoIP tunnel kicks in:
We tried the exact same setup as with ap2 and ap1 (additional EoIP tunnel without IP adress) this time between ap2 and core_mz. But it simply does not work as we expected:
- The PADI packets from a client connected to ap2 via ethernet are being delivered to core_mz just fine.
- Core_mz then answers correctly with a PAD0 addressed to the client's ethernet MAC.

But the PAD0 never arrives at the client. It does however reach ap2.

It seems to me that ap2 is doing something veeery nasty with our little PAD0 packets. I do have some capture files attached (ap2_ether2.cap, ap2_bridge.cap, ap2_eoip.cap, core_mz_eoip.cap).

In case someone thinks the EoIP might not be working (that's what I thought at first) - I did try to dialin from AP2 directly via the EoIP tunnel... worked like a charm. Thus the EoIP must be set up correctly.


Technical configuration information (only relevant parts) follows:
Packet sniffer capture files from ap2 and core_mz while trying to establish a pppoe connection from a client connected to ether2 at ap2 to core_mz (mac-only-no-ip):
ap2_ether2.cap
ap2_bridge.cap
ap2_eoip.cap
core_mz_eoip.cap


We would be very thankful if any of you could help us on this one!

Hello, we solved similar problem for our customer, similar configuration, central router with pppoe server and bridged network (local network + remote networks connected via eoip and bridged). Everything was working, I could ping every device in network but pppoe won't pass.

The problem in our case was, that the device was connected via cable modem, the changed the connection and after this it started working.

Try to track, where are the packets lossing.

You can try to remove and create the bridge again, I remember I solved problem with bridge using this way.

Thanks for your answer!

Here's what I found out about my little PADI/PAD0 packet friends:

As you can see from the ethereal capture files in my previous posting, the PADI goes straight through from the client to core_mz.

The returning PAD0 is correctly received on the EoIP interface at ap2 but then unexpectedly somehow magically converted:

On the EoIP interface (ap2_eoip.cap): So far so good...
Then something weird happens on the Bridge interface (ap2_bridge.cap): First the source MAC is wrong and secondly the destination MAC is wrong, too. I don't even know which router that MAC address would belong to: I checked every router but did not find a corresponding interface's MAC.
The only interface that had a close enough MAC was an ethernet interface on core_mz with 00:11:2F:3E:BA:A9. But the first two bytes don't match and no matter what one might say: the correct PAD0 DID arrive at ap2! It is just somehow mangled on the bridge...

After this it is at least clear why my client with MAC 00:50:ba:33:91:6c never gets to see the PAD0 packet - it is simply not designated for my client!

But: How on earth can something like this happen???
I already tried to remove the bridge, the EoIP interface and started the setup from scratch (without resetting the device though) - nothing. It did not help at all.

Maybe I'll reset the device's configuration and start a fresh MT install...

Hello,

Try to check arp mode on each device, i always use "enabled".

Reset could help, I saw many times mysterious problems and reset and reconfiguring helped.

Even try another device on the same site a bridge it through metalic ethernet interface.

We have already tested it on another router/AP which is connected via an ethernat-cable to gw-core. ARP is enabled at all devices and bridges.
Reboot has been done many times with no effect.
I think we erase the configuration on both (and later on all) systems and reconfigure them.
I hope I can do this with export/import (not backup/restore).

Yes, you can use import/export, don't use backup/restore, because there is chance to transfer the configuration with the "secret error".

But remember, that import/export must be used carefully, because the order of exported commands wouldn't be the right for import.

I do it so:

on old configuration export all configuration:

/export file=all

and then I import selected parts (queue, firewall). Greatest problem is with interfaces, you have to name them at first.

Thanks a lot for your tips!!!

I´ve reconfigured one router from scratch (only AP, EoIP-tunnel and a bridge) and it worked fine.
I assume that the something went wrong with the upgrade from 2.8.28 to 2.9rcX.

Now I have to reconfigure all our routers outside from scratch
Anyway, then it works.

Thank you for your tips!

Well... actually it was NOT solved by reconfiguring the router from scratch. Neither was it an upgrading problem.
We discovered that as soon as the physical interface below the EoIP is itself within a bridge group the EoIP no longer works as expected.
If you remove the physical interface from the bridge group everything just works (after you setup routing correctly).
We had to rearrange our whole network from bridged to routed in order to be able to use the EoIP tunnels as a matter of transport for the PPPoE session.

If you're interested in details - please ask

Well, At least you are running a routed network now, which is much better then a bridged network.

Well... actually it was NOT solved by reconfiguring the router from scratch. Neither was it an upgrading problem.
We discovered that as soon as the physical interface below the EoIP is itself within a bridge group the EoIP no longer works as expected.
If you remove the physical interface from the bridge group everything just works (after you setup routing correctly).
We had to rearrange our whole network from bridged to routed in order to be able to use the EoIP tunnels as a matter of transport for the PPPoE session.

If you're interested in details - please ask

I found this bug and reported it a long time ago (v2.8.17). I'm tempted to comment the gross ineptitude. Perhaps you get better results?