if (event == NETDEV_UP) {
>
> ---
Many thanks. Now if only IPv4 would be fixed in similar fashion as well.
Also, this reminds me related issue - "ADDRCONF(NETDEV_UP): : link
is not ready" and "ADDRCONF(NETDEV_CHANGE): : link becomes ready"
messages. Whil
ager) you don't have any addresses on interface
at this point therefore /proc/sys/net/ipv[46]/conf// are NOT
created. That's the point - you can't configure anything before the first
"carrier up" event - ie. cable is plugged on.
regards,
--
Hasso Tepper
Elion Enterp
interface events via netlink. I can't do it in any
way before.
regards,
--
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
IP & Data Networking Expert
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
behave now. I can't continue using crappy workarounds.
regards,
--
Hasso Tepper
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ernative which would work with both
2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)?
Accessing `/proc/sys' directly isn't such alternative as it doesn't work
with capabilities.
regards,
--
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
Data Communication Net
ernative which would work with both
2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)?
Accessing `/proc/sys' directly isn't such alternative as it doesn't work
with capabilities.
regards,
--
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
Data Communication Net
ernative which would work with both
2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)?
Accessing `/proc/sys' directly isn't such alternative as it doesn't work
with capabilities.
regards,
--
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
Data Communication Net
Herbert Xu wrote:
> Hasso Tepper <[EMAIL PROTECTED]> wrote:
> >> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> >> reenable it on the interfaces that you actually want.
> >
> > You can't do that either (ie. reenable) in initscripts
Herbert Xu wrote:
> Peter Bieringer <[EMAIL PROTECTED]> wrote:
> > BTW: this is also the reason why autoconf or accept_ra cannot be
> > disabled by e.g. initscripts *per* interface before bringing one up.
>
> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> reenable it on the in
rface =>
no /proc/sys/net/ipv6/conf/. Bootup scripts (procps.sh reading
sysctl.conf existing in most of distributions AFAIK) can't set/get
anything in /proc/sys/net/ipv6/conf/ because it doesn't exist.
How userspace should behave now? Mandating daemon which listens interface
events
Thomas Graf wrote:
> However, I changed IPv4 addresses to provide the pid and support
> NLM_F_ECHO and the same will follow for IPv6 address notifications
> which will mean that quagga sees a different set of IPv4 address
> notifications.
Can you explain what exactly is changed?
jamal wrote:
> CCing Hasso Tepper <[EMAIL PROTECTED]>
>
> Hasso, please comment on this thread (apologies, I forgot the other
> guy's name; so if you can CC all the necessary suspects to comment, it
> would help).
I fully agree with Herbert Xu:
> The pid field in
Hasso Tepper:
> I can think of workarounds for most of problems (although it breaks a
> hell lot of software here), but how I suppose to configure ipv6
> settings for interfaces which have to obtain global ipv6 address via
> autoconf so that it will work even if cable is not plugg
Hasso Tepper wrote:
> After upgrade to 2.6.16.20 from 2.6.11 I discovered that no dynamic
> interfaces (vlans, tunnels) appear under /proc/sys/net/ipv4/conf/.
> /proc/sys/net/ipv6/conf/ is OK.
OK, realised out that it's feature. Entries in /proc/sys/net/*/conf/ are
not create
After upgrade to 2.6.16.20 from 2.6.11 I discovered that no dynamic
interfaces (vlans, tunnels) appear under /proc/sys/net/ipv4/conf/.
/proc/sys/net/ipv6/conf/ is OK.
Bug? Or feature?
with my best wishes,
--
Hasso Tepper
-
To unsubscribe from this list: send the line "unsubscribe netde
: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Kernel configuration and dmesg from problematic machine attached.
regards,
--
Hasso Tepper
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16
# Mon Mar 20 09:
s they want to listen in various stages of work.
--
Hasso Tepper
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t this pid and
negative numbers stuff is valid only if application doesn't set nl_pid.
It's completely legal for application to do that before calling bind()
and if there's no conflict (no already open netlink socket with this
nl_pid), everything is OK.
--
Hasso Tepper
-
To unsubsc
jamal wrote:
> So the question is what would be the "address"/nl_pid of something
> issued by an ioctl (refer to my earlier email to Alexey).
It's the kernel who creates this message and puts it to the netlink
domain, so I'd say 0.
--
Hasso Tepper
-
To unsubscrib
jamal wrote:
> On Wed, 2006-08-02 at 22:50 +0200, Hasso Tepper wrote:
> > jamal wrote:
> > > Ok, thanks for the reminder Hasso.
> > > so essentially at the moment the pid that will show up (if
> > > quagga added the v6 route) will be that of quagga, correct?
o every netlink socket that the process subsequently
creates."
Once again link to the archive to the message I posted with new netlink.7
no one bother to comment yet ;).
http://www.mail-archive.com/netdev%40vger.kernel.org/msg06166.html
--
Hasso Tepper
-
To unsubscribe from this list: send
Hasso Tepper wrote:
> No, that was different issue and isn't related with issue Alexey
> poiting to. The issue I complained and you fixed it, Jamal, was that
> IPv6 related netlink messages had always pid 0 even if they were issued
> by application.
It was unclear, so I have
the app that made
> the kernel change has its pid appear on the resulting netlink message
> and at others it was 0 or the large (negative) number when you had
> more than 1 socket within the same process.
>
> CCing Hasso Tepper and more details of the original fix are
> here:
> ht
After seeing yet another project which had pointers in the code comments
to the false statements in the netlink.7 man page, I decided to spend
some time on improving man page.
Comments and improvements are welcome especially regarding TODO's, XXX's
and FIME's in the page.
-
pect that it wouldn't use default pointed to
wired network _and_ 192.168.1.0/24 pointed to it any more. Default
pointed to the wireless is there, wireless link is known to be usable
(IFF_RUNNING) and 192.168.1.0/24 is reachable via wireless as well.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN a
re if !IFF_RUNNING. So, from point of view of
routing calculations all works already. The only problem is kernel itself
- routing daemon may add really usable route to the network behind
directly connected interface, but it will not be used by kernel, because
there is connected route in the
d circuit, link may stay down. What
RFC3883 does, is that it defines mechanism to detect if neighbour is
really still alive if link will be brought up and used for traffic.
That's all.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
-
To unsubscribe from this list: send the line "
to exchange routing information.
I don't see any concept of "OSPF's own link state detection" here.
regards,
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
>
> Recently (not yet published), I went though ip(7), tcp(7), udp(7)
> etc, and changed SOL_IP to IPPROTO_IP, SOL_TCP to IPPROTO_TCP,
> etc, on the basis that
>
> -- the IPPROTO_* constants are what appear in POSIX, and
That's good enough reason, IMHO.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
with 2.4 kernel".
Without this patch it's not possible to support IPv6 routing in Quagga
without race conditions. Users (including myself) are using this patch in
production for some months and haven't noticed any issues with it.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administra
ds comment to the NOTES. Also comment
about SOL_IP portability added to the NOTES and duplicate IP_PKTINFO
removed in the VERSIONS section.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
--- ip.7.orig 2005-07-18 19:02:32.0 +0300
+++ ip.7 2005-08-19 11:20:23.0 +0300
) I get message with type IP_TTL (2). What makes it more complicated
is that in FreeBSD (AFAIK othere OSes don't have it) control message has
type IP_RECVTTL.
Bug in man page? Or in kernel?
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
-
To unsubscribe from this list: send the
32 matches
Mail list logo
