Question: Sharing an IP-connection

[Bjørn Mork]

Thomas Schäfer <thomas at cis.uni-muenchen.de> 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 tap0: <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.. at .@.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