Searched hist:40664 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-10.1-release/usr.sbin/ppp/ | ||
| H A D | iface.c | diff 40664 Mon Oct 26 17:07:36 MST 1998 brian Fix the interface alias code. Previously, I was expecting something like tun0: flags=blah 10.0.0.1 -> 10.0.0.100 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 10.0.0.100 to DTRT, despite the SIOCAIFADDR for each new alias returning -1 & EEXIST while adding the alias anyway. In real life, once we have the second alias with the same destination, nothing will route any more ! Also, because I was ignoring EEXIST, the dynamic IP assignment code was assigning duplicate addresses ('cos it was being lied to by iface_inAdd()). Now we have tun0: flags=blah 10.0.0.1 -> 255.255.255.255 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 255.255.255.255 This works - stuff bound to 10.1 & 10.3 will be considered alive by the kernel, and when they route back to the tun device, the packets get aliased to 10.2 and go out to 10.100 (as with the original plan). We still see the EEXIST in SIOCAIFADDR, but ignore it when our destination is 255.255.255.255, assuming that the alias *was* actually added. Additionally, ``iface add'' may now optionally be given only the interface address. The mask & destination default to 255.255.255.255. |
| H A D | command.c | diff 40664 Mon Oct 26 17:07:36 MST 1998 brian Fix the interface alias code. Previously, I was expecting something like tun0: flags=blah 10.0.0.1 -> 10.0.0.100 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 10.0.0.100 to DTRT, despite the SIOCAIFADDR for each new alias returning -1 & EEXIST while adding the alias anyway. In real life, once we have the second alias with the same destination, nothing will route any more ! Also, because I was ignoring EEXIST, the dynamic IP assignment code was assigning duplicate addresses ('cos it was being lied to by iface_inAdd()). Now we have tun0: flags=blah 10.0.0.1 -> 255.255.255.255 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 255.255.255.255 This works - stuff bound to 10.1 & 10.3 will be considered alive by the kernel, and when they route back to the tun device, the packets get aliased to 10.2 and go out to 10.100 (as with the original plan). We still see the EEXIST in SIOCAIFADDR, but ignore it when our destination is 255.255.255.255, assuming that the alias *was* actually added. Additionally, ``iface add'' may now optionally be given only the interface address. The mask & destination default to 255.255.255.255. |
| H A D | ppp.8 | diff 40664 Mon Oct 26 17:07:36 MST 1998 brian Fix the interface alias code. Previously, I was expecting something like tun0: flags=blah 10.0.0.1 -> 10.0.0.100 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 10.0.0.100 to DTRT, despite the SIOCAIFADDR for each new alias returning -1 & EEXIST while adding the alias anyway. In real life, once we have the second alias with the same destination, nothing will route any more ! Also, because I was ignoring EEXIST, the dynamic IP assignment code was assigning duplicate addresses ('cos it was being lied to by iface_inAdd()). Now we have tun0: flags=blah 10.0.0.1 -> 255.255.255.255 10.0.0.2 -> 10.0.0.100 10.0.0.3 -> 255.255.255.255 This works - stuff bound to 10.1 & 10.3 will be considered alive by the kernel, and when they route back to the tun device, the packets get aliased to 10.2 and go out to 10.100 (as with the original plan). We still see the EEXIST in SIOCAIFADDR, but ignore it when our destination is 255.255.255.255, assuming that the alias *was* actually added. Additionally, ``iface add'' may now optionally be given only the interface address. The mask & destination default to 255.255.255.255. |
Completed in 130 milliseconds