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
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.
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.
```text
ethernet Wireless(EoIP) ethernet Wireless(EoIP) Wireless(EoIP)
core_mz----------mz1~~~~~~~~~~~~~~~~sh1----------sh2~~~~~~~~~~~~~~~~ap1~~~~~~~~~~~~~~~~ap2
| |
|____add. EoIP_____|
```
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.
```text
ethernet Wireless(EoIP) ethernet Wireless(EoIP) Wireless(EoIP)
core_mz----------mz1~~~~~~~~~~~~~~~~sh1----------sh2~~~~~~~~~~~~~~~~ap1~~~~~~~~~~~~~~~~ap2
| |
|_________________________________additional EoIP____________________________________|
```
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:
```text
core_mz:
-------
interface eoip> print
5 R name="EoIP -> ap2" mtu=1500 mac-address=00:00:5E:80:13:37
arp=enabled remote-address=172.16.1.205 tunnel-id=31337
interface bridge port> print
12 EoIP -> ap2 none 128 10
interface pppoe-server server> print
2 service-name="FRED PPPoE Test" interface=EoIP -> ap2
max-mtu=1492 max-mru=1492 authentication=pap,chap,mschap1,mschap2
keepalive-timeout=10 one-session-per-host=no max-sessions=0
default-profile=fred_testprofil_oeffentliche_ips_statisch
```
\
<br>
```text
AP2:
---
interface eoip> print
4 R name="EoIP -> core_mz" mtu=1500 mac-address=00:00:5E:80:13:38
arp=enabled remote-address=172.16.1.249 tunnel-id=31337
interface ethernet> print
1 R ether2 1500 00:0D:B9:01:82:D5 enabled
interface bridge> print
3 R name="PPPoE Bridge -> core_mz" mtu=1500 arp=enabled
mac-address=00:00:5E:80:13:38 stp=no priority=32768 ageing-time=5m
forward-delay=15s garbage-collection-interval=5s hello-time=2s
max-message-age=20s
interface bridge port> print
1 ether2 PPPoE Bridge -> core_mz 128 10
8 EoIP -> core_mz PPPoE Bridge -> core_mz 128 10
```
\
<br>
```text
PPPoE-Client connected to ether2 at AP2:
---------------------------------------
debian linux machine connected directly to ether2 (10mbit half-duplex)
eth0:
mac=00:50:BA:33:91:6C
```
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](http://www.juchart.de/omnidat/ap2_ether2.cap)
[ap2_bridge.cap](http://www.juchart.de/omnidat/ap2_bridge.cap)
[ap2_eoip.cap](http://www.juchart.de/omnidat/ap2_eoip.cap)
[core_mz_eoip.cap](http://www.juchart.de/omnidat/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.
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):
PADI from src MAC 00:50:ba:33:91:6c (which is my client) goes to broadcast MAC.
PADO from src MAC 00:00:5e:80:13:37 (which is core_mz) with destination 00:50:ba:33:91:6c arrives through the EoIP tunnel at ap2.
So far so good…
Then something weird happens on the Bridge interface (ap2_bridge.cap):
the PADI just passes fine like on the EoIP interface but the
PAD0 from src MAC 00:00:5e:80:22:05 (which is the backbone interface of ap2 where definately NO PPPoE is running and which is not even in this bridge group!) with destination 01:cd:2f:3e:ba:a9 is just plain wrong.
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…
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).
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.
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.
