Hello all.
I just rebuild current today, and now I can not use aliases on my
network interface anymore.
FreeBSD desk.server.testdomain.nl 11.0-CURRENT FreeBSD 11.0-CURRENT #6
r300138: Wed May 18 14:30:38 CEST 2016
r...@desk.server.testdomain.nl:/usr/obj/usr/src/sys/KRNL amd64
my /etc
On 2014-09-10 10:05, Kurt Lidl wrote:
> On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote:
>> On 04.09.2014 18:16, Kurt Lidl wrote:
>>> Greetings all:
>>>
>>> I have a host that recently was upgraded from FreeBSD 9.1
>>> to FreeBSD 9.3. After the upgrad
On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote:
On 04.09.2014 18:16, Kurt Lidl wrote:
Greetings all:
I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3. After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:
The section of my
On 04.09.2014 18:16, Kurt Lidl wrote:
> Greetings all:
>
> I have a host that recently was upgraded from FreeBSD 9.1
> to FreeBSD 9.3. After the upgrade, the IPv6 aliases that
> I was setting on vlan'd interfaces, no longer get set:
>
> The section of my /etc/rc.co
Greetings all:
I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3. After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:
The section of my /etc/rc.conf, which worked under 9.1:
# inside network (gigabit connected)
ifconfig
> <201306200229.r5k2tnfr085...@svn.freebsd.org>:
>
[...]
What is the current, non deprecated way, to configure IP addresses in
rc.conf? Let's say for a dual stack, multi IP box I need to set:
10.0.0.66/28 and 10.0.0.67-78 as aliases and
fdda:5cc1:23:4::1/48 and fdda:5cc1:23:4::
Michael Grimm wrote
in <4c07217dc9200841dfd065a6d5284...@mx1.enfer-du-nord.net>:
tr> On 2013-07-12 6:56, Hiroki Sato wrote:
tr> > Kevin Oberman wrote
tr> > in :
tr> > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
tr> > rk>
tr> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Gr
On 2013-07-12 6:56, Hiroki Sato wrote:
Kevin Oberman wrote
in
:
rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
rk>
rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
rk> > trash...@odo.in-berlin.de> wrote:
rk> >
rk> > Will that patch make it into 9.2? If I am not mistaken,
On Thu, Jul 11, 2013 at 9:56 PM, Hiroki Sato wrote:
> Kevin Oberman wrote
> in :
>
> rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
> rk>
> rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
> rk> > trash...@odo.in-berlin.de> wrote:
> rk> >
> rk> > Will that patch make it int
Kevin Oberman wrote
in :
rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
rk>
rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
rk> > trash...@odo.in-berlin.de> wrote:
rk> >
rk> > Will that patch make it into 9.2? If I am not mistaken, that patch isn't
rk> >> in stable yet.
rk>
W dniu 2013-07-10 17:52, Kevin Oberman pisze:
> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
>
>> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
>> trash...@odo.in-berlin.de> wrote:
>>
>> Will that patch make it into 9.2? If I am not mistaken, that patch isn't
>>> in stable yet.
>>>
On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote:
> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
> trash...@odo.in-berlin.de> wrote:
>
> Will that patch make it into 9.2? If I am not mistaken, that patch isn't
>> in stable yet.
>>
>
> I would also like to see this patch hit 9.x sooner t
On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm
wrote:
Will that patch make it into 9.2? If I am not mistaken, that patch isn't
in stable yet.
I would also like to see this patch hit 9.x sooner than later. It's so
painful when someone forgets to fix the alias numbering on servers with
Hi --
[Upcoming code freeze in stable]
On 2013-04-13 22:15, Michael Grimm wrote:
On 13.04.2013, at 14:29, Kimmo Paasiala wrote:
[great deal of simplification by ipv6_addrs_IF]
Sorry to resurrect this thread but since nothing has happened in about
three months I have to ask: What can I do
W dniu 2013-04-13 22:15, Michael Grimm pisze:
> On 13.04.2013, at 14:29, Kimmo Paasiala wrote:
>
> [great deal of simplification by ipv6_addrs_IF]
>
>> Sorry to resurrect this thread but since nothing has happened in about
>> three months I have to ask: What can I do to have this commited to
>>
I would also like to see this committed. I started on my own patch about
4 months ago but got sidetracked. This would be very, very valuable to
the sysadmins at my workplace.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
Hi --
On 13.04.2013, at 14:29, Kimmo Paasiala wrote:
[great deal of simplification by ipv6_addrs_IF]
> Sorry to resurrect this thread but since nothing has happened in about
> three months I have to ask: What can I do to have this commited to
> HEAD?
+1
Nowadays -where IPv6 becomes more and m
lied at top level
>>> of sources (/usr/src typically). It now does the deconfiguration in
>>> reverse order of the configuration, meaning the aliases configured
>>> with ipv6_addrs_IF are removed before the ones configured with
>>> ifconfig_IF_aliasN="ine
deconfiguration in
>> reverse order of the configuration, meaning the aliases configured
>> with ipv6_addrs_IF are removed before the ones configured with
>> ifconfig_IF_aliasN="inet6 ...".
>
> Adapted for FreeBSD 8.2, works fine:
>
> --- network.subr.orig 201
2012/12/26 Kimmo Paasiala :
> I've revised the patch again and updated it at gihub,
> https://gist.github.com/4362018. It can now be applied at top level
> of sources (/usr/src typically). It now does the deconfiguration in
> reverse order of the configuration, meaning the a
On 26-12-2012 10:33, Kimmo Paasiala wrote:
> Now, is there any interest in seeing this feature as part of future
> versions of FreeBSD? Could it be incorporated to HEAD and then MFC'ed
> to 9-STABLE if it turns out it's seen as a useful feature?
Yes please! I've been waiting for this for a while,
uot;YES"
>> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
>> inet6 2001:6a0:1cb::1 prefixlen 128
>>
>> Of course using "inet6 auto_linklocal" instead of "up" seems a better
>> way to do it, thank you for this tip.
>>
On Sat, Dec 22, 2012 at 7:49 PM, Łukasz Wąsikowski
wrote:
> W dniu 2012-12-22 18:14, Ben Morrow pisze:
>> Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= :
>>> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>>>
Yeah, this is problem in network.subr. An interface is not recognized
as IPv6
On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski
wrote:
> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>
It looks like the reason for the difference to ipv4_addrs_IF is that
the "alias" parameter for ifconfig(8) operates differently for IPv6
addresses, the first address of an in
W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>>> It looks like the reason for the difference to ipv4_addrs_IF is that
>>> the "alias" parameter for ifconfig(8) operates differently for IPv6
>>> addresses, the first address of an interface can't be added with
>>> "alias", for IPv4 it does not car
r
>>>>>
>>>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>>>> this message.
>>>>>
>>>>> Again it's against a very recent 9-STABLE, I still haven't found time
>>>>> to see
s you can use hexdigit and hexprint from
>>>>> network.subr.
>>>>>
>>>>> --
>>>>> Jilles Tjoelker
>>>>
>>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>>> this message.
>>
gt; Jilles Tjoelker
>>>
>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>> this message.
>>>
>>> Again it's against a very recent 9-STABLE, I still haven't found time
>>> to see if it applies to CURRENT.
&g
>> Again it's against a very recent 9-STABLE, I still haven't found time
>> to see if it applies to CURRENT.
>>
>> It does allow you to do crazy stuff like
>>
>> ipv6_addrs_re0="2001:db8::::1-/64"
>>
>> However I did
work.subr.
>>
>> --
>> Jilles Tjoelker
>
> Thanks, I've rewitten my patch to support ranges. It is attached in
> this message.
>
> Again it's against a very recent 9-STABLE, I still haven't found time
> to see if it applies to CURRENT.
>
> It
ttached in
this message.
Again it's against a very recent 9-STABLE, I still haven't found time
to see if it applies to CURRENT.
It does allow you to do crazy stuff like
ipv6_addrs_re0="2001:db8::::1-/64"
However I didn't find anything to limit the number of aliase
On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
> A question related to this for those who have been doing work on the
> rc(8) scripts. Can I assume that /usr/bin is available when
> network.subr functions are used? Doing calculations on hexadecimal
> numbers is going to be very awk
On Wed, Dec 19, 2012 at 11:47 PM, Kimmo Paasiala wrote:
> On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
> wrote:
>> W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:
>>
>>>> I wrote a small patch for /etc/network.subr to add support for
>>>> ipv6_a
On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
wrote:
> W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:
>
>>> I wrote a small patch for /etc/network.subr to add support for
>>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
>>> ipv4_addrs_IF
W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:
>> I wrote a small patch for /etc/network.subr to add support for
>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
>> aliases can be wri
On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala wrote:
> Hello,
>
> I wrote a small patch for /etc/network.subr to add support for
> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
> aliases c
Hello,
I wrote a small patch for /etc/network.subr to add support for
ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
aliases can be written like:
ipv6_addrs_re0="2001:db8::::1/64 2001:db8::22
On Tue, 5 Mar 2002, Adam Webb wrote:
> Is there a known bug or particular reason I can't add network aliases in
> -current?
> --
> Adam Webb
None that I know of, although there does seem to be at least one bug
relating to removable interfaces and dhclient. It might be usefu
Is there a known bug or particular reason I can't add network aliases in
-current?
--
Adam Webb
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marcel Moolenaar wrote:
>
> Alexey Zelkin wrote:
> >
> > I am trying to realize "is requested locale physicaly present on this system"
> > or it's just an alias.
>
> Can you not revert the test: if the locale is present in the alias file,
> then it obviously is an alias; otherwise it should be p
Alexey Zelkin wrote:
>
> I am trying to realize "is requested locale physicaly present on this system"
> or it's just an alias.
Can you not revert the test: if the locale is present in the alias file,
then it obviously is an alias; otherwise it should be present on the
system?
Just a quick thou
hi,
On Tue, Aug 29, 2000 at 05:19:56PM +0100, Konstantin Chuguev wrote:
> Perhaps you should check presence of any of the following files in a locale
> directory:
> LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME,
LC_NUMERIC ? :)
> and proceed if any of them has been found...
Sure. I
On Tue, Aug 29, 2000 at 06:24:49PM +0300, Alexey Zelkin wrote:
> > You need to check LC_* existence corresponding to setlocale() request
> > made.
>
> What to check if LC_ALL request is given ?
Just repeat the same procedure as regular algorithm gives for LC_ALL
processing.
--
Andrey A. Cherno
Alexey Zelkin wrote:
> > > > You need to check LC_* existence corresponding to setlocale() request
> > > > made.
> > >
> > > What to check if LC_ALL request is given ?
>
> > LC_ALL overrides all other LC_* variables. If it is set, there is no need to
> > check anything else.
>
> > Then you should
hi,
On Tue, Aug 29, 2000 at 04:35:04PM +0100, Konstantin Chuguev wrote:
> > > You need to check LC_* existence corresponding to setlocale() request
> > > made.
> >
> > What to check if LC_ALL request is given ?
> LC_ALL overrides all other LC_* variables. If it is set, there is no need to
> ch
Alexey Zelkin wrote:
> > You need to check LC_* existence corresponding to setlocale() request
> > made.
>
> What to check if LC_ALL request is given ?
>
LC_ALL overrides all other LC_* variables. If it is set, there is no need to
check anything else.
Then you should check all other LC_*, and th
hi,
On Tue, Aug 29, 2000 at 07:00:47PM +0400, Andrey A. Chernov wrote:
> Why you always check LC_CTYPE existance only? It may not exist but other
> locale parts, f.e. LC_TIME are still valid. It is not required to have
> LC_CTYPE for locale.
I just randomly selected one of files which is exists
On Tue, Aug 29, 2000 at 05:26:51PM +0300, Alexey Zelkin wrote:
> I have updated patchset. libc/nls part is comming soon.
Why you always check LC_CTYPE existance only? It may not exist but other
locale parts, f.e. LC_TIME are still valid. It is not required to have
LC_CTYPE for locale.
You need t
hi,
I have updated patchset. libc/nls part is comming soon.
* Synchronize behaviours for LOCALE_ALIASES_PATH and LOCALE_PATH handling.
If attempt to open customized locale.aliases (declared by env variable
LOCALE_ALIASES_PATH) is failed -- don't try to use default system
locale.aliases in
On Tue, Aug 29, 2000 at 03:19:00PM +0400, Andrey A. Chernov wrote:
> By quick looking I found this:
>
> 1) strtok() should not be used in libraries, use strsep() instead.
>
> 2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check
> required.
>
> 3) The same functionality shou
On Tue, Aug 29, 2000 at 02:01:02PM +0300, Alexey Zelkin wrote:
> please review and comment
By quick looking I found this:
1) strtok() should not be used in libraries, use strsep() instead.
2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check
required.
3) The same functiona
hi,
please review and comment
--
This is set of patches for libc which allow user to use locale
aliases. Currently it's only possible to use locale aliases
by creating one more symbolic link in /usr/share/locale, i.e.
if I want to have locale named "ru" I have to:
l
52 matches
Mail list logo
