2

I have a raspberry pi 2 plugged into a (Vodafone New Zealand) 3G usb modem. It's a huwaei one. I have managed to get it working correctly, (I even wrote a rubygem to help with reading SMS's off the modem, and for 'connecting' and 'disconnecting' from the internet). However, I'm having real issues with the DNS and I was wondering if anyone might be able to help.

I have tried restarting it (with and without the usb modem attached) and various configurations in the /etc/network/interfaces mostly without joy. What I want is a bombproof way to restart it correctly, as the idea is to use the pi for remote monitoring of a water quality study site, and I want to be able to restart it remotely and make sure the 3G comes up correctly.

Some things which may help:

network interfaces I tried both static and dynamic, even specifying the nameservers.

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

auto usb0
iface usb0 inet static  
address 192.168.9.136
netmask 255.255.255.0
gateway 192.168.9.1
dns-nameservers 8.8.8.8

**dynamic interfaces

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

allow-hotplug usb0
auto usb0
iface usb0 inet dhcp

if I restart the modem with the usb stick plugged in, this is my route -n and ifconfig

eth0      Link encap:Ethernet  HWaddr b8:27:eb:26:70:3c  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

usb0      Link encap:Ethernet  HWaddr 02:0c:e7:0b:01:02  
      inet addr:192.168.9.136  Bcast:192.168.9.255  Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:200 errors:0 dropped:2 overruns:0 frame:0
      TX packets:196 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:13780 (13.4 KiB)  TX bytes:16124 (15.7 KiB)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.9.1     0.0.0.0         UG    0      0        0 usb0
192.168.9.0     0.0.0.0         255.255.255.0   U     0      0        0 usb0

if I start without the usb modem plugged in

eth0      Link encap:Ethernet  HWaddr b8:27:eb:26:70:3c  
      UP BROADCAST MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

This is the ping to google (honestly can't remember which of the variations this was on

PING google.com (192.168.59.5) 56(84) bytes of data.

--- google.com ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 17001ms

The slightly odd thing I noticed, was that on one of the pings, it started off pinging 192.168.9.1 , I think, certainly it was the gateway ip address.

Anyway, somewhat tearing my hair out here.. I feel like I'm 99% of the way there, but could really use a hand getting over the line! Thanks.

Finally, here is a (bad) traceroute to google.com if that helps

 traceroute to google.com (192.168.59.5), 30 hops max, 60 byte packets
 1  192.168.9.1 (192.168.9.1)  0.909 ms  1.599 ms  1.792 ms
 2  172.27.74.44 (172.27.74.44)  1141.241 ms  1143.081 ms  1143.172 ms
  3  172.27.66.219 (172.27.66.219)  1243.072 ms  1243.110 ms  1243.119 ms
  4  172.27.87.69 (172.27.87.69)  1275.568 ms  1275.273 ms  1242.989 ms
  5  172.27.87.70 (172.27.87.70)  1275.574 ms  1275.299 ms  1275.616 ms
  6  203.109.129.190 (203.109.129.190)  1275.370 ms  1242.945 ms  1242.237 ms
  7  203.109.129.189 (203.109.129.189)  1209.486 ms  105.834 ms  105.253 ms
  8  203.109.180.225 (203.109.180.225)  105.353 ms  133.821 ms  147.434 ms
  9  203.109.180.226 (203.109.180.226)  149.173 ms  147.342 ms  147.348 ms
 10  192.168.59.254 (192.168.59.254)  146.812 ms  82.653 ms  126.443 ms
 11  * * *

(just stars after 11->30)

Hmmmm, what's interesting is that if you ping one of the 203 addresses (e.g. http://mxtoolbox.com/SuperTool.aspx?action=ptr%3a203.109.180.226&run=toolpage )... is is actually a vodafone ip address. Why (the hell) it's then coming back with 192.168.59.254 is most strange (to me anyway)

finally ;)

If I unplug the 3G modem from the pi, plug it into my PC (running Ubuntu) it can ping google.. this is the traceroute I get.

  1  192.168.9.1 (192.168.9.1)  1.804 ms  2.166 ms  2.531 ms
  2  172.27.74.44 (172.27.74.44)  73.779 ms  73.889 ms  73.996 ms
  3  172.27.66.220 (172.27.66.220)  83.737 ms  83.979 ms  93.473 ms
  4  172.27.87.69 (172.27.87.69)  113.967 ms  113.959 ms  113.697 ms
  5  172.27.87.70 (172.27.87.70)  123.940 ms  123.683 ms  124.045 ms
  6  vl628.akl-grafton-bdr1.ihug.net (203.109.129.190)  124.164 ms  90.028 ms  89.777 ms
  7  fa0-0-628.pmr-tcl-core1.ihug.net (203.109.129.189)  89.883 ms  89.994 ms  89.611 ms
  8  be8-188.ppnzftc02.akl.vf.net.nz.180.109.203.in-addr.arpa (203.109.180.225)  90.218 ms  90.328 ms  99.321 ms
  9  UNASSIGNED.vf.net.nz (203.109.180.207)  99.562 ms  99.803 ms  109.548 ms
 10  * * *

I really don't get it!

1 Answer 1

1

Turned out (still don't quite know why) the /etc/resolve.conf had cached DNS settings from when eth0 was active, and it didn't update them for the usb0 ethernet.

Fix was to manually create /etc/resolve.conf and put in the nameserver details I wanted (I just used googles) So, all working now & happy days.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.