Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
On Sat, Dec 08, 2001 at 11:44:47PM +0100, Joerg Wunsch wrote: As Ruslan Ermilov wrote: You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. Only if you have INET address configured on an interface. That's the purpose of an sppp interface. You can't do anything with it unless an INET address has been configured to it. (In the case of an automatic dialer -- which is what many ISDN users are using -- you need the IP traffic generated by normal routing in order to trigger the ISDN dialout.) ifconfig isp0 up route add default -iface isp0 Won't this work, without prior configuring any INET addresses? This will definitely trigger a traffic through the interface. Why not just bring the interface up first, then negotiate an address, then add it to interface? Because it'll become a chicken-and-egg problem: the interface would never start negotiating PPP in that case. Still don't get it, sorry. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
On Fri, Dec 07, 2001 at 09:01:12PM +0100, Joerg Wunsch wrote: As Ruslan Ermilov wrote: phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. OK, but is it really necessary? It's much simpler to add routes over P2P interfaces using the interface name ... You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. Only if you have INET address configured on an interface. (Actually, it even tries to enter it twice, so you get a meaningless Address already exists. message when bringing a p2p interface up with ifconfig.) The politically correct solution to negotiate the remote PPP address would have been to change the routing table entry after negotiating the address, of course. However, this seemed to be too much hassle for the smallsimple intent of sppp(4), in particular considering that the only added value compared to the 0.0.0.1 hack would be that you can reach the IP address of your peer directly. Why not just bring the interface up first, then negotiate an address, then add it to interface? [Please DO NOT exclude my personal address when replying -- I didn't ask for it (as many do) through the Mail-Followup-To: header.] Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
As Ruslan Ermilov wrote: You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. Only if you have INET address configured on an interface. That's the purpose of an sppp interface. You can't do anything with it unless an INET address has been configured to it. (In the case of an automatic dialer -- which is what many ISDN users are using -- you need the IP traffic generated by normal routing in order to trigger the ISDN dialout.) Why not just bring the interface up first, then negotiate an address, then add it to interface? Because it'll become a chicken-and-egg problem: the interface would never start negotiating PPP in that case. There are other PPP implementations available for people who want a full-blown one; sppp is meant to be the simplest (and smallest) PPP implementation that is useful for synchronous data carriers. [Please DO NOT exclude my personal address when replying -- I didn't ask for it (as many do) through the Mail-Followup-To: header.] You got it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
On 7 Dez, Ruslan Ermilov wrote: The magical destination address is 0.0.0.1. It is used as a `placeholder' address for the remote side, so you can add a route to it. Should probably be extended to 0.0.0.*, so you can add more than one interface that way. I thought this already happened... [...] OK, but is it really necessary? It's much simpler to add routes over P2P interfaces using the interface name rather than the ``other end's IP address'': route add default -iface tun0 'route add default -iface ispX' in this case (that's the way I use it, btw). Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
As Ruslan Ermilov wrote: phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. OK, but is it really necessary? It's much simpler to add routes over P2P interfaces using the interface name ... You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. (Actually, it even tries to enter it twice, so you get a meaningless Address already exists. message when bringing a p2p interface up with ifconfig.) The politically correct solution to negotiate the remote PPP address would have been to change the routing table entry after negotiating the address, of course. However, this seemed to be too much hassle for the smallsimple intent of sppp(4), in particular considering that the only added value compared to the 0.0.0.1 hack would be that you can reach the IP address of your peer directly. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rev 1.61 of /sys/netinet/in.c breaks ISDN
Hi, with rev 1.61 of in.c I4B directly hangs up after dialing out. At the moment I run a current kernel as of yesterday with a netinet directory as of today except for in.c (which is at rev 1.60 here) and everything works fine. Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
Hi, with rev 1.61 of in.c I4B directly hangs up after dialing out. At the moment I run a current kernel as of yesterday with a netinet directory as of today except for in.c (which is at rev 1.60 here) and everything works fine. Hi, Can you give me more details about the failure - error messages, your configuration, what you're using (sppp?), that sort of stuff ? The change makes the kernel fail attempts to add POINTOPOINT interfaces with conflicting IPv4 destination addresses. Are you in a situation where you're expecting this to be possible ? If so, can you explain more about why it's required ? Cheers. Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 -- 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: rev 1.61 of /sys/netinet/in.c breaks ISDN
On Thu, Dec 06, 2001 at 01:52:49PM +, Brian Somers wrote: Hi, with rev 1.61 of in.c I4B directly hangs up after dialing out. At the moment I run a current kernel as of yesterday with a netinet directory as of today except for in.c (which is at rev 1.60 here) and everything works fine. Hi, Can you give me more details about the failure - error messages, your configuration, what you're using (sppp?), that sort of stuff ? The change makes the kernel fail attempts to add POINTOPOINT interfaces with conflicting IPv4 destination addresses. Are you in a situation where you're expecting this to be possible ? If so, can you explain more about why it's required ? ISTR that I4B uses some special magical destination address for some purpose (0.0.0.0 or something). Sorry, don't recall the details. But I bet Alexander knows, as we already hit this once, with my routing changes, some time ago... Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
On 6 Dez, Ruslan Ermilov wrote:
with rev 1.61 of in.c I4B directly hangs up after dialing out. At the
moment I run a current kernel as of yesterday with a netinet directory
as of today except for in.c (which is at rev 1.60 here) and everything
works fine.
Can you give me more details about the failure - error messages, your
configuration, what you're using (sppp?), that sort of stuff ?
- isppp
- No error messages, just normal call clearing, but immediatly after
dialing out.
---snip---
(1) root@ttyp1 # /etc/start_if.isp1
ifconfig isp1 link1 0.0.0.0 0.0.0.1 netmask 255.255.0.0
ispppcontrol isp1 $(cat /etc/isdn/connect-CBC.parameters) enable-vj
ifconfig isp1 down
---snip---
Do you need more? What else?
The change makes the kernel fail attempts to add POINTOPOINT
interfaces with conflicting IPv4 destination addresses.
Are you in a situation where you're expecting this to be possible ?
Yes.
If so, can you explain more about why it's required ?
ISTR that I4B uses some special magical destination address for some
purpose (0.0.0.0 or something). Sorry, don't recall the details.
But I bet Alexander knows, as we already hit this once, with my
routing changes, some time ago...
Online:
---snip---
(4) netchild@ttyp1 % ifconfig isp1
isp1: flags=a051UP,POINTOPOINT,RUNNING,LINK1,MULTICAST mtu 1500
inet 213.6.44.137 -- 0.0.0.1 netmask 0x
ether 00:00:00:00:00:00
---snip---
While offline, the interface has a local address of 0.0.0.0. It changes
to the official IP after getting it via pap, and it changes back to
0.0.0.0 after a hang up.
Online:
---snip---
(6) netchild@ttyp1 % netstat -rn
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default0:0:0:0:0:0USc340 isp1
0.0.0.1213.6.44.137 UH 00 isp1
[...]
---snip---
For more internals you better ask someone with in deep knowledge, e.g.
{hm,isdn,joerg}@freebsd.org.
Bye,
Alexander.
--
Intel: where Quality is job number 0.9998782345!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
Ruslan Ermilov [EMAIL PROTECTED] wrote: ISTR that I4B uses some special magical destination address for some purpose (0.0.0.0 or something). The magical destination address is 0.0.0.1. It is used as a `placeholder' address for the remote side, so you can add a route to it. Should probably be extended to 0.0.0.*, so you can add more than one interface that way. (The actual PPP negotiation for the remote side is simply told to acceppt any suggested address, but this address is then ignored, and the local end still uses 0.0.0.1 for routing purposes. This is a big hack, but the only feature you lose is to directly access your remote router. Any other packets have a destination address different from the remote router anyway.) phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
On Thu, Dec 06, 2001 at 09:23:32PM +0100, Joerg Wunsch wrote: Ruslan Ermilov [EMAIL PROTECTED] wrote: ISTR that I4B uses some special magical destination address for some purpose (0.0.0.0 or something). The magical destination address is 0.0.0.1. It is used as a `placeholder' address for the remote side, so you can add a route to it. Should probably be extended to 0.0.0.*, so you can add more than one interface that way. (The actual PPP negotiation for the remote side is simply told to acceppt any suggested address, but this address is then ignored, and the local end still uses 0.0.0.1 for routing purposes. This is a big hack, but the only feature you lose is to directly access your remote router. Any other packets have a destination address different from the remote router anyway.) phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. OK, but is it really necessary? It's much simpler to add routes over P2P interfaces using the interface name rather than the ``other end's IP address'': route add default -iface tun0 Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
