bjorn at mork
May 22, 2012, 6:36 AM
Post #11 of 11
(579 views)
Permalink
|
Thomas Schäfer <thomas [at] cis> writes:
> Am 20.05.2012 21:55, schrieb Bjørn Mork:
>> Does bridging work, Thomas?
>
> Bridging did not work. But it is possible that the error was in front
> of the screen.
Nah, I don't think so. The ethernet frame emulation in the modem is
broken (or rather limited by assumptions). Just did a simple bridging
test using IPv4, and that doesn't work either for the same reason.
I have this bridge:
nemi:/home/bjorn# brctl show br1
bridge name bridge id STP enabled interfaces
br1 8000.cefc5f05ec52 no tap0.10
wwan0
Using these MAC adresses on the ports and the bridge:
nemi:/home/bjorn# ip link show wwan0
21: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN mode DEFAULT qlen 1000
link/ether d6:c6:02:91:1c:41 brd ff:ff:ff:ff:ff:ff
nemi:/home/bjorn# ip link show tap0.10
9: tap0.10 [at] tap: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UP mode DEFAULT
link/ether ce:fc:5f:05:ec:52 brd ff:ff:ff:ff:ff:ff
nemi:/home/bjorn# ip link show br1
31: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
link/ether ce:fc:5f:05:ec:52 brd ff:ff:ff:ff:ff:ff
nemi:/home/bjorn# brctl showmacs br1
port no mac addr is local? ageing timer
1 02:50:f3:00:00:00 no 0.74
2 52:54:00:ff:05:00 no 0.76
2 ce:fc:5f:05:ec:52 yes 0.00
1 d6:c6:02:91:1c:41 yes 0.00
So, we have
modem: 02:50:f3:00:00:00
client: 52:54:00:ff:05:00
tap0.10 if: ce:fc:5f:05:ec:52
wwan0 if: d6:c6:02:91:1c:41
and we want the client and modem to talk together:
13.103922 10.105.75.185 -> 130.67.15.251 ICMP 98 Echo (ping) request id=0x07b6, seq=481/57601, ttl=64
0000 02 50 f3 00 00 00 52 54 00 ff 05 00 08 00 45 00 .P....RT......E.
0010 00 54 00 00 40 00 40 01 52 49 0a 69 4b b9 82 43 .T..@.@.RI.iK..C
0020 0f fb 08 00 e7 f3 07 b6 01 e1 c3 8d bb 4f 00 00 .............O..
0030 00 00 c8 c4 00 00 00 00 00 00 10 11 12 13 14 15 ................
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
13.131276 130.67.15.251 -> 10.105.75.185 ICMP 98 Echo (ping) reply id=0x07b6, seq=481/57601, ttl=56
0000 d6 c6 02 91 1c 41 02 50 f3 00 00 00 08 00 45 00 .....A.P......E.
0010 00 54 5b 07 00 00 38 01 3f 42 82 43 0f fb 0a 69 .T[...8.?B.C...i
0020 4b b9 00 00 ef f3 07 b6 01 e1 c3 8d bb 4f 00 00 K............O..
0030 00 00 c8 c4 00 00 00 00 00 00 10 11 12 13 14 15 ................
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
That won't work... Note how the reply destination address doesn't match
the request source address. The bridge will deliver this to the wwan0
interface instead of the client port.
Did some more experiments, and as expected this is tied to where the
initial DHCP request came from. Stopping and restarting the connection,
and then letting the *client* send the DHCP request will tie all packets
from the modem to the client MAC address instead.
So you can bridge, but not share the bridge among multiple clients. The
modem will select a single MAC address as your end of the link. It
doesn't really do ARP.
I assume the IPV6 implementation is similar. The modem doesn't really
do ND either. It just fakes them, and assumes a two-device
point-to-point link between modem and host. It does not expect the host
to be a bridge.
Started thinking of what can be done about this. The immediate thought
was that the "raw IP" mode would be better, but really it wouldn't. You
could just as well use ebtables to replace the destination MAC address
on packets from the modem with zeros, which is what the driver would
have to do if emulating an ethernet device with the modem in that mode.
Ideas are welcome.
Bjørn
|
