Trying to get ZTE MF710 dongle operational....[SOLVED-ish]

[rcrsn51]

Obviously, I'd like my mate to be on 64-bit, for the additional security it offers.

Please explain.

[starhawk]

I'll have a look at the tarball later -- I've got a busy day today, I'm afraid.

Look and see, though, if it's got a file labeled 'Makefile' anywhere in it. If it does, it will also have a file called 'INSTALL'. Set up the devx and read the instructions in INSTALL -- which should be pretty simple.

Usually it's navigate to the base of the folder tree and then either

Code: Select all

./configure
make
make install

or

Code: Select all

./autogen.sh
make
make install

In either case, it should be fairly uneventful unless you need to go dependency-hunting (which is fairly likely).

OTOH, if you *don't* see a Makefile in there, it'll require some noodling to figure it out. I can look at it but it'll be late afternoon or evening tonight.

[Mike Walsh]

Afternoon, all.

@starhawk:- I've never, ever been able to get the hang of compiling, mate. I follow all the instructions to the letter.....and it always goes wrong for me.

I've no real need for the thing anyway; I use BitMeterOS to keep an eye on my usage, and I top up via the ISP's website. It's somewhat redundant in my case; it doesn't do much more than what I've just stated.

I know the executables contained therein are 32-bit ELFs, but Tahr has it's 32-bit compat. libs, so I would expect it to work, in any case. Probably wouldn't in Slacko64, though, 'cos that doesn't have compat. libs.

---------------------------------------------

I think I spoke too soon about Tahr64 working with the ZTE. I definitely had the internet working in Chrome earlier today through the damn thing, 'cos I was posting from it.....but this afternoon, try as I might, I cannot reproduce the conditions (and I've tried literally everything.)

I'm now back to 'usb0' showing as a working, configured, 'live' network connection.....yet when you open a browser up (any browser!), it's the same thing, every time. 'This computer is not connected to the Internet', or variations on that theme, depending on the browser.

How the hell is this even possible? This is what I couldn't understand previously. How can you have a 'live', configured, working network connection.....yet have no internet access?

(It's definitely not the LAN or 'localhost'; I know what the subnet mask and assorted settings for those are, and these are not they.)

Hell, I've got an external IP address showing in 'Network Info', when I left-click on the network tray icon, as you would expect, but..... 'No internet connection'.

What's going on? If I could get to the bottom of this (and it's bound to be something small, stupid, and easily overlooked), then I'm betting I'd get it to work in Slacko64, too. 'Cos the conditions for Slacko64 are precisely the same as stated above. Live connection; 'no internet connection'.

I can't be the only person who wants to use a broadband dongle with the 64-bit Pups, surely?

(The 32-bit Pups continue to work happily with it, using the procedure I outlined above.)

?????

A somewhat perplexed

Mike.

[rcrsn51]

Once again, what's in resolv.conf?

Have you disconnected your ethernet? You can't do a proper test otherwise.

Run: ping 8.8.8.8

Do you get a response?

[Mike Walsh]

Hallo, Bill; getting a wee bit frazzled, here.

Okay. /etc/resolv.conf:-



This is the procedure I'm following every time, which worked earlier on. Plug the dongle in, wait for the icon to show on the desktop. Don't follow tallboy's mount/unmount procedure; leave it alone. (Although this appears to be necessary in the 32-bit Pups; they won't work with the ZTE unless I do.)

Then (no ethernet connected), click on the network tray icon:-



Click on 'usb0', followed by 'Test usb0':-



Click on 'AutoDHCP', which gives:-



Next, check 'Network Info'......wait a minute, wait a minute! Now I'm not showing an external IP address.... That's strange. What's altered? Hmm...



Naturally enough, then, the 'ping' test doesn't return anything:-



'Operation not permitted'. A root issue, perhaps? This is where I start to come unstuck; troubleshooting's never been my strongest suit. And yet, it works flawlessly with the 32-bitzers. I don't know why the difference.

Any suggestions? What do you think?

Quote:
Obviously, I'd like my mate to be on 64-bit, for the additional security it offers.

Please explain.

Perhaps I'm wrong here, but everywhere you look on the 'net, everybody and his dog seems to be of the opinion that 64-bit systems are more secure.

A 'fallacy', perhaps? I don't know. Why is the industry moving toward 64-bit, if security isn't a part of it.....along with the ability to access, and work with, far greater amounts of memory address space?

I'm no expert in such things, it's true.


Mike.

[rcrsn51]

In the IPInfo screen, click the Routing tab. Do both interfaces show a Gateway entry? If 192.168.1.1 is at the top, then you are not going to have an Internet connection.

If you reboot with Ethernet disconnected, there should be no gateway through eth0. There should also be NO nameserver line for 192.168.1.1.

However, there is a possibility that the device is connecting, then immediately disconnecting due to environmental issues.

[greengeek]

I think I spoke too soon about Tahr64 working with the ZTE. I definitely had the internet working in Chrome earlier today through the damn thing, 'cos I was posting from it.....but this afternoon, try as I might, I cannot reproduce the conditions (and I've tried literally everything.)

Any testing should be done in a pristine boot of the base pup without using any savefile. Otherwise your test session can be affected by conditions left over from previous testing/configuration.

In my experience most internet connection issues are the result of savefiles containing corrupted or at least irrelevant information from previous sessions.

This is the main reason i now run without savefiles.
.

[Mike Walsh]

Evening, all.

This is getting stranger by the minute. To add to the list of 32-bit Pups that will work with the ZTE, I'm posting this from Tahr 6.05 (32-bit).....with Ethernet diconnected, and /etc/resolv.conf showing 192.168.3.1 as the nameserver. And yes, I am getting an external IP address this time in IPinfo.

@greengeek:-

Just tried a pristine boot of the base Tahr64, using parameter 'puppy pfix=ram', so that it wouldn't pick up on the Tahr64 save-folder from the hard drive. Ethernet disconnected before powering on. Plugged the ZTE in, and waited for the desktop icon to come up.

Went into Menu>Setup>Internet Connction Wizard, picked 'Wired or wireless LAN', and 'Dougal's' to connect with. Repeated the previous steps exactly, to the letter. Still no joy; connection established, but no external IP.

So I don't think it's anything to do with a corrupted save-file/folder. And it still doesn't explain why the 32-bit Pups will run with the ZTE.....and the 64-bitzers won't.

What is it that the 32-bitzers have, which the 64-bitzers haven't? This is frustrating. I still think this has something to do with the across the board major re-working that's occurred with the two main, 'official' 64-bit releases. I could be wrong, but I don't think I'm far shy of the mark, if the truth be known.....

I wonder if it could be something as basic as the damn firewall.....'cos the new version is a PITA to work with. You can't see specifically what you're doing with it, like you could the old one.....and I don't understand the iptables ruleset well enough to know what I'm looking for, or how to interpret the output.

Right; next step, try again without the firewall. Watch this space.


Mike.

[rcrsn51]

In the 64bit Puppy, open a terminal and run

Code: Select all

dhcpcd usb0

[Mike Walsh]

In the 64bit Puppy, open a terminal and run

Code: Select all

dhcpcd usb0

Will do, Bill. Bear with me for a few minutes while I nip out for a smoke, re-boot and set a coupla things up.

Won't be long.


Mike.

[Mike Walsh]

Hallo again, Bill. I'm back.

Right, then. Output from

Code: Select all

dhcpcd usb0

...is as follows:-

Code: Select all

root# dhcpcd usb0
dhcpcd[18009]: version 6.6.2 starting
dhcpcd[18009]: all: IPv6 kernel autoconf disabled
dhcpcd[18009]: usb0: adding address fe80::df88:1af0:85ae:3f16
dhcpcd[18009]: if_addaddress6: Operation not supported
dhcpcd[18009]: usb0: waiting for carrier
dhcpcd[18009]: usb0: carrier acquired
dhcpcd[18009]: all: IPv6 kernel autoconf disabled
dhcpcd[18009]: DUID 00:01:00:01:1e:83:fb:3e:00:13:d3:57:17:a4
dhcpcd[18009]: usb0: IAID e7:0b:01:02
dhcpcd[18009]: usb0: carrier lost
dhcpcd[18009]: usb0: carrier acquired
dhcpcd[18009]: all: IPv6 kernel autoconf disabled
dhcpcd[18009]: usb0: IAID e7:0b:01:02
dhcpcd[18009]: usb0: rebinding lease of 192.168.3.136
dhcpcd[18009]: usb0: leased 192.168.3.136 for 86400 seconds
dhcpcd[18009]: usb0: adding route to 192.168.3.0/24
dhcpcd[18009]: usb0: adding default route via 192.168.3.1
dhcpcd[18009]: forked to background, child pid 18230
root# 

This is in Tahr64, ethernet disconnected, ZTE wireless device plugged in. There is, as usual, no internet connection.




'Routing' shows as this:-




Tell you anything you didn't already suspect?


Mike.

[rcrsn51]

There is, as usual, no internet connection.

Meaning that "ping 8.8.8.8" still fails?

I have no idea. It appears that the LAN side of the device is working correctly, but the WAN side is failing.

Unplug the device, count to 30 and plug it in again.

----------------------------

[greengeek]

Do you see anything in your browser if you type 192.168.3.136 in the url field?

And also what about 192.168.3.1 ?

[Mike Walsh]

Hi, all.

@rcrsn51:- Yes, ping still fails.....with identical output to last time. But why 32-bit and not 64-bit? That's what I can't understand......unless of course it's designed for 32-bit systems. Having only been released onto the market back in February 2014, I find that hard to believe.

@greengeek:-

Never thought of that. I'll give it a try, and see what shows up, if anything.

Bear with me.


Mike.

[Mike Walsh]

Do you see anything in your browser if you type 192.168.3.136 in the url field?

And also what about 192.168.3.1 ?

192.168.3.136:- 'This site refused to connect'. Please check your proxy and fire wall'

192.168.3.1:- Doesn't do anything at all. Hang about, I was going to check without the firewall enabled, wasn't I? I'd better give that a try, pronto...


Mike.

[rcrsn51]

192.168.3.136:- 'This site refused to connect'. Please check your proxy and fire wall'

That's not a surprise. That IP address is your machine and you are not running a web server.

192.168.3.1:- Doesn't do anything at all.

The modem also may not run a web server.

According to the interwebs, this kind of modem uses the kernel module cdc_ether. Check using "lsmod". Look for errors in "dmesg".

[Mike Walsh]

Well, well, well.

Looks like it was the firewall, all along. Having disabled it, disconnected Ethernet, plugged the ZTE back in, let it settle down, and run

Code: Select all

dhcpcd usb0

again in the terminal, I got the same readout as last time.....only this time, I now finally have an IP address! I'm posting this via the ZTE in Tahr64 right now.

Okay. Since I'm loathe to run without one (and I don't trust the router firewall, since I have no control over that), question now is how to set it up so that this beastie will run through it?

Any suggestions, people?


Mike.

[greengeek]

Is it 01mickos new firewall that is running in the 64bit pups? If so maybe he would be able to pinpoint a logfile somewhere that may have some info to offer about specific port activity or something?

[Mike Walsh]

Hi, Bill.

Output of 'lsmod':-

Code: Select all

lsmod
Module                  Size  Used by
cdc_ether               3880  0 
usbnet                 14926  1 cdc_ether
cfg80211              149648  0 
powernow_k8             8312  0 
xt_limit                1242  2 
xt_pkttype               792  1 
xt_LOG                  9216  11 
xt_conntrack            2280  6 
iptable_mangle          1080  0 
iptable_nat             1944  0 
nf_nat_ipv4             2250  1 iptable_nat
iptable_filter           984  1 
nf_conntrack_irc        3232  0 
nf_nat_ftp              1336  0 
nf_conntrack_ftp        5504  1 nf_nat_ftp
nf_nat                  7982  3 nf_nat_ftp,nf_nat_ipv4,iptable_nat
nf_conntrack_ipv4       4920  7 
nf_defrag_ipv4           984  1 nf_conntrack_ipv4
nf_conntrack           41360  8 nf_nat_ftp,nf_nat,nf_nat_ipv4,xt_conntrack,nf_conntrack_ftp,nf_conntrack_irc,iptable_nat,nf_conntrack_ipv4
ip_tables              11736  3 iptable_filter,iptable_mangle,iptable_nat
btusb                  13933  0 
bluetooth             171057  2 btusb
6lowpan_iphc            4648  1 bluetooth
rfkill                  6818  2 cfg80211,bluetooth
radeon               1000888  3 
snd_usb_audio          95344  0 
uvcvideo               53544  0 
snd_usbmidi_lib        13112  1 snd_usb_audio
videobuf2_vmalloc       1816  1 uvcvideo
videobuf2_memops        1176  1 videobuf2_vmalloc
videobuf2_core         19228  1 uvcvideo
snd_hwdep               4048  1 snd_usb_audio
videodev               76144  2 uvcvideo,videobuf2_core
psmouse                62121  0 
snd_atiixp              9136  0 
snd_ac97_codec         85001  1 snd_atiixp
snd_seq_dummy            825  0 
snd_seq_oss            17652  0 
snd_seq_midi            3312  0 
snd_seq_midi_event      3384  2 snd_seq_oss,snd_seq_midi
snd_pcsp                5225  0 
snd_pcm_oss            26544  0 
snd_mixer_oss          10200  1 snd_pcm_oss
snd_rawmidi            12384  2 snd_usbmidi_lib,snd_seq_midi
8139too                14905  0 
firewire_ohci          23776  0 
mii                     2792  2 usbnet,8139too
ttm                    49768  1 radeon
snd_seq                31176  6 snd_seq_midi_event,snd_seq_oss,snd_seq_dummy,snd_seq_midi
firewire_core          34522  1 firewire_ohci
snd_pcm                54448  5 snd_pcm_oss,snd_usb_audio,snd_ac97_codec,snd_atiixp,snd_pcsp
drm_kms_helper         25792  1 radeon
snd_seq_device          3500  5 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_dummy,snd_seq_midi
drm                   173992  5 ttm,drm_kms_helper,radeon
snd_timer              12882  2 snd_pcm,snd_seq
snd                    39968  14 snd_pcm_oss,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_seq_oss,snd_seq_device,snd_mixer_oss,snd_atiixp,snd_pcsp
k8temp                  2728  0 
hwmon                   1760  2 k8temp,radeon
i2c_algo_bit            3884  1 radeon
ac97_bus                 824  1 snd_ac97_codec
i2c_piix4               7220  0 
parport_pc             19220  0 
parport                22512  1 parport_pc
root#

Tell you anything? Like the second line;

'usbnet', used by 'cdc_ether'?

I mean, it appears the firewall was the culprit.....although it still keeps dropping out, periodically; but I'm putting that down to environmentals, myself.....as I explained earlier in the thread.

Explain one thing to me? I've seen this same statement many times on this and other forums; 'Check for errors in dmesg'. Is this another terminal command? And what errors are you supposed to look for? How do you know when you've found them? Does it tell you.....or is this something that only comes with experience?

Edit:- Just tried it. Still looks horrendously complicated to me, but there are several mentions of this:-

Code: Select all

'failed to execute '/etc/udev/mtp-probe' '/etc/udev/mtp-probe /sys/devices/pci0000:00/0000:00:13.2/usb1/1-6 1 18': No such file or directory'

I'm sending you a copy, if you'd care to have a skim through it. I'm guessing now that 'dmesg' is some kind of error log for the session, am I right?


Mike.

[Mike Walsh]

Hi, greengeek.

Yes, the 64-bit Pups (Tahr and Slacko) both use Micko's new firewall. What are you suggesting? That I PM him, and explain the situation, or something else? He's a busy fella; I may never get an answer..!

Anyway, look; I gotta hit the sack. It's getting pretty late over here, and I've got an early start in the morning. I'll catch you guys tomorrow, OK?


Mike.