Is this related to your existing question Using the RAK2045 with an USB to UART addapter where you were trying to use a USB-UART for the concentrator’s GPS?
One thing to be aware of from the RAK2013 page:
Note that if you buy WisLink Cellular Pi Hat RAK2013 as an individual pice it will not be compatible with WisLink LPWAN RAK2245 RPi Hat and WisGate Developer RAK7243/44(without Cellular) Gateways and vice versa. RAK2245 LPWAN PiHAT module that we use in our WisGate RAK7243/44C(With Cellular) Developer Gateways is modified.
Are you trying to use the RAK2013 via UART or via USB?
If via UART, the packet forwarder might still be trying to open the pi’s UART, and so stealing bytes intended for pppd; look at the packet forwarder config files and the log on startup and make sure it’s using either nothing or your USB-UART, and not /dev/ttyAMA0 or whatever the hardware one is.
If via USB, it’s possible that there might be a conflict with dynamic device names - most modems get names in the /dev/ttyACM[n] range while most USB-UARTs get names in the /dev/ttyUSB[n] range, but there are counter-examples which could confuse software, and might need custom udev rules to sort out.
Really your simplest solution to serial conflicts is probably not to try to use GPS at all - in typical LoRaWAN use cases, it’s actually not useful at all - TDOA location requires additional capabilities not present, and it’s easy to set static location coordinates; the only thing GPS really does for you is give a time source if you’re archiving packets while received offline, but most LoRaWAN network servers can’t ingest logs of past packets in a useful way anyway.
Another possible issue for your failure is that your overall power supply might be insufficient for certain peak loads. Many people mistakenly shop based on average - I’d strongly recommend using a 4 or 5 amp power supply for a pi-based gateway.