|
Bugzilla – Full Text Bug Listing |
| Summary: | dial on demand with modem does not work | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Component: | Network | Assignee: | Hendrik Vogelsang <hvogel> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Minor | ||
| Priority: | P5 - None | CC: | behlert, lnussel, mvidner, werner |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Component Test | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 140732 | ||
| Attachments: | suggested patch for pppd (untested) | ||
|
Description
Forgotten User ZhJd0F0L3x
2006-01-25 22:40:07 UTC
i do not think that Robert is the correct assignee for this bug. This has nothing to do with NetworkManager, it is a smpppd/pppd issue IMO. setting
IPADDR="00.0.0.0"
^^
in the provider file fixes this.
The double 0 is important since smpppd explicitly checks for 0.0.0.0 and exchanges those for "" which in turn leads to the default of IPADDR=192.168.99.1;REMOTE_IPADDR=192.168.99.99 and that is rejected by my provider.
So a workaround exists.
The question remains why 0.0.0.0 is not valid and why we set the address to 192.168.99.1 at all.
You need IP fake addresses as long as you are not dialled in. It's strange that your provider rejects 192.168.99.99 but not 10.112.112.112 though. The latter is what pppd uses if you specify 0 as remote address. The reason why 00.0.0.0 works is that smpppd actually compares strings rather than the binary respresentation of the ip address. pppd then does compare the binary value and substitutes 10.112.112.112. So there is probably nothing to fix. ok, the local part is the interesting one. pppd behaves differently if you don't specify a local IP. It then uses 10.64.64.64 but doesn't tell the remote about that. If you manually specify any IP it will tell the remote. (In reply to comment #3) > You need IP fake addresses as long as you are not dialled in. Why? Care to comment the smpppd source? ;-) > It's strange that your provider rejects 192.168.99.99 but not > 10.112.112.112 though. Well, i get a 10.x address from my provider, this could be related. > The latter is what pppd uses if you specify 0 as remote address. But the log seems to suggest, that pppd actually _sends_ 0.0.0.0 to the dialin router. OTOH i am not too sure: PAP authentication succeeded sent [CCP ConfReq id=0x2 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] rcvd [LCP ProtRej id=0x1 80 fd 01 02 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] rcvd [IPCP ConfReq id=0x1] sent [IPCP ConfNak id=0x1 <addr 10.112.112.112>] rcvd [IPCP ConfNak id=0x3 <addr 10.129.182.74> <ms-dns1 212.23.97.3> <ms-dns3 212.23.97.2>] > The reason why 00.0.0.0 > works is that smpppd actually compares strings rather than the binary > respresentation of the ip address. pppd then does compare the binary value I figured this out from the source, this is why i tried this. The question is, why we special-case 0.0.0.0 at all. Let the user configure what he wants. YaST doesn't add this anyway IIUC, so if the user knows what he does, let him enter 0.0.0.0 and don't impose smpppds will on him. I assume this is a work around for some old version where YaST put in 0.0.0.0 into IPADDR when it should have left the variable just empty. > and substitutes 10.112.112.112. > > So there is probably nothing to fix. I Will try DOD with "IPADDR=10.23.45.67". Maybe this stupid provider is just rejecting everything out of his own address. I'd like to know what other OSs do when setting up the connection... "0.0.0.0" is not a valid address at all in some places it is interpreted as "not configured". We used it a long time as default for DOD with dynamic addresses,but it doesn't work in all cases, so far I remember some reports came from you for this 0.0.0.0 problem. And something is fishy here, since the log shows that we only offer 0.0.0.0 as addresses, but the other side offers nothing for it own address. Can you provide the same log without DOD, which was working if I understand your first line correctly. the initial report does include a "DOD - does not work" and a "!DOD - does work" log. It also works with DOD if i explicitly specify 0.0.0.00 Regarding comment #5: it does not work with 10.x.x.x instead of 0.0.0.0, so as soon as i send anything in the initial request, the connect fails. If you specify 0.0.0.00 pppd will configure your interface with 10.64.64.64 but doesn't send that to the peer. However if you specify 10.64.64.64 yourself pppd _does_ send that address to the peer. Apparently your provider doesn't accept any address. IMO the best fix would be to add a patch to pppd that lets you choose the local address you wish but makes pppd not tell the peer. The hardcoded 10.64.64.64 may not be appropriate in some networks (and neither the 192.168.99.1 of smpppd) so having it configurable is good. Created attachment 65814 [details]
suggested patch for pppd (untested)
Karsten any comments on that proposed patch? The patch looks good, from maintenance viewpoint, we should try to get this mainline too, but we can include it I think. I vote for mainline fist too as the original problem can easily be worked around by only specifying REMOTE_IPADDR ok ill try to get this upstream first... seife please try ipcp-no-addresses and/or ipcp-no-address thats whats upstream suggests instead of the patch ipcp-no-address: Feb 2 21:40:10 strolchi pppd[22605]: Serial connection established. Feb 2 21:40:10 strolchi pppd[22605]: Connect: modemB <--> /dev/rfcomm0 Feb 2 21:40:11 strolchi pppd[22605]: Remote message: Congratulations! Feb 2 21:40:11 strolchi pppd[22605]: PAP authentication succeeded Feb 2 21:40:12 strolchi pppd[22605]: Peer refused to agree to our IP address Feb 2 21:40:12 strolchi pppd[22605]: Connect time 0.2 minutes. Feb 2 21:40:12 strolchi pppd[22605]: Sent 619 bytes, received 188 bytes. Feb 2 21:40:12 strolchi pppd[22605]: Connection terminated. Feb 2 21:40:12 strolchi pppd[22605]: Hangup (SIGHUP) ipcp-no-addresses: Feb 2 21:41:30 strolchi pppd[22825]: Serial connection established. Feb 2 21:41:30 strolchi pppd[22825]: Connect: modemB <--> /dev/rfcomm0 Feb 2 21:41:31 strolchi pppd[22825]: Remote message: Congratulations! Feb 2 21:41:31 strolchi pppd[22825]: PAP authentication succeeded Feb 2 21:41:33 strolchi pppd[22825]: LCP terminated by peer Feb 2 21:41:33 strolchi pppd[22825]: Hangup (SIGHUP) Feb 2 21:41:33 strolchi pppd[22825]: Modem hangup Feb 2 21:41:33 strolchi pppd[22825]: Connection terminated. both: i can dial in, but i do not get a ip adress from the remote side: root@strolchi:/etc/ppp/ip-up.d> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.99.99 0.0.0.0 255.255.255.255 UH 0 0 0 modemB 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 cable 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.99.99 0.0.0.0 UG 0 0 0 modemB which is not very useful. i also enable ipcp-accept-remote and ipcp-accept-local but it did not help. i can provide logs for all those with "debug" if needed. please provide me with debug. i have to see whats going on in LCP i'll do, but this is low-prio right now. There's been no answer for nearly a year. Please reopen once you have the requested information. Instead of simply closing it, just remember Stefan about his comment #17 Stefan? Do have done the test? |