2

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?
0

1 Answer 1

5

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.
8
  • This explains a lot, thanks Marcus! Ubuntu supports RNDIS with a dedicated kernel module and my USB modems might appear as RNDIS device in dmesg, that's why I was not fully sure if it's used :)
    – gorogm
    Mar 12, 2023 at 10:32
  • The APN I use is a private one - maybe I should have mentioned. I'm not sure if I can go to IPv6 :( Thanks, I'll not miss the MAC from ppp0 then :) I'd like to solve the problem of lost incoming packets locally, there's something buggy with the Brovi USB modem and it's ppp connection to linux. Anyway I'll accept your answer as technically it answered my question about MAC.
    – gorogm
    Mar 12, 2023 at 11:06
  • If the modem's buggy, chances are you can't fix it. Mar 12, 2023 at 15:21
  • 1
    NDIS is the Windows-specific driver API, while RNDIS (remote NDIS) is a USB interface protocol derived from it. It's commonly implemented by Android devices for the "USB tethering" feature and it's not unlikely to see it being used for USB LTE modems as well. Mar 12, 2023 at 17:50
  • 1
    @MarcusMüller, yes, you can have PPP on e.g. RS485 with multiple stations. There is a reason the address field exists, after all. Mar 12, 2023 at 22:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .