Page 7 of 9 FirstFirst ... 23456789 LastLast
Results 121 to 140 of 169
  1. #121  
    Quote Originally Posted by sq5 View Post
    I'm thinking of adding a line to the event.d script to echo the number 1 into /proc/sys/net/ipv4/ip_forward at bootup, and also, if possible to add a cron job that will make sure the it stays set to 1 on a regular interval, like every minute.
    I tried adding it to my optware-dropbear script and it didn't work. The cron job might work but seems like a lot of overhead for something I can just do manually when I need it. Fortunately I don't tether all that often.
  2. #122  
    I wonder if the file is being recreated each time or copied from a different location and over writing it self.
    MatterOfFactJack
  3. #123  
    Quote Originally Posted by Prefect View Post
    I tried adding it to my optware-dropbear script and it didn't work.
    I added the line I was mentioning to the /etc/event.d/ipforward script right below the iptables line, and after a reboot it does appear to work, at least for one tethering session. This way, at least you can get tethered after a reboot without rooting into the phone, or other manual intervention.

    here is what the script looks like now...


    start on stopped finish
    stop on runlevel[!2]

    console none

    pre-start script
    /usr/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
    echo 1 > /proc/sys/net/ipv4/ip_forward
    end script



    Quote Originally Posted by Prefect View Post
    The cron job might work but seems like a lot of overhead...Fortunately I don't tether all that often.
    I only tether once in a while too, but I might still try the cron job too. All the job would do is write a single character into a text node, which completes instantaneously, so even if it happens as much as once a minute, it would be imperceptibly negligible.


    Quote Originally Posted by Prefect View Post
    ...something I can just do manually when I need it...
    Btw, are you rooting into the phone via USB to manually change the 0 to 1? Or are you (or anyone else) able to get root access somehow (sudo maybe?) after connecting via SSH? If I could avoid having to go to developer mode for doing things like this, it would be much more convenient.
  4. #124  
    Quote Originally Posted by jack87 View Post
    I wonder if the file is being recreated each time or copied from a different location and over writing it self.
    Interesting thought! I tested that idea by copying the 1.3.1 version of PmNetConfigManager into place again, since I know it has a different file size than the 1.3.5 version, figuring that if the PmNetConfigManager file gets recreated from a different location, the file size should change back to reflect that of the 1.3.5 version again. After leaving it for a while and manually tinkering, it didn't seem to change, so I don't think thats the case.
  5. #125  
    Quote Originally Posted by sq5 View Post
    Interesting thought! I tested that idea by copying the 1.3.1 version of PmNetConfigManager into place again, since I know it has a different file size than the 1.3.5 version, figuring that if the PmNetConfigManager file gets recreated from a different location, the file size should change back to reflect that of the 1.3.5 version again. After leaving it for a while and manually tinkering, it didn't seem to change, so I don't think thats the case.
    Very interesting. Is the code located on the same line on both files?
    MatterOfFactJack
  6. #126  
    Quote Originally Posted by sq5 View Post
    ... echo 1 > /proc/sys/net/ipv4/ip_forward
    ...

    Btw, are you rooting into the phone via USB to manually change the 0 to 1? Or are you (or anyone else) able to get root access somehow (sudo maybe?) after connecting via SSH? If I could avoid having to go to developer mode for doing things like this, it would be much more convenient.
    You are correct - that works! Duh, I screwed up the echo by leaving out the ">".

    I'm connecting as my user account using putty by either bluetooth or usb cable. Then sudo -i and do my thing. The phone doesn't have to be in developer mode to do that.
  7. #127  
    What about a udev rule triggered when USB cable is connected to the PC? This rule could simply contain a RUN attribute which would point to a short script with an echo statement?
  8. DrewPre's Avatar
    Posts
    818 Posts
    Global Posts
    829 Global Posts
    #128  
    okay, so not sure what I have done differently but I am appearing to have tethered inet connection on my PC via the Pre even after a disconnect and reconnect and a restart.

    Here's what I did while it's still fresh in memory....

    first thing I did was issue the iptables command to make sure that it was still valid post 1.3.5 update.

    I then, issued the echo 1 > /proc/sys/net/ipv4/ip_forward command.

    after doing this I made sure I could connect to the internet.... success!

    I had to use the up arrow and re-issue the echo command serveral times while waiting for various webpages to finish loading. At least untill......

    I stopped PmNetConfigManager and edited the PmNetConfigManager file using VI in Novaterm. I suspect that others are using VI in Putty. I don't use Putty. I use SSH Secure Shell. VI acts really weird in SSH Secure shell. Maybe it also acts weird in Putty as well, I don't know. but when searching for 'forward' in VI via SSH Secure shell, the cursor is moved to a line 3 lines below the word 'forward'. This is corrected by using Novaterm to shell into the Pre. Maybe in Putty, you think you're on the correct line, but you're really not. I don't know... I just know VI acts funny in SSH Secure Shell.

    My tethered PC still has access to the Internet. I no longer have to use the up arrow key and keep re-issuing the echo command to the ip_forward file.

    I edited the optware-dropbear file to include the echo command and rebooted. I still have inet accesss on the tethered PC.

    So it appears that tethering is still working with this edit. at least for me! I will let you guys know when/if this changes.
  9. #129  
    Quote Originally Posted by DrewPre View Post
    I stopped PmNetConfigManager and edited the PmNetConfigManager file using VI in Novaterm. I suspect that others are using VI in Putty. I don't use Putty. I use SSH Secure Shell. VI acts really weird in SSH Secure shell. Maybe it also acts weird in Putty as well, I don't know. but when searching for 'forward' in VI via SSH Secure shell, the cursor is moved to a line 3 lines below the word 'forward'. This is corrected by using Novaterm to shell into the Pre. Maybe in Putty, you think you're on the correct line, but you're really not. I don't know... I just know VI acts funny in SSH Secure Shell.
    I feel like I missed something.
  10. #130  
    To be honest, tethering has been working flawlessly for me as well in 1.3.5. THese are the steps I took:

    stop PmNetConfigManager
    modified PmNetConfigManager (using vi)
    start PmNetConfigManager
    echo 1 > /proc/sys/net/ipv4/ip_forward
    added this echo statement to /etc/event.d/ipforward below the iptables rule


    and that's it. The value stays at 1 after a reboot and it also stays at 1 after multiple connects/disconnects. I've been using it for about 2 days now and it's no problems whatsoever.

    P.S. Obviously, don't forget to edit dnsmasq.palm.conf over again because it gets overwritten by the update.
  11. DrewPre's Avatar
    Posts
    818 Posts
    Global Posts
    829 Global Posts
    #131  
    Sorry, grndslm.... I know i didn't write that very well. It's a bit confusing.

    Basically, SSH Secure Shell is a client jsut like Putty. SSH Secure Shell doesn't play well with VI. My suspicion...with no evidence to support....is that Putty may have similar issues with VI although they may not be as obvious.

    I had to use Novaterm to Shell [root] into the Pre and use VI. It's more consistent with what I expect to see from VI.
  12. DrewPre's Avatar
    Posts
    818 Posts
    Global Posts
    829 Global Posts
    #132  
    So far my experience has been the same as Alkos333
  13. #133  
    I followed these instruction exactly yesterday and then continued with the tut on webos-internals (with the exception that I editted the PmNetConfig file rather than the older PmConnection file). My computer recognizes my Palm Pre as a network upon plugging it into usb. I now have the option to connect to the internet with "Auto etho0" or "Auto usb0" in Ubuntu 9.10! Thanks!
  14. #134  
    Quote Originally Posted by alkos333 View Post
    To be honest, tethering has been working flawlessly for me as well in 1.3.5. THese are the steps I took:

    stop PmNetConfigManager
    modified PmNetConfigManager (using vi)
    start PmNetConfigManager
    echo 1 > /proc/sys/net/ipv4/ip_forward
    added this echo statement to /etc/event.d/ipforward below the iptables rule


    and that's it. The value stays at 1 after a reboot and it also stays at 1 after multiple connects/disconnects. I've been using it for about 2 days now and it's no problems whatsoever.

    P.S. Obviously, don't forget to edit dnsmasq.palm.conf over again because it gets overwritten by the update.

    Strangely, thats what I did too, to the letter as far as I can tell, but with the partially unsuccessful results some of us have had since 1.3.5. Like DrewPre, I have always been using novacom to get into the root shell for editing with vi, so that doesn't seem to be my issue.

    Any chance you can upload your edited and/or original PmNetConfigManager files someplace for those of us to try again with?
  15. #135  
    For reference, I have only ever tethered over bluetooth, and not over usb.
  16. #136  
    Quote Originally Posted by sq5 View Post
    Strangely, thats what I did too, to the letter as far as I can tell, but with the partially unsuccessful results some of us have had since 1.3.5. Like DrewPre, I have always been using novacom to get into the root shell for editing with vi, so that doesn't seem to be my issue.

    Any chance you can upload your edited and/or original PmNetConfigManager files someplace for those of us to try again with?

    PM me your email address.
  17. #137  
    PM sent.
  18. #138  
    While I try and get to the root of the issue some are having since 1.3.5, I came up with a much more convenient workaround for manually re-enabling tethering if it gets disabled.

    Currently, by adding the right echo command to /etc/event.d/ipforward as described previously, a user can at least get one good tethering session connected. After that, they would need to reboot the phone to tether again.

    I wanted to avoid having to go through a full reboot, or having to ssh into the phone manually to issue a command. If possible, I also preferred not to install or configure any additional software like crond just for addressing this problem.

    Since I tether over Bluetooth, I wanted to tie the workaround to that. (You can still use this workaround even if you don't tether over Bluetooth). I discovered that the Bluetooth control in the GUI calls /usr/bin/PmBtStart momentarily. By adding an echo command just after the beginning of the script, I can now re-enable my tethering by just turning off Bluetooth from the GUI menu, and then turning it back on. After editing PmBtStart, it should look like this at the beginning:


    #!/bin/sh



    echo 1 > /proc/sys/net/ipv4/ip_forward
    DevType1() { grep TWL4030 /proc/interrupts; }

    # don't use highspeed UART

    NOHU=/var/log/NOHU



    # Startup script to load CSR stack and start Bluetooth Engine


    .
    .
    .
    .
    .

    Be sure to add the echo command at the beginning of the file, as shown...it won't work if added to the end (anyone know why that makes a difference? just curious).

    As a tip, you should full cycle the Bluetooth setting for this to work right. So for instance if you BT is still on, turn it off then back on. But if it is already off, you can just turn it on, then off, and then back on. Sorry if I'm making this all sound more complicated than it is.

    Hope this helps anyone who is having an issue, and wants a simple way to re-enable tethering right from the GUI without rebooting, shell commands, or additional processes.
  19. jettca1's Avatar
    Posts
    28 Posts
    Global Posts
    29 Global Posts
    #139  
    Well done, sq5! This worked for me just as you said. ip_forward was 0, then 1 after restarting bluetooth. This solution also makes sense in the normal scheme of trouble-shooting. The first thing I do when my tether doesn't work is restart Bluetooth.

    I was worried about losing this hack. I love that it's so command-line-based. It's easy to squash a tether app - not so easy to track CLI mods.

    Well done, all.
  20. #140  
    can we get an updated first post as some of the files have changed?
Page 7 of 9 FirstFirst ... 23456789 LastLast

Posting Permissions