This is the old SliTaz forum - Please use the main

[Solved] Dialup internet problem in Cooking 20100314
  • marquiticomarquitico March 2010
    When trying to connect to the Internet, I can only receive data from secure (https://) sites. Never encountered anything like this. Usually an Internet connectivity problem is all or nothing: either you're connected or you aren't.

    My connection is an old fashioned analogue dial-up modem type. I use a USRobotics 56K V.92 external serial port faxmodem on COM1 (/dev/ttyS0). I snagged the wvdial, wvstreams, OpenSSL, and linux-dialup packages, and they installed just fine. wvdialconf detected my modem right away, and filling in the required fields in /etc/wvdial.conf was easy. wvdial called my ISP and it logged in with no trouble. Watching the console messages I saw that I got an IP address and DNS addresses. There was an /etc/resolv.conf file with those nameservers listed, and it had appropriate permissions. But I couldn't surf.

    After trying several web addresses with no response, I tried one with some secure and some non-secure items, and only the secure items came in. This was the big clue, and I tried several secure sites (https://), and lo and behold, they all came in fine. Only non-secure sites didn't respond. Ping is the same, so it's not limited to Midori. I have two ISPs, actually, and they displayed the same problem.

    This only happens on Cooking 20100314. Stable-2.0 makes pppd connections just fine on my machine, as do other Linuxes, plus one FreeBSD distro. Is there anything else I should tell you? I'm an end-user with a few years' experience with Linux of various flavors, but no expert by any means. Does this problem ring any bells for anyone?

    Thank you in advance.

    Oh, the linux-dialup package: was it sufficient just to install it, or should I have modprobed something from there after installing? Just a thought.
  • marquiticomarquitico March 2010
  • marquiticomarquitico March 2010
    Same thing now happening in 3.0. Can only receive data from https:// sites, not http://. No one has any ideas, thoughts on how to help me?
  • marquiticomarquitico April 2010
  • mojomojo April 2010
    Sometime in December 2009 the cooking kernel configuration was changed that broke things in networking. The ndiswrapper driver for wireless networking adapters quit working. I would suspect the problem your having is caused by the kernel change as well.

    I install the kernel from cooking november 2009 in Slitaz 3.0 to fix.

  • marquiticomarquitico April 2010
    Thank you for your explanation! I'm disappointed, but also relieved to know that it's not my fault...Where can I get the Nov 2009 Cooking? Been searching the mirrors with no luck. And can anyone either explain installing a different kernel or point me to online instructions?

    Thank you.
  • marquiticomarquitico April 2010
    Anyone help me locate a Cooking 20091104 iso? I cannot locate anything other than current version to try my hand at what mojo suggested...
  • erniaernia April 2010
    Mabe Mojo could somehow give you the output of
     zcat /proc/config.gz
    so you could diff from the output of the same command with 3.0 kernel to check for difference.
    Do you have the same problems in Firefox? Please, try before you answer, i've read about ping but you never know...
    Can you post the output of lsmod?
  • marquiticomarquitico April 2010
    Thank you for your comment! I will not be back on my own computer for a couple of days, but as soon as I've tried it out I'll post back with what I find.
  • erniaernia April 2010
    you may want to check your firewall rules as well.
    http requests are directed to port 80 while https requests are directed to port 443, and this would explain ping behavior too.
    what is the output of
    iptables -L
    as root?
    i don't use slitaz's firewall, i'm used to arno-iptables-firewall, so i don't know if it runs automatically at startup, as it could seems reading /etc/rcS.conf. if it runs it sources /etc/firewall.conf , where default interface is eth0, maybe you may want ppp0 instead, or ppp+ , which (if i'm not wrong, don't have time to check it) should catch every ppp interface
  • marquiticomarquitico April 2010
    OK, my lsmod output looks like this:

    Module                  Size  Used by    Not tainted
    rtc 9136 0
    intel_agp 23032 1
    agpgart 25980 2 intel_agp
    snd_riptide 18472 1
    snd_ac97_codec 88736 1 snd_riptide
    ac97_bus 1308 1 snd_ac97_codec
    snd_pcm 51780 2 snd_riptide,snd_ac97_codec
    snd_opl3_lib 7948 1 snd_riptide
    snd_timer 16344 2 snd_pcm,snd_opl3_lib
    snd_hwdep 5988 1 snd_opl3_lib
    snd_page_alloc 7256 2 snd_riptide,snd_pcm
    gameport 9348 2 snd_riptide
    snd_mpu401_uart 5612 1 snd_riptide
    snd_rawmidi 16920 1 snd_mpu401_uart
    snd_seq_device 5544 2 snd_opl3_lib,snd_rawmidi
    snd 43584 11 snd_riptide,snd_ac97_codec,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
    soundcore 5180 1 snd

    I can post the zcat /proc/config.gz output, too, but it's huge, as I'm sure you know. What sections are relevant that I can cut out and paste, or should I just give it all?

    I missed your last post, so I will report back with the iptables -L output.

    Meanwhile, you must bear with me a bit. Since I can't get online, I have to snag the packages for Firefox while out of distro, so I have to resolve the dependencies by hand.
  • marquiticomarquitico April 2010
    OK, no firewall running. I ought to have known, because iptables is a separate package that I never installed, duh. But just for thoroughness iptables -L produces "Not found".

    Firefox is giving me a small pain. I think I have all the dependencies resolved, as tazpkg doesn't complain, but the app breaks when I try to launch it. Maybe out of memory? I'll try to get the Firefox "flavor" and see what happens there.
  • marquiticomarquitico April 2010
    I made it online!! To cut to the chase, I'm using the Firefox-3.0.iso flavor. Many thanks to ernia for the suggestion.

    I returned to "plain" 3.0 and to Cooking, and I can verify that they're still not working no matter what I try to do with them. Is it the Midori installation that is goofing it up? Or maybe it's actually missing something? Well, I'm only a layman in that regard, so I have no way to tell.

    I leave it to a friendly moderator to decide whether or not this ought to be marked solved. From my user-end perspective, it is: I have what I wanted. From a distro maintainer's point of view, maybe not, because it doesn't explain why pppd doesn't work on the "plain" release version.

    I have verified that lsmod on this .iso is identical to the one I posted above. I will check the contents of config.gz later, if anyone is interested. Oh, and yes, ping is working here on the Firefox flavor, too.

    I understand that fewer and fewer users rely on old-fashioned analogue dial-up, so there are few opportunities to test that type of connection. If anyone wants me to go back to "plain 3.0" and test-run possible solutions, I'm willing to try.
  • erniaernia April 2010
    i use dialup with a nokia phone and i have no problem with midori or firefox.
    It must be something very tied to your system.
    Changing your OS to a brand new Firefox-3.0.iso flavor could have cleaned up something wrong with your previous configuration, but if you have tried a plain install of 3.0 and cooking with no result it should not depend on it.
    It could be useful to debug this thing to install midori in the firefox flavor.
    If you can browse with firefox and not with midori it could be something related to midori/libwebkit, if not you could try to install firefox in the plain 3.0. it firefox does not works could be related to ppp setup in plain 3.0.
    You don't need to check config.gz anymore because kernel should be the default slitaz one in firefox flavor too.
  • marquiticomarquitico April 2010
    OK, Midori installed upon "Firefox-3.0" works fine. I'm using it to type this, actually. Firefox installed upon "Plain 3.0" (which ships with Midori) does not change the original problem, described above.

    Shall I try something else?
  • erniaernia April 2010
    if "Plain 3.0" is a brand new install of slitaz and not your previous install this would be an interesting case, it would means that there is something wrong with plain 3.0 and your system. if you have both install you could search for difference in kernel configuration in the two flavours making a diff between the two files resulting from
    zcat /proc/config.gz > firefox.kernel
    zcat /proc/config.gz > midori.kernel
    . You could search for difference in ouput of
     ls -la /etc/init.d/firewall
    tazpkg list

    and in what's related to ppp in general.
    beware that probably you are in internet without a firewall, you better install iptables edit your /etc/firewall.conf to use ppp0 or ppp+ as your network interface and, if it's not already executable, make executable /etc/init.d/
  • marquiticomarquitico April 2010
    If I install Firefox upon "Plain 3.0", lsmod and zcat /proc/config.gz are the same according to diff in both flavors. If I install Midori onto "Firefox 3.0", then the tazpkg install list is the same as well. Sheesh. I feel like I'm back in the old MS-DOS 5.0 days, trying to work out the bootup load order for my TSRs. Just one tiny thing out of order and it doesn't work...

    So why doesn't "Plain 3.0" work right out of the box?

    So far as "clean install" is concerned, when I first had this problem in Cooking I decided not to install anything, so all of these are running as live CDs in RAM with no persistence, making each bootup essentially clean. The only one I saved to a persistent storage was 2.0, because it worked straight off.

    Thank you for the advice about the firewall. Since I'm running these live, I also don't bother to mount the harddrive, so I'm fairly well insulated against malicious activity. If I can get the kinks worked out and then saved to a pendrive, I'll put it in.
  • Solution: make Midori self-identify as Firefox.

    Comment: again (like in another thread), the problem wasn't what I thought it would be. Turns out that not only webpages, but also ISPs employ browser-sniffing. Some ISPs, apparently, will not open the "gateway" to the wider WWW to you, even if the password handshake succeeds, if they don't like your browser useragent string. So if I'm on "Plain 3.0" and Midori is, therefore, the only browser, it's too unrecognized to be univerally accepted at this time.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social