Printable View
Good question...
I could have sworn that all of the PPP and LCP negotiation had been done and the IP connection was alive. The other night I sat down to look at it again and the peer was rejecting the connection after the negotiation... I'm still digging in between "real life".
Ah. Could you post the ppp.log of the negociation? I could do the same from a 4.6.0.162 OS and check what differs.
I spent way too many hours on this today and I'm still drawing a blank. I've been playing with raw pppd scripts all day as well as the standard internet connection from Network preferences. I seem to get about the same results either way. It appears that the negotiation spins while trying to retrieve the DNS settings.
I've attached the logs from my Mac (mac2.txt) and also from my Ubuntu (8.10) machine. Ubuntu negotiates the connection just fine with the Bold, but the Mac won't negotiate the connection at all. Thus, while something may have changed in later Bold versions, it is likely also somewhat a problem with the Mac PPPD handling.
One thing that I noticed between the logs that may or may not have anything to do with the problem is the sending of ms-dns3 instead of ms-dns2.
Mac:
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Ubuntu:
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
The other thing that stands out to me as being different is the timing of the protocol requests. The Mac sends/receives very quickly, while the Ubuntu box spaces out the requests. It may be a situation where the peer is not fast enough.
That's what I have at this point. I've been staring at it for too many hours and I'm starting to go cross-eyed. I'm looking forward to seeing the logs from a working firmware to see if anything stands out.
Thanks,
Craig
It doesn't look like it allowed me to attach (probably because I'm a newbie on this forum?)
I put the files on my web server (mangled) to get them to post:
http: slash slash setera.org/misc/ubuntu.txt
http: slash slash setera.org/misc/mac2.txt
Here's a log from my working firmware (4.6.0.162) :
http slash slash pastebin.com/fe3c4c32
dns3 is part of mac's negociation, but does not prevent the working firmware to sucessfully bring the link up :
Sun Apr 19 09:01:49 2009 : sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Did you try to negociate a ppp link without the dns ?
hm okay there's definitely something related to the dns negociation, or something that happens at the same time. The two mac logs look exactly the same till the local and remote IPs are set. Then at some point the mac hosts asks for 3 dns settings :
Sun Apr 19 09:01:49 2009 : sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
And things start to differ from here :
On the working firmware, the remote host answers :
Sun Apr 19 09:01:49 2009 : rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <ms-dns3 0.0.0.0>]
Not sure what this ConfRej[ect] means but that's probably something to do with not serving a 3rd peer dns address. This ms-dns3 is gone forever in the rest of the negociation, which eventually succeeded. This line is not present in the b0rked firmware, and i suppose that is why the negociation loops while endlessy asking for this :
Sat Apr 18 20:40:40 2009 : sent [IPCP ConfReq id=0x8 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
and miserably fails.
Now the question is, why this reject is not present in the new firmware negociation? Maybe you're right and the flow is too fast to get interpreted... i honestly have no clue at this point. But all this looks that we may be able to fix it from the client side and not wait for a RIM solution.
I will spend some more time looking at this... I can say that one of the things I tried along the way was to tell it not to use the peer DNS which eliminated the calls for ms-dns, but still failed. BTW - it should be ms-dns1 and ms-dns2, not ms-dns3. I'm still not sure what Mac is up to there....
I couldn't even get my mac to recognize the bold as an outside drive. let alone tether. I tried downgrading and still nothing. it's like big bertha doesn't exist unless I use the windows partition.
I'm going back up to .247.
oh, so it does not loop on the ms-dns3 Nak but stills fails ?
Quick update. I've spent a good chunk of time playing with this today and I'm still unable to get things going correctly. I can get the negotiation to complete if I force a set of IP addresses, but in doing so, I end up without a working data connection. I chose the IP addresses based on the successful connection from my Ubuntu box and as you can see from the logs, ppp accepted those addresses. Unfortunately, that doesn't seem to be enough. I tested using Google's IP address just to see if I could get something going without DNS resolution, but no go.
The information can be seen at http: slash slash setera.org/misc/mactether/ From there you can see the pppd configuration files I've been using to try to get some control over the conversation as well as the relevant portion of my system.log file.
I've spent a lot of time perusing the pppd source code from the Apple Darwin project. While they have a large number of Apple-specific additions and alterations, I can't find anything specifically in there that would help or hinder.
I still wonder if the whole negotiation would work out if there was some way to slow it down and give the peer a chance to do something on their end. I've been unable to find any way to control the speed of the negotiation.
Given this new information, does anyone have any further thoughts or ideas? I'm willing to keep trying this, but will have much less time during the week.
wow, that's very impressive ! I used to play a lot with ppp on mac in a former life when I had to do callbacks. I'll give it a try tonight and try to slow down the negociation process.
your settings work as expected : i have a working ppp connection on the old firmware. There's something else i've noticed in my logs that does not appear in yours :
Sun Apr 19 09:01:49 2009 : rcvd [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 02 1f f3 ff fe 5b 32 3b]
Probably the ipv6 reject (as it does not appear when i'm launching ppp from the command line) but who knows.
I was wondering also if it keeps looping if you specifically ask for more retries (with lcp-max-configure set to 30). I'll upgrade my bold and do the tests, the grapewine says even the leaked new OS doesn't fix the tethering so we really need to work this out.
Cheers,
I look forward to your results. BTW - I tried all of the options I could to get it to keep negotiating longer. It seemed to ignore all of them and stop at the same point no matter what I did. I may have been doing something wrong, but I basically set all of the iteration values to 50 and it still ran the same number of iterations.
okay this is SO weird.
First of all, let me say that i'm posting this from my mac tethered with the new firmware.
see log here :
http slash slash pastebin.com/f34f93cb9
I don't know if i'll be able to do it again, and how this is all related but here's what i've done so far :
1. upgraded to 4.6.0.221 from parallels' XP.
2. Tried to dialup, didnt work, same error as always.
3. Tried to dial from the command line with the line :
pppd debug logfile /var/log/ppp-custom.log hide-password noauth connect "/usr/sbin/chat -v -f /Users/bruno/bb/ppp/BluetoothDialup-chat" /dev/cu.Bluetooth-Modem 115200 defaultroute user "orange" password orange defaultroute dump nodetach
and it worked somehow. ppp was up with an IP at both ends, but no connectivity, no DNS (even if usepeerdns was in the line), and absolutely no connectivity. There are tricks around to force the mac to update its "network awareness", often used it to make the OS take into account some weird proxying, but hey, to no avail. Even plain IP connectivity from the low-level didn't work , i sniffed it with wireshark and nothing but PPP echo stuff back and forth, but that was it.
4. I did something very stupid : i went back into system preferences, and changed the modem script to some Generic 3G CID 1 script i had been using with my former nokia phone : it didnt work, i had the same error as always with firmware 2xxx.
5. I CHANGED THE MODEM SCRIPT BACK TO Blackberry 3G and guess what, it *WORKED*. That's where i'm standing from right now.
I have no idea of what's going on, perhaps i just got lucky this time, but the same errors (less, though) are still present in the log as you can see in the pastebin url...
Okay i'll disconnect and try to come back, and let you know what happened!
this is even weirder. Now i'm stuck with the same 2xx error, and i'm positive i was connected 10mn ago with the exact same settings.
Sounds more and more like some sort of strange timing issue.
hah, i think i've found it.
I've managed to connect 20 times in a row, 100% success.
i *created* this file :
/etc/ppp/options.cu.Bluetooth-Modem
with
-- cut here --
dump
lcp-max-failure 5
-- cut here --
"dump" is just there to see what options are actually used by pppd, the real important line is lcp-max-failure 5 :
the man says :
Set the maximum number of LCP configure-NAKs returned before starting to send configure-Rejects instead to n (default 10).
that seems to do the trick !
is this working for you guys ?
-- UPDATE --
I confirm this is really working. I've rebooted, connected/disconnected 30 times and it's getting online every time :)
hmm
now it seems that i can connect on 75%... i thought i had it but maybe i've spoken too fast :(
anyway, here's the line that leads me to the same behavior as in NetworkPreferences, that is, 75% chance of success, and when it works, a full IP connectivity :
pppd debug logfile /var/log/ppp.log noauth \
connect "/usr/sbin/chat -v -f /Users/bb/ppp/BluetoothDialup-chat" \
/dev/cu.Bluetooth-Modem addifroute mru 1200 mtu 1500 novj receive-all \
ipcp-accept-local ipcp-accept-remote noccp defaultroute user "orange" \
password orange usepeerdns nodetach dump refuse-eap noipdefault \
lcp-max-failure 5 plugin PPPSerial.ppp
tomte: I'm unfortunately swamped with work and soccer practice.... not sure when I will be able to try these ideas. You mention that you get 75% success via Network Preferences? I've seen 100% failure via Network Preferences.
Well with this /etc/ppp/options.cu.Bluetooth-Modem file present AND dialing from Network Preferences i went from 0% success to 100%, and now that's 75%. I really don't know how this is all related, but it's definitely getting closer !
I'd like to try this out. How do I get the file you mentioned and where do I put it? (I'm on .266 beta right now)
Thanks!
wow, i'm back at 50% success now. I'm not sure creating this file will solve our problems.... Just create a options.cu.Bluetooth-Modem file in the /etc/ppp folder with the following lines :
dump
lcp-max-failure 5
If you're not used to the Terminal, here's a quick way to do it (Disclaimer : don't Go Use Terminal If You Don't Know What You're Doing)
touch /tmp/options.cu.Bluetooth-Modem.txt
open /tmp/options.cu.Bluetooth-Modem.txt
at this point Textedit will launch, just copy the two lines mentioned earlier, save and quit.
then
sudo cat /tmp/options.cu.Bluetooth-Modem.txt > /etc/ppp/options.cu.Bluetooth-Modem
But honestly i'd wait a little before trying this out, i'm sure we will be figure a safer way to do it if this really works out.
Timing, timing, timing <grin> Just teasing...
I won't claim to have any better answers, but in my nearly 20 years in software development, anything that isn't reproducible is almost always a timing issue.
One thing that would be interesting would be to compile the Darwin PPP code with an intentional delay in the configure requests. From what I saw in the code over the weekend, that is likely going to require compiling a whole lot more than just pppd. I'm not sure if that will be worth it, but it definitely isn't something I could consider doing before this weekend.
Some progress : i'm not sure it is the DNS negociation that is broken, but rather the noipdefault option.
Here's a simple test :
if i do a command-line pppd *without* noipdefault, the link is up *everytime* with no IP connectivity.
if i do a command-line pppd *with* noipdefault, the negociation fails the exact same way as Network Preferences do.