On May 16, Eddy Petri??or <eddy.petrisor@gmail.com> wrote: > >>If I am going to do that on the connection from my provider, I will > >>have my contract termitated in a second because I am not allowed to > >>use other IPs in their network than the ones given by thier servers, > >>and believe me, there is NO configuration given for the ethernet card. > >You are supposed to use a private IP address then. > No, I have told you, I AM NOT ALLOWED TO CONFIGURE THAT ETHERNET > INTERFACE WITH ANY IP. The ppp interface is the only one which is > allowed to be up with an IP which must be given by their server. > > I had problems because of this (not exagerating) from day one, when my > laptop was put as a router for the internal network and on the used > interface it had on private class IP. One guy from the techincal body > of the ISP has visited me in the intent to disconnect me _just_ > because I had an IP (an IP) other than the one provided by them. I do not believe this. Your ISP CANNOT KNOW about IP addresses assigned to your internal interfaces, unless your configuration is broken in some way (e.g. you forwarded packets originated from internal addrsses without NAT'in them). > It is not *necessary* to have an IP to search for the concentrator, > but it is *sufficient* to have the possibility to probe for > concentrators. > So, AFAICT, if probing must be done for eth0 then thi should be done > according to the following algorithm: > - is eth0 up? if yes, probe for concentrators > - if eth0 is down, _just_ up the interface (no IP) then probe > Any objection to this approach? The case of "ethernet interface needs to be up without an IP address" must be handled by the code which currently configures ethernet interfaces (if you can persuade the maintainers). This means that when ppp-udeb will start probing the available interfaces they will already be up (with or without an IP address). > ppp-udeb's postinst must allow running it an infinite number of times, > but the result should be the same. Curently this is not true because > for each run of the postinst, another pppoe connection is configured, > although it should not. Maybe if a ppp interface exists then it should not try to configure others. > The problem is that this issue must be solved and one will have to > know (for multiple netcard system) on which ethX a pppY was > configured, so that once the pppY is down, _if_ the associated ethX > was upped by ppp-udeb's postinst previousely, it should be downed if > no concentrator was found on it. ppp-udeb does not support configuring multiple PPP interfaces, and I see no reason why it should. If for some reason you need to know the ethernet interface used by the PPPoE connection you can find it in the /etc/ppp/peers/ config file. (Beware: the name of ethernet interfaces may not match eth[0-9]...) > So ppp-udeb should depend on another udeb which should provide a > PPP-config-saver udeb which should take care of this copying after the > target is installed. No, ppp-udeb should install a script to copy the configuration on the target. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature