Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. Say for example that you do ``set ifaddr A B'' and then ``telnet X'' when the link is down. telnet does a connect(X), resulting in a local binding to address A with a destination address of X. ppp brings the link up and negotiates C -- D, but keeps A -- B on the interface. The initial ``telnet X'' packet (A -- X) can now be transmitted, but ppp's alias address is now C. It NATs the packet to C -- X and sends it out. X gets it and sends a packet back to C. Your ISP routes to C correctly and your ppp process unNATs it back to A. Thus your ``first connection'' works when in reality it should not. If you ``iface clear'' on linkup, ppp doesn't NAT the A -- X packet and X replies to A -- which your ISP (of course) can't route. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. That may be because most connections consist of a DNS lookup followed by the connect... but I'm not sure about that. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. It should work ok now. Adding an interface address only needs to special-case things when either the source or destination addresses conflict with ones that are already assigned to the interface. [.] -- Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. [...] When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Oh, I just discovered that cvsup didn't update my tree for 3 days. Everything works ok again - even the things which weren't design to work at all. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
