USB LTE modem without MAC address

mac addressmodempppserial portttyusb

I'm connecting a linux machine using a nowadays popular Huawei Brovi E3372-325 LTE USB Stick to the internet. The special requirement is that incoming ssh/ping/NTP/… connections must reach my linux OS.

The state is, that using usb_modeswitch -X and the option driver I can bring up the 3 ttyUSB interfaces, and connect successfully using wvdial. But for some reason, ifconfig does not list a HW/MAC address for ppp0 interface, and devices on the same APN network can't ping the my IP address. I don't think the reason is blockage by the ISP, because my other devices are ping-able on the network.

Output of ip addr

19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 10.250.0.112 peer 10.64.64.64/24 scope global ppp0
       valid_lft forever preferred_lft forever
  1. If I'm not mistake, I don't use RNDIS right now. Am I right, that in general the popular RNDIS protocol does not suit my use case, because that creates an additional local network, making it trickier to forward incoming connections to the OS? Pinging might work from outside because that's answered by the USB modem itself, but incoming ssh would fail.
  2. What might be the reason, that ppp0 does not have a MAC address? How it's even possible? Should I assign one? Is it probably the reason that other devices can't ping it's IP? How to solve this situation?

Best Answer

If I'm not mistake, I don't use RNDIS right now.

RNDIS is a Windows-specific network interface driver API. Um, that as nothing to do with what you're doing, right?

What might be the reason, that ppp0 does not have a MAC address? How it's even possible?

a MAC address is an Ethernet concept; and PPP is not ethernet :)

PPP's frame do contain an Address – but it's just a single byte long, and always set to 0xFF, PPP being a point-to-point protocol, where you don't need more addresses (you know who you're talking to – the other end).

I don't think the reason is blockage by the ISP, because my other devices are ping-able on the network.

Good debugging. Note, however, that mobile network operators (MNOs) routinely employ carrier-grade NAT to hide a lot of users behind one public IPv4 address – there's even theoretically, ignoring anything else but humans with phones – only 2³² possible IP addresses (ignoring any "special" addresses), and roughly as many phones as there are humans, so there's only IPv4 addresses for around half of the phones. The message here is that if you want your mobile device to be world-reachable, there's going to be some extra infrastructure involved (like a VPN server), or you need to use IPv6. I'd recommend going for IPv6 – due to market forces, for most MNOs it's cheaper to have IPv6 traffic to and from the internet, so they might prioritize that.

Anyway, your question is why it doesn't work for you – here's the thing: This is carrier-grade NAT (your IPv4 address on that interface is a private one!), there's neither a guarantee nor too much sense in guaranteeing that different subscribers can contact each other directly. It's cool that it works for you on your other devices, though.

What's a bit worrying is that you're only assigned a single IPv4 address, and not an IPv6 address (or a whole IPv6 subnet). That might mean that your Linux machine's pppd isn't configured to accept IPv6, or some other misconfiguration.

But more realistically: PPP is an … old protocol that's got nothing to do with how mobile network infrastructure operates, at all. 2.5G/GPRS/EDGE, 3G/UMTS, 4G/LTE, 5G… etc are packet networks – you get an interface that transports IP packets, directly; you don't get a serial line over which you need to talk PPP to establish a packet tunnel.
So, what must be happening is that your USB modem connects to the mobile network, gets an IP address, and puts the IP packets it gets through a PPP tunnel, which it seems to then put over an emulated serial link to your computer? That's an interesting way to do it, to say the least – could as well just have been a USB network card, and worked out of the box. In fact, that's how USB tethering on my phone works, and I had built-in modem cards for my laptops in the past, which did the same.

Maybe your USB modem has different modes of operating, and one that looks like a 1990's dial-up modem that emulates connecting to an Internet Service Provider that offers PPP, and a different mode where it's just an IP router? If that's the case, use the latter mode, and set it to forward packets to your computer.

So, either way, your modem is involved in mangling IP packets; so quite likely that's where your incoming packets get lost. But, maybe your other devices are also using the same APN nominally, but if they're using a different way of connecting to the mobile network, their packets go a different route in the core network, and don't end up in the same private network as your modem; there's much that could differ here, that you have zero visibility of. Generally, your MNO doesn't operate an internal network for you (unless you pay them to – for example using a special M2M subscription), but an internet access; communicate through the internet, if you can't communicate locally. For that you need a global IP address that you can connect to.

If you asked me, if you need to be mutually communicating:

  • Use IPv6. That's your best chance to actually get a global address. Fall back to IPv4 only if you positively must.
  • Get some server that has a static public address. Your user equipment gets assigned a new IP address at will of your MNO.
  • Establish a VPN connection to that public address from each of your devices – wireguard is an excellent, relatively low-power method for that. This might already solve all your problems.
  • if you want to be Smart (with a capital S) about latencies, you can add additional direct network paths between different devices as soon as they detect they can mutually directly communicate – which requires some software running at the endpoints, delivering address information about the different network interfaces offered by your devices, and a daemon to make sense of these.
Related Question