Bug#265183: pppoe workaround of the post-reboot problem
On Sep 24, Vassilii Khachaturov [EMAIL PROTECTED] wrote: Then you are not using PPTP to your modem but to your ISP, your modem is behaving correctly and you don't need pppoeconf at all, because there is no way we can know the details of PPTP tunneling used by every provider. pppoe does run locally over the eth0, and the modem is correctly discovered as the concentrator on the local Ethernet network by the pppoeconf. Then you are NOT using PPTP as I hypothesized... But if your modem is a modem using PPPoE then it's not supposed to have the DHCP server running, and it's even more not supposed to provide a default route to itself, as it's not a router. OTOH you say that at the same time you are able to reach your ISP's servers in net 10 without starting pppd, but this is impossible. So I will have to conclude that you are either very confused or we cannot reliably communicate, and this bug report is bogus. Please don't send me a reply unless you can point to a specific bug in pppd or at least pppoeconf. -- ciao, | Marco | [8196 bo9j.hNl3cPKo] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
Then you are not using PPTP to your modem but to your ISP, your modem is behaving correctly and you don't need pppoeconf at all, because there is no way we can know the details of PPTP tunneling used by every provider. pppoe does run locally over the eth0, and the modem is correctly discovered as the concentrator on the local Ethernet network by the pppoeconf. Look at the 2 1st messages on the 265183 bug thread where the (working) interfaces and dsl-provider details are dumped. Please note that as long as the interfaces file was hacked to statically assign the local (host to modem) LAN address statically, pppoeconf did everything correctly afterwards. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
Marco has pretty much summed it up. I fail to see though why the modem asking the host to consider the modem the default gateway is a bug. The routing Because the modem is not a gateway and will not work as such? [snip] If the speedtouch DHCP server really provides a default route when it's configured for PPTP tunnels (something which I doubt and I think should be verified) It is a gateway and does work as such. Did I not write in my last e-mail that *without* starting pppoe one can reach the provider's WAN via the default route going via the speedtouch? As for the verification, doesn't the routing table I reported in the 1st mail in the thread suffice? I'll be happy to do any additional verifications if you want. *maybe* pppoeconf could check if the local address is 10.0.0.1 and 10.0.0.138 is the modem: if ping ... 10.0.0.138 \ wget --quiet --output-document=- http://10.0.0.138/welcome.htm \ | grep -q '^HEADTITLEADSL Index'; then echo yes fi Then it would have to check if the PPTP server is enabled. Unfortunately, .138 is the firmware default of my modem, but a lot of folks reconfigure the address; I can also imagine other models using addresses other than .138. As pppoeconf already discovers the modem by its own means, so I don't think the hardwiring saves a lot of coding. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Sep 23, Vassilii Khachaturov [EMAIL PROTECTED] wrote: It is a gateway and does work as such. Did I not write in my last e-mail that *without* starting pppoe one can reach the provider's WAN via the default route going via the speedtouch? Then the modem is configured as a router and you don't need need PPTP at all... Unfortunately, .138 is the firmware default of my modem, but a lot of folks reconfigure the address; I can also imagine other models using Their problem. addresses other than .138. As pppoeconf already discovers the modem by its own means, so I don't think the hardwiring saves a lot of coding. It does not discover the IP address. -- ciao, | Marco | [8119 feRgDBQtRyAFQ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
It is a gateway and does work as such. Did I not write in my last e-mail that *without* starting pppoe one can reach the provider's WAN via the default route going via the speedtouch? Then the modem is configured as a router and you don't need need PPTP at all... Marco, you seem to have forgotten another portion of the info I had mentioned earlier in the thread (to another portion of the same mail I had referred in the text you've just quoted!). While my traffic is routed to the WAN, being a 10. address it is NOT routable outside of it. Therefore, to get to the global Internet space, I need to establish PPTP. (A bit OT: I can still be using the provider's WAN e.g. to use their DNS forwarders rather than going to the DNS via the PPTP tunnel, but that would require me to add routes also to the DNS servers on the provider's LAN. This complication is not worth the negligible benefit of using the DNS. Overall, for a clean solution I should have the modem negotiate with my computer using a routing protocol and tell it about the provider WAN IPs reachable via the ethernet link to the modem, but this option is not provided, at least not in the default SpeedTouch config. Anyhow, this is not relevant to the pppoeconfig discussion.) Unfortunately, .138 is the firmware default of my modem, but a lot of folks reconfigure the address; I can also imagine other models using Their problem. Agreed, at least until a lot of folks complain :) addresses other than .138. As pppoeconf already discovers the modem by its own means, so I don't think the hardwiring saves a lot of coding. It does not discover the IP address. It knows its Ethernet address, it's the same LAN, and I bet it can send a RARP request to obtain one. Anyhow, as I am not giving a script patch and you do, I think that a hack that does what is needed in the most common case is definitely better than nothing. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Sep 23, Vassilii Khachaturov [EMAIL PROTECTED] wrote: Then the modem is configured as a router and you don't need need PPTP at all... Marco, you seem to have forgotten another portion of the info I had mentioned earlier in the thread (to another portion of the same mail I had referred in the text you've just quoted!). While my traffic is routed to the WAN, being a 10. address it is NOT routable outside of it. Therefore, to get to the global Internet space, I need to establish PPTP. Then you are not using PPTP to your modem but to your ISP, your modem is behaving correctly and you don't need pppoeconf at all, because there is no way we can know the details of PPTP tunneling used by every provider. -- ciao, | Marco | [8146 l'in59F1Sy6vA] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Tuesday 21 September 2004 00:12, Marco d'Itri wrote: On Sep 20, Eduard Bloch [EMAIL PROTECTED] wrote: Which loop? I do not know why your modem has an own IP, maybe it is a router and not a modem? Why does it give your local systems DHCP adresses? How are they related to whatever is connected there? Or maybe it is not a usual PPPoE modem but this other weird ip-route-over-fake-internal-network-with-dhcp-over-DSL system (*). He is using an alcatel speedtouch ethernet modem which encapsulates PPP in PPTP, to allow using PPPoA. The modem has 10.0.0.138 and the host should have another address in that range. This page describes a similar but different (there is no ppp0, but eth0) configuration: http://pptpclient.sourceforge.net/diagrams.phtml . If the modem DHCP server is really providing a gateway then I consider this a modem bug. Marco has pretty much summed it up. I fail to see though why the modem asking the host to consider the modem the default gateway is a bug. The routing table that is set up on the host once the modem has responded via DHCP correctly reflects the situation - the only way to the outside from the host at that time is via the modem. One can use the modem as a router (w/o starting pppoe at all) and reach the provider's WAN, although the traffic won't be routable outside. PS: (*) I am still looking for somebody to explain me how this technology works and can provide a reliable step-for-step howto to add support for it to pppoeconf. Or even patches. From time to time people asked me to add support for their DHCP DSL but for real support more is needed. It's not hard. Look at this example configuration: http://www.bytewise.at/knowhow/adsl-pptp/Konfiguration.html The only piece of info that you asked for that Marco hasn't addressed was the duplex LAN link - I was telling that the host is directly wired into the modem, i.e. there is no hub sitting between them, so the LAN connection MODEM - HOST is a full-duplex ethernet connection (as opposed to half-duplex). I think that to add to pppoeconf the support, the following needs to be done: 1) from the routing table, one must deduce that there is no direct route to the modem, hence the default route will be used 2) that default route has to be cloned into a direct route to the modem (better yet, make that a network route to the net specified by the network portion of the modem address) 3) after that, ppp has to be invoked with the replacedefaultroute option, and it will work I'll be happy to elaborate further if needed. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Sep 23, Vassilii Khachaturov [EMAIL PROTECTED] wrote: Marco has pretty much summed it up. I fail to see though why the modem asking the host to consider the modem the default gateway is a bug. The routing Because the modem is not a gateway and will not work as such? I think that to add to pppoeconf the support, the following needs to be done: No, really. This is too much complex. 1) from the routing table, one must deduce that there is no direct route to the modem, hence the default route will be used There is no need for a route, host and modem have IP addresses on the same subnet and can communicate. 2) that default route has to be cloned into a direct route to the modem (better yet, make that a network route to the net specified by the network portion of the modem address) There must be no default route pointing to the modem, because the modem is not able to work as a default gateway. 3) after that, ppp has to be invoked with the replacedefaultroute option, and it will work If there is no default route pppd will just work. If there is one there is probably a good reason to have it, so the default should be to leave it there. If the speedtouch DHCP server really provides a default route when it's configured for PPTP tunnels (something which I doubt and I think should be verified) *maybe* pppoeconf could check if the local address is 10.0.0.1 and 10.0.0.138 is the modem: if ping ... 10.0.0.138 \ wget --quiet --output-document=- http://10.0.0.138/welcome.htm \ | grep -q '^HEADTITLEADSL Index'; then echo yes fi Then it would have to check if the PPTP server is enabled. -- ciao, | Marco | [8117 sfOak.jbPaG1Y] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
As said to the previous bug reporters, it is simply not my job to load _kernel_ modules for some other package. It would just additional complexity while there are other places where it must be fixed. I agree that this bug looks very shameful for a fresh Debian release so it should be release critical. Especially when there is such a simple fix. I agree with you about the bug#263224 importance. I believe though that pppoeconfig might need to at least give a hint about the need to have the module preloaded - right now the behaviour during pppoeconfig is inconsistent with the behaviour after the fresh boot when just pppoe is being run. I agree that it is out of the scope of pppoe or pppd. But, ideally, pppoeconfing aiming to be a 1-2-3 setup wizard type of program, I think it should do everything including modconf-ing the module in forever if necessary, or at least offering this interactively as an option. PS: I won't clone 265183, there are already enough bug reports to the pppoe module problem. But what about the routing loop problem I had mentioned in the original 265183 report? It is something pretty confusing for a new user. Kind regards, Vassilii P.S. Sorry for a long silence - I was on vacation abroad, away from my home which is where all my ADSL hardware lives. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
#include hallo.h * Vassilii Khachaturov [Mon, Sep 20 2004, 11:51:31AM]: PS: I won't clone 265183, there are already enough bug reports to the pppoe module problem. But what about the routing loop problem I had mentioned in the original 265183 report? It is something pretty confusing for a new user. Which loop? I do not know why your modem has an own IP, maybe it is a router and not a modem? Why does it give your local systems DHCP adresses? How are they related to whatever is connected there? Or maybe it is not a usual PPPoE modem but this other weird ip-route-over-fake-internal-network-with-dhcp-over-DSL system (*). Or what t.f. is a LAN duplex link? Does not say anything to me. Maybe a phantasy name from your ISP? If yes, what is in the real world terms? Regards, Eduard. PS: (*) I am still looking for somebody to explain me how this technology works and can provide a reliable step-for-step howto to add support for it to pppoeconf. Or even patches. From time to time people asked me to add support for their DHCP DSL but for real support more is needed. -- So, your solution is to ask Should I break your system now or after the next reboot?. Debconf is not an alternative to fixing the problem. Such questions are still unacceptable bugs. -- asuffield in debian-devel about crazy linux-2.4 repackaging -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Sep 20, Eduard Bloch [EMAIL PROTECTED] wrote: Which loop? I do not know why your modem has an own IP, maybe it is a router and not a modem? Why does it give your local systems DHCP adresses? How are they related to whatever is connected there? Or maybe it is not a usual PPPoE modem but this other weird ip-route-over-fake-internal-network-with-dhcp-over-DSL system (*). He is using an alcatel speedtouch ethernet modem which encapsulates PPP in PPTP, to allow using PPPoA. The modem has 10.0.0.138 and the host should have another address in that range. This page describes a similar but different (there is no ppp0, but eth0) configuration: http://pptpclient.sourceforge.net/diagrams.phtml . If the modem DHCP server is really providing a gateway then I consider this a modem bug. PS: (*) I am still looking for somebody to explain me how this technology works and can provide a reliable step-for-step howto to add support for it to pppoeconf. Or even patches. From time to time people asked me to add support for their DHCP DSL but for real support more is needed. It's not hard. Look at this example configuration: http://www.bytewise.at/knowhow/adsl-pptp/Konfiguration.html -- ciao, | Marco | [8086 spM4h02ownjLg] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
severity 263224 serious reassign 262941 modutils severity 262941 serious merge 262941 263224 thanks #include hallo.h * Vassilii Khachaturov [Fri, Aug 13 2004, 08:50:58AM]: The thing that happens as a by-product of pppoeconf that enables the pppoe to work later on is the loading of the pppoe module. So to have pppoe working after reboot, `modprobe pppoe' is needed before `pon dsl-provider'. I think pppoeconf should have done something differently transparent to the user. FWIW, here's the /etc/ppp/peers/dsl-provider it had generated. See this also in connection with the routing quirk described in the original report (that had to be worked around with the assigning of a static address). Eduard: please feel free to fork #265183 to pppoeconf bugs (on the As said to the previous bug reporters, it is simply not my job to load _kernel_ modules for some other package. It would just additional complexity while there are other places where it must be fixed. I agree that this bug looks very shameful for a fresh Debian release so it should be release critical. Especially when there is such a simple fix. PS: I won't clone 265183, there are already enough bug reports to the pppoe module problem. Regards, Eduard. -- OpenBSD fails miserably in this respect, and makes for an example of how NOT to work with the community on security issues. Their approach is, roughly, we fixed this a while ago but didn't tell anyone, so you're vulnerable and we're not, ha-ha-ha. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
The thing that happens as a by-product of pppoeconf that enables the pppoe to work later on is the loading of the pppoe module. So to have pppoe working after reboot, `modprobe pppoe' is needed before `pon dsl-provider'. I think pppoeconf should have done something differently with the files it generated so that the module loading would have been transparent to the user. FWIW, here's the /etc/ppp/peers/dsl-provider it had generated. See this also in connection with the routing quirk described in the original report (that had to be worked around with the assigning of a static address). Eduard: please feel free to fork #265183 to pppoeconf bugs (on the routing and the module loading issues), or just ask me to do so. (However, I'm going on vacation and will be offline for the next week, though, so I'll be unable to open the new bugs right away). # Configuration file for PPP, using PPP over Ethernet # to connect to a DSL provider. # # See the manual page pppd(8) for information on all the options. ## # Section 1 # # Stuff to configure... # MUST CHANGE: Uncomment the following line, replacing the [EMAIL PROTECTED] # by the DSL user name given to your by your DSL provider. # (There should be a matching entry in /etc/ppp/pap-secrets with the password.) #user [EMAIL PROTECTED] # Use the pppoe program to send the ppp packets over the Ethernet link # This line should work fine if this computer is the only one accessing # the Internet through this DSL connection. This is the right line to use # for most people. #pty /usr/sbin/pppoe -I eth0 -T 80 -m 1452 # An even more conservative version of the previous line, if things # don't work using -m 1452... #pty /usr/sbin/pppoe -I eth0 -T 80 -m 1412 # If the computer connected to the Internet using pppoe is not being used # by other computers as a gateway to the Internet, you can try the following # line instead, for a small gain in speed: #pty /usr/sbin/pppoe -I eth0 -T 80 # The following two options should work fine for most DSL users. # Assumes that your IP address is allocated dynamically # by your DSL provider... noipdefault # Try to get the name server addresses from the ISP. usepeerdns # Use this connection as the default route. # Comment out if you already have the correct default route installed. defaultroute ## # Section 2 # # Uncomment if your DSL provider charges by minute connected # and you want to use demand-dialing. # # Disconnect after 300 seconds (5 minutes) of idle time. #demand #idle 300 ## # Section 3 # # You shouldn't need to change these options... hide-password lcp-echo-interval 20 lcp-echo-failure 3 # Override any connect script that may have been set in /etc/ppp/options. connect /bin/true noauth persist mtu 1492 # RFC 2516, paragraph 7 mandates that the following options MUST NOT be # requested and MUST be rejected if requested by the peer: # Address-and-Control-Field-Compression (ACFC) noaccomp # Asynchronous-Control-Character-Map (ACCM) default-asyncmap plugin rp-pppoe.so eth0 user [CENSORED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
