-
Dear pfSense Community
I am using an APU board with pfSense 2.4.5-RELEASE-p1. As WAN interface I am using a ME909s-120 from Huawei. The setup works fine and with the package "Cellular Modem" I can monitor the status without any problems.
But my problem is the following.
- Usually my performance (after speedcheck) is something like this:
Latency: 44.49 / Download: 29.33 / Upload: 23.94 - But when I reboot the system, the performance is usually in the following range:
Latency: 60.14 / Down: 5.45 / Up:6.24 - Only after a "reset" (Button inside the Package "Cellular Modem"), I will reach the original speed again.
What can be the reason for this, or what can I do about it? I have already set the loader_delay to "40" - but it does not help.
Alternatively, I could automatically reset the modem after system startup - but how can I do that?Thank you for your support!
- Usually my performance (after speedcheck) is something like this:
-
It looks like it echos
AT^RESET
to the modem port.
https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-cellular/files/usr/local/sbin/cellular_check.php#L57So you could probably do that with a shellcmd.
Steve
-
Hi Steve
Thank you for your support. I tried it with the following command:/bin/echo "AT^RESET" > '/dev/cuaZ99.1'
If I send the command over putty, it works and after the reset the performance is much better. But if I ad the command to shellcmd, the modem is unable to connect to the network (no connection). Is the syntax wrong for using the command in shellcmd?
Or do I ned a waiting sequenz before the command?Regards, Darkred
-
Mmm, the modem might not be available when the shellcmd runs. Or, more likely, it reboots the modem and it's still rebooting when pfSense tries to bring it up as an interface.
You might try one of the other shellcmd types. earlyshellcmd might mean it's finished rebooting when pfSense tries to assign it. afterfiletrchangesshellcmd might not apply to it until after it's been assigned.Steve
-
Hmm... I checked the doumentation..
shellcmd --> Will run the command specified towards the end of the boot process. earlyshellcmd --> Will run the command specified at the beginning of the boot process. afterfilterchangeshellcmd -->Will run after each filter_configure() call.
As far as I understand it, "shellcmd" is the only reasonable variant. "earlyshellcmd" would be before the start process (i.e. too early) and "afterfilterchangeshellcmd" would repeat itself several times - after every run of a filter_configure() call. And there are no other start-up methods as far as I know?
-
I would try them anyway to see what the result is but otherwise you can run it as a rc script:
https://docs.netgate.com/pfsense/en/latest/development/boot-commands.html#shell-script-optionWhat you could probably do is run a command/script that does something like:
reset modem
wait 30s
configure the LTE interface againSteve
-
I have now tried all three variants - without success. The modem does not connect this way. Is there perhaps an error in the command?
/bin/echo "AT^RESET" > '/dev/cuaZ99.1'.
Do shell scpits in /usr/local/etc/rc.d/ directory start later than the commands in shellcmd?
I will test something like:/usr/local/etc/rc.d/modemreset.sh:
#!/bin/sh sleep 60 /bin/echo "AT^RESET" > /dev/cuaZ99.1
Regards
-
The timing is probably not much different. I would check the system logs for errors during boot that might indicate the interface is unavailable at that point.
You probably don't need to sleep at that point but after the reset. More like:
#!/bin/sh /bin/echo "AT^RESET" > /dev/cuaZ99.1 sleep 60 /etc/rc.linkup opt1 up
Steve
-
Hi Steve
I tried it (changed the interface).#!/bin/sh /bin/echo "AT^RESET" > /dev/cuaZ99.1 sleep 60 /etc/rc.linkup ppp0 up
Sadly with no success..
After the reboot the system trys to reconnect in an endless loop...
But then, if I place the following command over cron or putty, it connects successfully...
/bin/echo "AT^RESET" > '/dev/cuaZ99.1'
-
Ok but key in that log is that the port you are trying to use does not actually exist.
So what does exist at that point? Has it rearranged the ports so that is now cuaU1.0 for example?Does it not in fact see the modem at all so no ports are created?
In which case you might try using usbconfig to retrigger that process after the reset.Steve
-
The problem is that I can't connect to the firewall during log output (is remotely connected via VPN). I wait until the next reset is done by cronjob. After that it runs again. But I will try to check this on site.
Then I would have to check in the shell which cua* devices are visible? What is the best way to do this? And how could I do the reset with usbconfig? -
Yeah check the system log. Look in /dev.
Use
usbconfig -d ugen0.2 reset
or whatever the device is.
See: https://www.freebsd.org/cgi/man.cgi?query=usbconfigSteve
-
Hi Steve
Sorry, I had a lot to do the last Days. But now I tested wirh usbconfig. Sadly the same effect. If I set the command manually in the running system - it works. But if I use it as part of shellcmd the system does not connect to the modem.... I have no Idea what I can do. Currently I have an cron once a night, which runs "/bin/echo "AT^RESET" > '/dev/cuaZ99.1'". Thats working but is not a very nice solution.
Regards -
Well it looks like a timing issue so you should be able to set something that runs at boot, waits for the interfaces to be detected and the modem to cone up and then sends the AT reset. It's just a matter if finding the correct timing and using a command that doesn't prevent other things running while it waits.
Steve
-
Hi Darkred,
Does adding a boot delay to /boot/loader.conf help?
loader_delay="40"
I had to add a delay on my apu4d4. I followed these instructions:
https://teklager.se/en/knowledge-base/pfsense-lte-troubleshooting/Br,
nblind -
What can be the reason for this, or what can I do about it? I have already set the loader_delay to "40" - but it does not help.
I now see that you already did that.
I did not read carefully enough, sorry.Br,
nblind -
Hi @nblind
Thank you for your support.
I have already implemented the delay, that is correct. Unfortunately, my problem still exists. Currently I use a workaround. I reboot the device once a night and start a reset of the modem via cron 10 minutes later. So it works - for whatever reason.....
Best Regards