I have a Huawei E3351 3G dongle connected to a Pi which requires maximum unattended uptime. Ensuring that the connection remains solid over time has been a troublesome endeavour, largely due to unfamiliarity with the environment and best practices to manage this connection. I currently use usb_modeswitch to achieve the modem mode on the 3g dongle. sudo udevadm trigger is called to manually perform the modeswitch if Raspian did not achieve this.

At an unknown length of time from powering up the Pi, the 3G connection will drop, anywhere from a few minutes to a few weeks. A primitive method to fix this was just simply restarting the Pi via sudo reboot. We can probably all agree that this would be bandaid solution rather than addressing the root cause. However, the problem occasionally persisted over reboots, and required a physical power cycle (disconnecting and reconnecting the power to the Pi) in order to work.

A new method was to employ a script that takes down the network interface, cycles power on the USB bus, and brings the network interface back up:

ifdown etho0
sleep 1

echo 0 > /sys/devices/platform/bcm2708_usb/buspower

sleep 1

echo 1 > /sys/devices/platform/bcm2708_usb/buspower

sleep 2
ifup etho0

However, this exposed an issue which I believe is the real problem that requires addressing:

Listening on LPF/etho0/ADDRESS
Sending on LPF/etho0/ADDRESS
Sending on Socket/fallback
DHCPRELEASE on eth0 to port 67
send_packet: Network is unreachable
send_packet: please consule README file regarding broadcast address.
ifup: interface etho0 already configured

The current idea is to just increase the sleeping period between the power cycle from 1 second to 5 seconds. Testing this strategy is difficult, as it is unknown when the problem will manifest. It also feels like another bandaid solution rather than addressing the root cause.

What strategies can I employ to overcome this problem? Are there any further calls I can perform to further increase reliability?

Please let me know if you need more context.

  • When you say "the real problem" what are you referring to? I notice there's a DHCP event on eth0 (not etho0). Is that actually connect and are you meaning to use it? – goldilocks Aug 10 '15 at 12:35
  • eth0 is the connection to the 3G device. Typically, when the ifdown buspower ifup is run on a stable 3G connection, the connection will go down and come back. If the 3G connection has 'dropped' after a random length of time, this strategy does not work. The buspower command does not remove power from the device, but rather a smaller voltage to facilitate the USB communications, leaving over 5V running through the 3G device. The next step could be a GPIO switch in order to cut the main USB power, but I am wondering if I can 'wipe the slate clean' to re-establish the 3G programatically. – damaca Aug 11 '15 at 0:54
  • Would have been useful to see your usb_modeswitch script or options used. Did you ever resolve this problem? Also note that USB power is probably stabilized with condensers, so you'd have to wait far longer than one second, perhaps 5-10 s. – not2qubit Feb 24 '17 at 14:36
  • As mentioned in the previous comment, the workaround we devised was to kill power completely to the dongle, in addition to the other strategies. It was the simplest solution at the time with respect to our limited knowledge of the networking process. We have since shifted away from the 3G dongles to a more relevant comms system for our application. Sorry! – damaca Feb 25 '17 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.