MBIM Interface in Bridge Mode
Sassy Natan
sassyn at gmail.com
Fri Oct 2 17:20:32 UTC 2020
Hi Again,
I am still fighting with this and didn't manage to get this working.
Spend over 10 hours today and yesterday without any luck.
Maybe someone can help?
Thank you 🙏
On Wed, Sep 30, 2020 at 12:28 PM Sassy Natan <sassyn at gmail.com> wrote:
> Dear Bjørn,
>
> Thank you so much for your effort and detailed information on how to
> shorten out this issue.
> I really appreciate this!
>
> Apologies for the late reply.
> We had a holiday here in Israel, and with the covid-19 situation (we in
> the middle of the second wave) I'm really losing my head.
> The
>
>
>
> situation here in Israel is really bad compared to the rest of the world
> :-(
>
> Again, thank you so much! Your solution opened my mind to new things and
> ideas.
>
> However, I tried out your solution, and It doesn't work on my setup.
> I'm using a clean ubuntu 18.04 with vpp version 18.07-release without any
> luck.
>
> I have compiled an asciinema of the entire process, maybe you can take a
> quick look?
>
> https://asciinema.org/a/05VG1Xhl3kYOydE685wjphoqf
> <http://goog_1496068446>
> https://asciinema.org/a/3sOWj8x5YBWnT5mNUgxiIHmUw
> <https://asciinema.org/a/3sOWj8x5YBWnT5mNUgxiIHmUw>
>
>
> Here is also a quick figure of the topology
> [image: image.png]
>
> You were saying "There are a gazillion other ways to achieve the same"
> are you referring to the "two-way default routing"?
> Or you mean the entire process.
>
> As I said your solution is very creative - but even though I spent a long
> time on this - I didn't manage to come up with an alternative.
>
> Even with your setup, I did try to do a long debug to it.
> I used tcpdump on all interfaces (including tracing out the ethernet
> address "-e"), but nothing I can say will provide good feedback here.
>
>
> Will be very thankful if someone can drop a comment here.
>
> Thank you.
> Sassy
>
>
>
>
>
>
>
> On Wed, Sep 23, 2020 at 4:03 PM Bjørn Mork <bjorn at mork.no> wrote:
>
>> FWIW, I just had to try out how much it takes to connect a host owned
>>
>>
>> LTE netdev to VPP. That's actually pretty easy. But you end forwarding
>>
>>
>> between the VPP host interface and the LTE netdev in Linux, which I
>>
>>
>> guess is something you eventually might like to avoid. I assume this is
>>
>>
>> pretty easy to implement as a VPP plugin or similar. It's not related
>>
>>
>> to the actual functionality here anyway.
>>
>>
>>
>>
>>
>> My demo setup is a slight modification of the start of the VPP tutorial:
>>
>>
>> https://fd.io/docs/vpp/v2005/gettingstarted/progressivevpp/interface.html
>>
>>
>>
>>
>>
>>
>>
>>
>> What I did was - on the host:
>>
>>
>>
>>
>>
>> 1) Create veth pair according to tutorial instructions:
>>
>>
>>
>>
>>
>> ip link add name vpp1out type veth peer name vpp1host
>>
>>
>>
>>
>>
>>
>>
>>
>> 2) Create a new sub-interface for MBIM session ID 3:
>>
>>
>>
>>
>>
>> ip link add wwan0.3 link wwan0 type vlan id 3
>>
>>
>>
>>
>>
>>
>>
>>
>> 3) Create a new network namespace and put both these interfaces there:
>>
>>
>>
>>
>>
>> ip netns add vpplte
>>
>>
>> ip link set vpp1host netns vpplte
>>
>>
>> ip link set wwan0.3 netns vpplte
>>
>>
>>
>>
>>
>> 4) Start a shell in the network namespace and execute the remaining host
>>
>>
>> commands there:
>>
>>
>>
>>
>>
>> ip netns exec vpplte /bin/bash
>>
>>
>>
>>
>>
>>
>>
>>
>> 5) Set all links up:
>>
>>
>>
>>
>>
>> ip link set lo up
>>
>>
>> ip link set vpp1host up
>>
>>
>> ip link set wwan0.3 up
>>
>>
>>
>>
>>
>>
>>
>>
>> 6) Enable proxy-arp and forwarding
>>
>>
>>
>>
>>
>> echo 1 > /proc/sys/net/ipv4/conf/vpp1host/proxy_arp
>>
>>
>> echo 1 > /proc/sys/net/ipv4/conf/vpp1host/forwarding
>>
>>
>> echo 1 > /proc/sys/net/ipv4/conf/wwan0.3/forwarding
>>
>>
>>
>>
>>
>>
>>
>>
>> 7) set up two-way default routing
>>
>>
>>
>>
>>
>> ip route add default dev wwan0.3
>>
>>
>> ip route add default dev vpp1host table 3
>>
>>
>> ip rule add pref 1000 iif wwan0.3 lookup 3
>>
>>
>>
>>
>>
>> 8) Disable arp on the veth endpoint
>>
>>
>>
>>
>>
>> ip link set dev vpp1host arp off
>>
>>
>>
>>
>>
>>
>>
>>
>> 9) Connect the session, and note the assigned address
>>
>>
>>
>>
>>
>> mbimcli -p -d /dev/cdc-wdm0
>> --connect=apn=telenor.smart,session-id=3,ip-type=ipv4v6
>>
>>
>>
>>
>>
>>
>>
>>
>> This is the output I got, to be used in the VPP shell below:
>>
>>
>>
>>
>>
>> [/dev/cdc-wdm0] Successfully connected
>>
>>
>>
>>
>>
>> [/dev/cdc-wdm0] Connection status:
>>
>>
>> Session ID: '3'
>>
>>
>> Activation state: 'activated'
>>
>>
>> Voice call state: 'none'
>>
>>
>> IP type: 'ipv4v6'
>>
>>
>> Context type: 'internet'
>>
>>
>> Network error: 'unknown'
>>
>>
>>
>>
>>
>> [/dev/cdc-wdm0] IPv4 configuration available: 'address, gateway, dns, mtu'
>>
>>
>> IP [0]: '10.169.198.6/30'
>>
>>
>> Gateway: '10.169.198.5'
>>
>>
>> DNS [0]: '193.213.112.4'
>>
>>
>> DNS [1]: '130.67.15.198'
>>
>>
>> MTU: '1500'
>>
>>
>>
>>
>>
>> [/dev/cdc-wdm0] IPv6 configuration available: 'address, gateway, dns, mtu'
>>
>>
>> IP [0]: '2a02:2121:2c0:e913:392d:3e46:cf98:4ca3/64'
>>
>>
>> Gateway: '2a02:2121:2c0:e913:70a8:2a1c:dc62:2022'
>>
>>
>> DNS [0]: '2001:4600:4:fff::52'
>>
>>
>> DNS [1]: '2001:4600:4:1fff::52'
>>
>>
>> MTU: '1540'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> In the VPP shell:
>>
>>
>>
>>
>>
>> 10) Create host interface and set link up as instructed by the tutorial
>>
>>
>>
>>
>>
>> create host-interface name vpp1out
>>
>>
>> set int state host-vpp1out up
>>
>>
>>
>>
>>
>>
>>
>>
>> 11) Assign the IP address from the mbimcli command above:
>>
>>
>>
>>
>>
>>
>>
>>
>> set int ip address host-vpp1out 10.169.198.6/30
>>
>>
>>
>>
>>
>>
>>
>>
>> 12) Set a default route (or whatever you want) via some fake gateway
>>
>>
>> address on the other end of that veth pair - the one suggested by
>>
>>
>> the modem is fine:
>>
>>
>>
>>
>>
>> ip route add 0/0 via 10.169.198.5
>>
>>
>>
>>
>>
>>
>>
>>
>> 13) ping an address on the other side of the LTE link:
>>
>>
>>
>>
>>
>>
>>
>>
>> vpp# ping 8.8.8.8
>>
>>
>> 116 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=68.0229 ms
>>
>>
>> 116 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=48.9930 ms
>>
>>
>> 116 bytes from 8.8.8.8: icmp_seq=3 ttl=114 time=52.8561 ms
>>
>>
>> 116 bytes from 8.8.8.8: icmp_seq=4 ttl=114 time=51.5395 ms
>>
>>
>> 116 bytes from 8.8.8.8: icmp_seq=5 ttl=114 time=99.0668 ms
>>
>>
>>
>>
>>
>> Statistics: 5 sent, 5 received, 0% packet loss
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> This was a simple abuse of a dedicated network namespace in the Linux
>>
>>
>> host, where it is easy to do two-way default routing without having to
>>
>>
>> care about addressing and routes at all. There are a gazillion other
>>
>>
>> ways to achieve the same,
>>
>>
>>
>>
>>
>> There is no way to know that there is anything special about the
>>
>>
>> host-vpp1out interface from the VPP shell. It looks like any other host
>>
>>
>> interface. But you'll obviously have to do something on the host if you
>>
>>
>> are going to run anything fancy over it. But that's normally not the
>>
>>
>> use case for an LTE connection anyway, I guess.
>>
>>
>>
>>
>>
>>
>>
>>
>> vpp# show interface
>>
>>
>> Name Idx State MTU (L3/IP4/IP6/MPLS)
>> Counter Count
>>
>>
>> host-vpp1out 1 up 9000/0/0/0 rx
>> packets 135
>>
>>
>> rx
>> bytes 22334
>>
>>
>> tx
>> packets 61
>>
>>
>> tx
>> bytes 4874
>>
>>
>>
>> drops 146
>>
>>
>> ip4
>> 15
>>
>>
>> ip6
>> 32
>>
>>
>> local0 0 down 0/0/0/0
>>
>>
>> vpp# show ip neighbor
>>
>>
>> Time IP Flags Ethernet
>> Interface
>>
>>
>> 4095.4097 10.169.198.5 D
>> fe:cd:9c:57:a9:da host-vpp1out
>>
>>
>> vpp# show ip fib
>>
>>
>> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0
>> flags:none locks:[adjacency:1, recursive-resolution:1, default-route:1,
>> nat-hi:2, ]
>>
>>
>> 0.0.0.0/0
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:14
>> to:[60:5760]]
>>
>>
>> [0] [@12]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12
>> to:[0:0] via:[60:5760]]
>>
>>
>> [0] [@5]: ipv4 via 10.169.198.5 host-vpp1out: mtu:9000 next:3
>> fecd9c57a9da02fe5a6a76810800
>>
>>
>> 0.0.0.0/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:2 buckets:1 uRPF:1 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>> 10.169.198.4/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>> 10.169.198.5/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]
>> via:[60:5760]]
>>
>>
>> [0] [@5]: ipv4 via 10.169.198.5 host-vpp1out: mtu:9000 next:3
>> fecd9c57a9da02fe5a6a76810800
>>
>>
>> 10.169.198.4/30
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:8 to:[0:0]]
>>
>>
>> [0] [@4]: ipv4-glean: host-vpp1out: mtu:9000 next:1
>> ffffffffffff02fe5a6a76810806
>>
>>
>> 10.169.198.6/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13
>> to:[15:1440]]
>>
>>
>> [0] [@2]: dpo-receive: 10.169.198.6 on host-vpp1out
>>
>>
>> 10.169.198.7/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>> 224.0.0.0/4
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:4 buckets:1 uRPF:3 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>> 240.0.0.0/4
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:3 buckets:1 uRPF:2 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>> 255.255.255.255/32
>>
>>
>> unicast-ip4-chain
>>
>>
>> [@0]: dpo-load-balance: [proto:ip4 index:5 buckets:1 uRPF:4 to:[0:0]]
>>
>>
>> [0] [@0]: dpo-drop ip4
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> And the Linux host view:
>>
>>
>>
>>
>>
>> root at miraculix:/tmp# ip link
>>
>>
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
>> DEFAULT group default qlen 1000
>>
>>
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>
>>
>> 10: vpp1host at if11: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
>> qdisc noqueue state UP mode DEFAULT group default qlen 1000
>>
>>
>> link/ether fe:cd:9c:57:a9:da brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>
>>
>> 12: wwan0.3 at if3: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>> noqueue state UP mode DEFAULT group default qlen 1000
>>
>>
>> link/ether 42:0a:0d:ab:b4:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>
>>
>> root at miraculix:/tmp# ip addr
>>
>>
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
>> default qlen 1000
>>
>>
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>
>>
>> inet 127.0.0.1/8 scope host lo
>>
>>
>> valid_lft forever preferred_lft forever
>>
>>
>> inet6 ::1/128 scope host
>>
>>
>> valid_lft forever preferred_lft forever
>>
>>
>> 10: vpp1host at if11: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
>> qdisc noqueue state UP group default qlen 1000
>>
>>
>> link/ether fe:cd:9c:57:a9:da brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>
>>
>> inet6 fe80::fccd:9cff:fe57:a9da/64 scope link
>>
>>
>> valid_lft forever preferred_lft forever
>>
>>
>> 12: wwan0.3 at if3: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>> noqueue state UP group default qlen 1000
>>
>>
>> link/ether 42:0a:0d:ab:b4:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>
>>
>> inet6 2a02:2121:2c0:e913:400a:dff:feab:b4f5/64 scope global dynamic
>> mngtmpaddr
>>
>>
>> valid_lft forever preferred_lft forever
>>
>>
>> inet6 fe80::400a:dff:feab:b4f5/64 scope link
>>
>>
>> valid_lft forever preferred_lft forever
>>
>>
>> root at miraculix:/tmp# ip route
>>
>>
>> default dev wwan0.3 scope link
>>
>>
>> root at miraculix:/tmp# ip route show table 3
>>
>>
>> default dev vpp1host scope link
>>
>>
>> root at miraculix:/tmp# ip rule
>>
>>
>> 0: from all lookup local
>>
>>
>> 1000: from all iif wwan0.3 lookup 3
>>
>>
>> 32766: from all lookup main
>>
>>
>> 32767: from all lookup default
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Bjørn
>>
>>
>>
>
> --
> Regards,
>
> Sassy Natan
> 972-(0)54-2203702
>
>
>
--
Regards,
Sassy Natan
972-(0)54-2203702
--
Regards,
Sassy Natan
972-(0)54-2203702
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libmbim-devel/attachments/20201002/7b5fed7a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31421 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libmbim-devel/attachments/20201002/7b5fed7a/attachment-0001.png>
More information about the libmbim-devel
mailing list