Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 17 apr 2022 om 15:28 schreef Bob Friesenhahn 
bfrie...@simple.dallas.tx.us:

> This sounds reasonable except for the "chicken and the egg" issue.
> If software is necessary in order for the system to receive updates or
> perform its function, then it is useful that it be installed.  I am
> not sure if that applies here, but it is always useful to make sure.

Most likely for historical reasons that is exactly why "network/routing"
which in my opinion should be called "network/dynamic-routing" is in the 
minimal group.

As an experiment I can launch a PR (pull request) which simply removes 
network/routing from the minimal group, and see what happens.

But you are right, the "chicken and egg issue" is that if routed is NOT enabled 
during installation or immediately after install, then there may be some setups 
that do not get their routing tables dynamically and hence they are not able to 
route to pkg.openindiana.org and "pkg install network/routing" or "pkg install 
network/dynamic-routing" will not work, because the pkg install will be broken 
due to in.routed not running or not being enabled.

However in my understanding the bug report or rather the "feature"

https://www.illumos.org/issues/8587

is that this is correctly flagged as "feature" or "design decision" and not a 
bug.

Note that Feature #8587 is called "Feature" and not bug.

The assumption is that nowadays setups that require in.routed to run to figure 
out their routing tables, are less common than in the past; say back 30 or 35 
years ago.

Anyway , I will launch the pull request, not to break things or to cause 
problems,
but my reasoning is that IPS and the distribution constructor (distro_const) 
are able to deal with this,
you could for example create in theory a distribution which includes dynamic 
routing.

Regards,
David Stes


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Sun, 17 Apr 2022, s...@pandora.be wrote:


I was thinking that if the service or daemon is not enabled,
it perhaps also simply shouldn't be installed.

Otherwise the minimal server type installs software that just sits there to be 
disabled.


This sounds reasonable except for the "chicken and the egg" issue. 
If software is necessary in order for the system to receive updates or 
perform its function, then it is useful that it be installed.  I am 
not sure if that applies here, but it is always useful to make sure.


If OI is installed from a USB stick, then it is useful if the 
installation is fully usable without subsequent access to the 
"Internet".



Anyway this must be a super classical issue, if it is a bug, it is not a new 
bug, but more a very old one, perhaps 30 years old bug.


Yes, routed dates from the time of SunOS 4 (and likely earlier).

There was a time when network considerations were not primarily how a 
computer was going to access the "Internet".  Layer 2 switching, 
Spanning Tree, and VLANs were not yet a thing.  Ethernet LANs could 
not support a lot of hosts so there were more routers and subnets.


Using RIP was necessary in some networks and requires little 
configuration beyond enabling it.  These days if one wants routing, a 
better alternative such as OSPF should be selected.


Regardless, I am not sure it has been determined that 'routed' is 
responsible for some OI systems suffering from the local interface 
route being screwed up.  It is just a topic which came up because I 
mentioned it.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 16 apr 2022 om 0:58 schreef Joshua M. Clulow j...@sysmgr.org:
> 
> Whether it is installed or not, the routing setup service should not
> have a special case like it does today that tries to guess at whether
> or not this daemon should be enabled.  The operator should be required
> to turn it on explicitly via routeadm, or potentially via SMF.

I was thinking that if the service or daemon is not enabled,
it perhaps also simply shouldn't be installed.

Otherwise the minimal server type installs software that just sits there to be 
disabled.

Also the name of the package network/routing may be a little misleading,
I've opened a request to change it to for example,

https://www.illumos.org/issues/14644

Something like : system/network/dynamic-routing

If the package were called 'dynamic-routing' it could make sense to immediately 
enable the routing daemons when they are installed.

Anyway this must be a super classical issue, if it is a bug, it is not a new 
bug, but more a very old one, perhaps 30 years old bug.

For example the 1995 O'Reilly book 'Essential System Administration' from 
Aeleen Frisch,
warns that after installation of your operating system, check to disable routed.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Fri, 15 Apr 2022 at 09:23, s...@pandora.be  wrote:
> > This is indeed a bug:
> >14006 ipv4-routing should not be enabled by default
> >https://www.illumos.org/issues/14006
> Should ipv4-routing not be enabled or should it not be installed as part of 
> the 'minimal' server type ?

Whether it is installed or not, the routing setup service should not
have a special case like it does today that tries to guess at whether
or not this daemon should be enabled.  The operator should be required
to turn it on explicitly via routeadm, or potentially via SMF.

> https://www.illumos.org/issues/8587

Ah, that is indeed effectively a duplicate of #14006, but with a less
crisp description.  I've closed that one out in favour of 14006.

> I am not sure there is a bug here.   Also I'd say that this is not really an 
> installer bug.

There is definitely a bug, and yes, it's not an installer bug.  It's a
bug in the machinery behind routeadm and routing setup in the core of
the OS.

> I am writing 'problem' between quotes as it is unclear to me that it is 
> really a problem, although that from a 'disabling unnecessary daemons' 
> perspective (hardening) it could be considered a problem, but thanks to IPS 
> packaging easy to uninstall/fix.

It definitely is a problem.  Enabling the routing daemon may cause the
system to uncritically consume routes sent from remote hosts, and at a
minimum will unhelpfully adjust the routing table in some cases.

The service should be able to be installed without being enabled, as
it is today, by guessing at the operator intent by looking at the
current (dynamic!) state of the network stack and configuration.
Whether to include it by default in newly installed systems seems more
of a distribution-level question, but unrelated to how it works when
it is installed.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 12 apr 2022 om 21:12 schreef Discussion list for OpenIndiana 
openindiana-discuss@openindiana.org:
> 
> This is indeed a bug:
> 
>14006 ipv4-routing should not be enabled by default
>https://www.illumos.org/issues/14006
> 
> I haven't had time to work on it, but I am happy to talk it through
> with people who would like to pick it up and get it fixed!

Should ipv4-routing not be enabled or should it not be installed as part of the 
'minimal' server type ?

See:

https://www.illumos.org/issues/8587

I am not sure there is a bug here.   Also I'd say that this is not really an 
installer bug.

Perhaps there are some arguments for saying that network/routing shouldn't be 
in the 'minimal' server install type, but then again perhaps there could be 
very valid arguments for including the package.  The package network/routing 
seems to be easy to uninstall.

I was able to reproduce the 'problem' (?) of route:default being enabled, 
easily in the non-NWAM case (option static ip) and non-NWAM case (network None) 
: on first boot it immediately enables route:default.

As I wrote before I also was able to reproduce the 'problem' (?) of 
route:default being enabled in the NWAM case (option 1 in the installer) 
although for the NWAM case, I somehow had to reboot twice, and on first boot I 
initially noticed that route:default was disabled.

I am writing 'problem' between quotes as it is unclear to me that it is really 
a problem, although that from a 'disabling unnecessary daemons' perspective 
(hardening) it could be considered a problem, but thanks to IPS packaging easy 
to uninstall/fix.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 13 apr 2022 om 22:19 schreef Udo Grabowski (IMK) udo.grabow...@kit.edu:

> The facts are that server environments can be really involved (and
> even Desktops), and NWAM isn't fit for such complications.

 The installer (logged in /var/sadm/system/log/install_log) has 3 options:

 1) Automatic (enable NWAM)
 2) Manual (static ip without NWAM)
 3) None (configure it-yourself without NWAM)

 In option 1 and option 3   I just tried

  # pkg uninstall -v routing

 That works for me, it uninstalls "Network Routing Daemons and Commands" 
in.routed , rtquery and the SMF files for the routing/* directory and creates a 
server that runs either physical:default in option 3 or physical:nwam in option 
1, and has uninstalled 'routing' so it does not run in.routed.

 Also it is then irrelevant whether /etc/defaultrouter is present since routing 
is uninstalled 'routeadm' continues to show route:default is disabled of course.
 
 Basically you have to make sure to "disable unnecessary daemons" (server 
hardening).

 As it has always been the case for routed and IPS packaging could provide an 
interesting way here by uninstalling the IPS routing package.

 Note that 
http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
 documents using "nano" (?) to setup /etc/defaultrouter  but it does not 
document 'pkg uninstall -v routing'.

 In any case the docs.openindiana.org documentation gives interesting info 
about this issue.

 Maybe if the use of an old 'legacy' file like /etc/defaultrouter is not 
encouraged, then the docs.openindiana.org should not document the 
/etc/defaultrouter setup.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/13/22 22:47, Joshua M. Clulow via openindiana-discuss wrote:

I agree.  I think we have a bug with the routeadm thing, but otherwise
I think people are trying too hard to consider the history when
thinking about it.  Broadly, I would say:

 - If you don't care beyond "plug in a cable", use NWAM.
   That's what it's for.  We can and should fix any
   defects that prevent it working as effectively
   automatic in simple environments, which would
   include desktops and laptops and even single-
   homed servers with simple DHCP addresses.

 - If you want to be in more control, or to have
   things be more static, disable NWAM.  Use ipadm.
   You will know when this is you, because your
   needs will not be met by NWAM.

I wouldn't make it more complex than that.


Cheers.

-- Joshua M. Clulow http://blog.sysmgr.org 
___ openindiana-discuss 
mailing list openindiana-discuss@openindiana.org 
https://openindiana.org/mailman/listinfo/openindiana-discuss


Hi!

+1 !

The 'daily driver' for me is a laptop. Mostly i am connected in my home 
office with a cable,

sometimes i am sitting in some other room/outside connected via wifi,
or i take it  with me to my parents (oh they're getting old!).
NWAM supports me in this use case.

There are dedicated machines in my home network that have dedicated 
network parameters,
and some of them are manually configured. But these are special use 
cases in my opinion
which have (plenty of) additional manual configuration so that the use 
case can be fulfilled (file/print/sane/mail/NAT/whatever ) - the network 
config is only a small part and you will know "if" and "how"..


Greetings,

Stephan


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Wed, 13 Apr 2022 at 12:43, Toomas Soome via openindiana-discuss
 wrote:
> > On 13. Apr 2022, at 22:32, s...@pandora.be  wrote:
> > - Op 13 apr 2022 om 21:13 schreef Judah Richardson 
> > judahrichard...@gmail.com:
> >> Speaking as an experimental user (read: OI is not my daily driver) who
> >> acknowledges OI inherits a lot of internal functionality from a
> >> server/workstation distro (openSolaris): all of this strikes me as
> >> anachronistically(?) complicated for something that should by default
> >> expect to get an IP address lease from any DHCP server on a network to
> >> which it's connected.
> > It's not really anachronistic.  It's just that there is an enormous amount 
> > of history behind the networking stack and OpenIndiana is the kind of 
> > operating system distribution where users appreciate "old conventions" for 
> > configuring the network.
> This is just bad excuse to have mess about how you configure your network.

I agree.  I think we have a bug with the routeadm thing, but otherwise
I think people are trying too hard to consider the history when
thinking about it.  Broadly, I would say:

- If you don't care beyond "plug in a cable", use NWAM.
  That's what it's for.  We can and should fix any
  defects that prevent it working as effectively
  automatic in simple environments, which would
  include desktops and laptops and even single-
  homed servers with simple DHCP addresses.

- If you want to be in more control, or to have
  things be more static, disable NWAM.  Use ipadm.
  You will know when this is you, because your
  needs will not be met by NWAM.

I wouldn't make it more complex than that.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 13/04/2022 21:13, Judah Richardson wrote:

On Wed, Apr 13, 2022 at 2:03 PM Gary Mills  wrote:


On Wed, Apr 13, 2022 at 08:04:40PM +0200, s...@pandora.be wrote:


The documentation


http://docs.openindiana.org/handbook/systems-administration/#configuring-networking

writes:



"While usually server and desktop installations tend to use default
network configurations, laptop users can leverage nwam network
configuations."


That really means: "in an envionment where the network configuration
changes frequently".


Speaking as an experimental user (read: OI is not my daily driver) who
acknowledges OI inherits a lot of internal functionality from a
server/workstation distro (openSolaris): all of this strikes me as
anachronistically(?) complicated for something that should by default
expect to get an IP address lease from any DHCP server on a network to
which it's connected.

Or, put more simply: it assumes a lot of network complexity that isn't
there for most (home) networks.

I'm not necessarily advocating for it to change since I don't have the time
to do it and clearly it seems to work for many people; just making an
observation. I can't think of any other OS I've used (Android, Linux,
Windows, (Free)BSD) for which maintaining a network connection isn't
anything more than connecting an Ethernet cable.

> 

The facts are that server environments can be really involved (and
even Desktops), and NWAM isn't fit for such complications.
E.g., today I had a rather simple task: Copy a network configuration
from one wall connector to another, and our guys from the central
network messed it up... The simple task was: configure one TX wall
outlet to carry two tagged VLANs. Instead, they distributed them
untagged across two connectors. My fixed config (without NWAM)
made at least one connection visible, so that I could diagnose
and recover. NWAM would have messed that up completely as it cannot
(at least to my knowledge) cope with tagged VLANs, leaving the box
disconnected, which is not so funny when you are in home office...
We have a couple of such involved configs due to environmental/hardware
constraints which always happens if you have a larger machine park
with over 100 instances.
So you simply need all those manual knobs and switches that can be
turned to adapt to all these hassles. NWAM probably does its job
for the simple Desktop, but that isn't the right measure to decide
what a OS should provide as configuration tools. Then we could simply
drop in.routed and other seldom used stuff, since almost no one needs
that => please go away and use another OS if so... That's clearly not
the goal.
In fact, when you've worked a couple of decades in that job, you would
find out that you may at least once needed those tools and were happy
to have them.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Toomas Soome via openindiana-discuss]

> On 13. Apr 2022, at 22:32, s...@pandora.be  wrote:
> 
> 
> - Op 13 apr 2022 om 21:13 schreef Judah Richardson 
> judahrichard...@gmail.com:
> 
>> Speaking as an experimental user (read: OI is not my daily driver) who
>> acknowledges OI inherits a lot of internal functionality from a
>> server/workstation distro (openSolaris): all of this strikes me as
>> anachronistically(?) complicated for something that should by default
>> expect to get an IP address lease from any DHCP server on a network to
>> which it's connected.
> 
> It's not really anachronistic.  It's just that there is an enormous amount of 
> history behind the networking stack and OpenIndiana is the kind of operating 
> system distribution where users appreciate "old conventions" for configuring 
> the network.
> 

This is just bad excuse to have mess about how you configure your network. 

rgds,
toomas
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 13 apr 2022 om 21:13 schreef Judah Richardson 
judahrichard...@gmail.com:

> Speaking as an experimental user (read: OI is not my daily driver) who
> acknowledges OI inherits a lot of internal functionality from a
> server/workstation distro (openSolaris): all of this strikes me as
> anachronistically(?) complicated for something that should by default
> expect to get an IP address lease from any DHCP server on a network to
> which it's connected.

It's not really anachronistic.  It's just that there is an enormous amount of 
history behind the networking stack and OpenIndiana is the kind of operating 
system distribution where users appreciate "old conventions" for configuring 
the network.

I appreciate the attempt (and necessity) in Illumos/OI for retaining backward 
compatibility with the network configuration scripts and methods of the past ...

In the case of the route:default service the manifest still has :

$ grep enable /lib/svc/manifest/network/routing/route.xml 



When I attempted to reproduce the issue, initially it seems on first boot that 
the service was created disabled.
So at first I thought I could not reproduce it.  The installer seems to create 
route:default in disabled state
(as it should).

Something seemed to have enabled it on the second boot for me.

Anyway the method to disable route:default (if it is not needed) is described 
in 
https://www.illumos.org/issues/14006

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Wed, Apr 13, 2022 at 2:03 PM Gary Mills  wrote:

> On Wed, Apr 13, 2022 at 08:04:40PM +0200, s...@pandora.be wrote:
>
> > The documentation
> >
> http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
> > writes:
>
> > "While usually server and desktop installations tend to use default
> > network configurations, laptop users can leverage nwam network
> > configuations."
>
> That really means: "in an envionment where the network configuration
> changes frequently".
>
Speaking as an experimental user (read: OI is not my daily driver) who
acknowledges OI inherits a lot of internal functionality from a
server/workstation distro (openSolaris): all of this strikes me as
anachronistically(?) complicated for something that should by default
expect to get an IP address lease from any DHCP server on a network to
which it's connected.

Or, put more simply: it assumes a lot of network complexity that isn't
there for most (home) networks.

I'm not necessarily advocating for it to change since I don't have the time
to do it and clearly it seems to work for many people; just making an
observation. I can't think of any other OS I've used (Android, Linux,
Windows, (Free)BSD) for which maintaining a network connection isn't
anything more than connecting an Ethernet cable.

>
> > So that doc positions NWAM as a solution for 'laptop users'.
> > Opinions may differ ...
>
> NWAM actually works well in many situations.
>
>
> --
> -Gary Mills--refurb--Winnipeg, Manitoba,
> Canada-
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 13 apr 2022 om 21:02 schreef gary mills gary_mi...@fastmail.fm:

>> So that doc positions NWAM as a solution for 'laptop users'.
>> Opinions may differ ...
> 
> NWAM actually works well in many situations.


That's true.   Maybe the doc could be rephrased.

Also describing Network Auto-Magic (NWAM) as a new approach is not entirely up 
to date in 2022.

Anyway 
http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
is a valuable doc.

It could indicate that NWAM has proven itself over the years as a good or best 
choice for servers.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Gary Mills]

On Wed, Apr 13, 2022 at 08:04:40PM +0200, s...@pandora.be wrote:

> The documentation
> http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
> writes:

> "While usually server and desktop installations tend to use default
> network configurations, laptop users can leverage nwam network
> configuations."

That really means: "in an envionment where the network configuration
changes frequently".

> So that doc positions NWAM as a solution for 'laptop users'.
> Opinions may differ ...

NWAM actually works well in many situations.


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 13 apr 2022 om 20:10 schreef Udo Grabowski (IMK) udo.grabow...@kit.edu:

> But what happens if you place an *empty* /etc/defaultrouter there ?

 I didn't test that.

 However I just rebooted my test server which I had installed from 
OI-hipster-202110 and then I can reproduce the problem.

 On the first boot, route:default was disabled.

 On the second boot, route:default was enabled.  Bad news ...

 So that confirms https://www.illumos.org/issues/14006

 On my OpenIndiana workstation with the 2 interfaces (e1000g0 and igb0) I have 
not observed such a thing.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 13/04/2022 20:04, s...@pandora.be wrote:

- Op 12 apr 2022 om 20:00 schreef John D Groenveld groenv...@acm.org:


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


I can't reproduce this.

When I install from the OI-hipster-text-20211031.iso it does not enable 
routing/route.


Also my OpenIndiana system (Dell Precision 3640 with 2 NIC, 1 e1000g0 and 1 
igb0)
is not running in.routed, route:default) and is fairly up to date with recent 
OI.

I didn't have to disable in.routed or route:default , by default it was NOT 
enabled.

When I install from the OI-hipster-text-20211031.iso

$ cat OI-hipster-text-20211031.iso.sha256sum
08d938497dfb39ab51da598437cc4cadcad9c936a9371c58520fe8e99431e86d  
OI-hipster-text-20211031.iso

after the install (where I selected "Automatic" for the NIC, a single NIC), I 
login and

routeadm shows : IPV4routing disabled

Udo Grabowski will be pleased to read that :-)



Yeah, indeed !


Can you be more specific please and check the "nwadmadm list" on your server and
/var/sadm/system/logs/install_log.

Maybe there is a specific scenario where indeed route:default is enabled,
as also confirmed in https://www.illumos.org/issues/14006

In fact the bug report 14006 refers to the manpage of routeadm which describes 
some conditions where routing is ENABLED indeed, so there is something that can 
indeed enable route:default accidentally.

However the bug report 14006 does not say this is OpenIndiana specific, it is a 
Illumos bug report possibly for a different distribution ?

However when I test this , I have no /etc/defaultrouter and route:default is 
not enabled.



But what happens if you place an *empty* /etc/defaultrouter there ?


For me on my test system "nwamadm list" shows "ncp Automatic online".

in.routed is not running, routeadm shows all disabled

I mean: the command routeadm after a fresh install of 202110 shows IPv4 and 
IPv6 forwarding and routing disabled.

Note however that the installer has multiple options, so I installed using 1 
NIC here and choose network type 'Automatic'.

Finally to touch a painful issue:   the type 'Automatic' is possible NOT the 
best choice for servers.

The documentation 
http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
writes:

"While usually server and desktop installations tend to use default network 
configurations, laptop users can leverage nwam network configuations."

So that doc positions NWAM as a solution for 'laptop users'.  Opinions may 
differ ...

Regards,
David Stes


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 12 apr 2022 om 20:00 schreef John D Groenveld groenv...@acm.org:

> svc:/network/routing/route is enabled out of the box with
> OI-hipster-text-20211031.iso

I can't reproduce this.

When I install from the OI-hipster-text-20211031.iso it does not enable 
routing/route.


Also my OpenIndiana system (Dell Precision 3640 with 2 NIC, 1 e1000g0 and 1 
igb0)
is not running in.routed, route:default) and is fairly up to date with recent 
OI.

I didn't have to disable in.routed or route:default , by default it was NOT 
enabled.

When I install from the OI-hipster-text-20211031.iso

$ cat OI-hipster-text-20211031.iso.sha256sum 
08d938497dfb39ab51da598437cc4cadcad9c936a9371c58520fe8e99431e86d  
OI-hipster-text-20211031.iso

after the install (where I selected "Automatic" for the NIC, a single NIC), I 
login and

routeadm shows : IPV4routing disabled

Udo Grabowski will be pleased to read that :-)

Can you be more specific please and check the "nwadmadm list" on your server and
/var/sadm/system/logs/install_log.

Maybe there is a specific scenario where indeed route:default is enabled, 
as also confirmed in https://www.illumos.org/issues/14006

In fact the bug report 14006 refers to the manpage of routeadm which describes 
some conditions where routing is ENABLED indeed, so there is something that can 
indeed enable route:default accidentally.

However the bug report 14006 does not say this is OpenIndiana specific, it is a 
Illumos bug report possibly for a different distribution ?

However when I test this , I have no /etc/defaultrouter and route:default is 
not enabled.

For me on my test system "nwamadm list" shows "ncp Automatic online".

in.routed is not running, routeadm shows all disabled 

I mean: the command routeadm after a fresh install of 202110 shows IPv4 and 
IPv6 forwarding and routing disabled.

Note however that the installer has multiple options, so I installed using 1 
NIC here and choose network type 'Automatic'.

Finally to touch a painful issue:   the type 'Automatic' is possible NOT the 
best choice for servers.

The documentation 
http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
writes:

"While usually server and desktop installations tend to use default network 
configurations, laptop users can leverage nwam network configuations."

So that doc positions NWAM as a solution for 'laptop users'.  Opinions may 
differ ...

Regards,
David Stes


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 13 apr 2022 om 6:32 schreef Judah Richardson judahrichard...@gmail.com:

> I can confirm that mousing over the network tray icon in MATE results in a
> popup that shows both the network profile and location are set to Automatic.


As you can read at "Troubleshooting NWAM" there is an option of at least two 
models,

svcs physical:default
or
svcs physical:nwam

The Troubleshooting NWAM warns that in some cases after a while Automatic could 
change to NoNet.

http://docs.openindiana.org/handbook/systems-administration/#configuring-networking

You can also check with "svcs -a | grep physical".

In addition there is a log file : /var/sadm/system/logs/install_log

The install_log of the OS records some of the answers that you typed while you 
installed the OS.

You made some choices during the install, and for example there can be a line 
in install_log :

network_type.py:174 Configuring NIC as: automatic

or 

network_type.py;174 Configuring NIC as: manual

This depends on the answers you enter for the install screens.

obviously there are some many different scenario's and perhaps you entered some 
incorrect choices.

You could check the /var/sadm/system/logs/install_log to see whether there is a 
hint in there about how this perhaps accidentally happened.

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 13/04/2022 16:32, Gary Mills wrote:

On Tue, Apr 12, 2022 at 10:42:53PM -0700, Joshua M. Clulow via 
openindiana-discuss wrote:


As suggested in the ticket, I would:

 # routeadm -d ipv4-routing -u

The "svc:/network/routing/route:default" instance should then be
disabled, unlike in your output above.


I have two different routing configurations.  The first is for a
system that acts as a NAT router using ipfilter.  /etc/defaultrouter
does not exist.  It has two ethernet interfaces.  One connects to my
cable modem.  The other goes to my private network, through a switch:

 $ routeadm
   Configuration   Current  Current
  Option   ConfigurationSystem State
 ---
IPv4 routing   disabled disabled
IPv6 routing   disabled disabled
 IPv4 forwarding   enabled  enabled
 IPv6 forwarding   disabled disabled
 ...

The "IPv4 forwarding" setting is required by ipfilter.

The other configuration is for a typical system on my private
network, using all the defaults, with a single ethernet:

 $ routeadm
   Configuration   Current  Current
  Option   ConfigurationSystem State
 ---
IPv4 routing   enabled  enabled
IPv6 routing   disabled disabled
 IPv4 forwarding   disabled disabled
 IPv6 forwarding   disabled disabled
 ...
 


This is what a typical off-the-shelf client machine should look like:

# routeadm
  Configuration   Current  Current
 Option   ConfigurationSystem State
---
   IPv4 routing   disabled disabled
   IPv6 routing   disabled disabled
IPv4 forwarding   disabled disabled
IPv6 forwarding   disabled disabled

   Routing services   "route:default ripng:default"

Routing daemons:

  STATE   FMRI
   disabled   svc:/network/routing/legacy-routing:ipv4
   disabled   svc:/network/routing/legacy-routing:ipv6
   disabled   svc:/network/routing/rdisc:default
   disabled   svc:/network/routing/route:default
   disabled   svc:/network/routing/ripng:default
 online   svc:/network/routing/ndp:default
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Gary Mills]

On Tue, Apr 12, 2022 at 10:42:53PM -0700, Joshua M. Clulow via 
openindiana-discuss wrote:
> 
> As suggested in the ticket, I would:
> 
> # routeadm -d ipv4-routing -u
> 
> The "svc:/network/routing/route:default" instance should then be
> disabled, unlike in your output above.

I have two different routing configurations.  The first is for a
system that acts as a NAT router using ipfilter.  /etc/defaultrouter
does not exist.  It has two ethernet interfaces.  One connects to my
cable modem.  The other goes to my private network, through a switch:

$ routeadm
  Configuration   Current  Current
 Option   ConfigurationSystem State
---
   IPv4 routing   disabled disabled
   IPv6 routing   disabled disabled
IPv4 forwarding   enabled  enabled
IPv6 forwarding   disabled disabled
... 

The "IPv4 forwarding" setting is required by ipfilter.

The other configuration is for a typical system on my private
network, using all the defaults, with a single ethernet:

$ routeadm
  Configuration   Current  Current
 Option   ConfigurationSystem State
---
   IPv4 routing   enabled  enabled
   IPv6 routing   disabled disabled
IPv4 forwarding   disabled disabled
IPv6 forwarding   disabled disabled
...


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/13/22 07:42, Joshua M. Clulow via openindiana-discuss wrote:

On Tue, 12 Apr 2022 at 22:17, Stephan Althaus
 wrote:

So, the default for the default routing features 'needed' for this
scenario should be enabled. If in.routed is not necessary, it should be
disabled by default. If it is needed for virtualisation network to
operate correctly (mostly  thinking of dhcp-enabled vm-clients) it
should be enabled by default.

I don't think in.routed should ever be enabled by default, even in
server configurations.  If you want to use it, it's because of an
explicit policy decision at your site.  That's why I filed 14006.


Nevertheless, the 'lost' network connection is not solved yet.

In my case of the 'lost' default gateway i am still thinking that it
should not happen in either case of a running or not running in.routed
daemon.
I thought i had disabled the route yesterday but it is running (?). The
'history' shows that i disabled it at 19:55 yesterday. Maybe
routing-setup did re-enable it at boot this morning..

$ svcs -a|grep rout
disabled6:36:37 svc:/network/routing/ripng:default
disabled6:36:37 svc:/network/routing/legacy-routing:ipv4
disabled6:36:37 svc:/network/routing/legacy-routing:ipv6
disabled6:36:37 svc:/network/routing/rdisc:default
online  6:36:40 svc:/network/routing-setup:default
online  6:36:40 svc:/network/routing/route:default
online  6:36:48 svc:/network/routing/ndp:default

As suggested in the ticket, I would:

 # routeadm -d ipv4-routing -u

The "svc:/network/routing/route:default" instance should then be
disabled, unlike in your output above.

When you're having the connectivity issue, it would likely help to
look at some of the basic network diagnostic tools; e.g.,

 $ routeadm
 $ netstat -rnv
 $ ipadm show-addr
 $ nwamadm list
 $ netstat -D
 $ cat /etc/resolv.conf


Cheers.


Hi!

Ok this is my data, currently in working state:

$ routeadm
  Configuration   Current  Current
 Option   Configuration    System State
---
   IPv4 routing   disabled disabled
   IPv6 routing   disabled disabled
    IPv4 forwarding   disabled disabled
    IPv6 forwarding   disabled disabled

   Routing services   "route:default ripng:default"

Routing daemons:

  STATE   FMRI
   disabled   svc:/network/routing/ripng:default
 online   svc:/network/routing/ndp:default
   disabled svc:/network/routing/legacy-routing:ipv4
   disabled svc:/network/routing/legacy-routing:ipv6
   disabled   svc:/network/routing/rdisc:default
   disabled   svc:/network/routing/route:default
$ netstat -rnv

IRE Table: IPv4
  Destination Mask   Gateway  Device MTU  
Ref Flg  Out   In/Fwd
 ---  -- - 
--- --- -- --
default  0.0.0.0 192.168.2.1  e1000g4 1500  
14 UG   16204  0
127.0.0.1    255.255.255.255 127.0.0.1    lo0 8232   2 
UH 351    351
192.168.2.0  255.255.255.0   192.168.2.63 e1000g4 1500   
5 U  172  0


IRE Table: IPv6
  Destination/Mask    Gateway    If MTU  Ref 
Flags  Out   In/Fwd
--- --- - - --- 
- -- --
::1 ::1 lo0 8252   2 
UH 0  0
fe80::/10   fe80::a64c:c8ff:fe79:c2f2   e1000g4 1500   2 
U  0  0


$ ipadm show-addr
ADDROBJ   TYPE STATE    ADDR
lo0/v4    static   ok   127.0.0.1/8
e1000g4/_b    dhcp ok   192.168.2.63/24
lo0/v6    static   ok   ::1/128
e1000g4/_a    addrconf ok fe80::a64c:c8ff:fe79:c2f2/10

$ nwamadm list
TYPE    PROFILE    STATE
ncp Automatic  online
ncu:phys    e1000g4    online
ncu:ip  e1000g4    online
loc Automatic  online
loc NoNet  offline
loc User   disabled

$ netstat -D
Interface  State Sent  Recv  Declined  Flags
e1000g4    BOUND    3 1 0
(Began, Expires, Renew) = (04/13/2022 06:36, 05/13/2022 06:36, 
04/28/2022 06:36)

e1000g4    SELECTING   50 0 0  [V6]

$ cat /etc/resolv.conf
domain  fritz.box
search fritz.box
nameserver  192.168.2.1



Stephan


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Tue, 12 Apr 2022 at 22:17, Stephan Althaus
 wrote:
> So, the default for the default routing features 'needed' for this
> scenario should be enabled. If in.routed is not necessary, it should be
> disabled by default. If it is needed for virtualisation network to
> operate correctly (mostly  thinking of dhcp-enabled vm-clients) it
> should be enabled by default.

I don't think in.routed should ever be enabled by default, even in
server configurations.  If you want to use it, it's because of an
explicit policy decision at your site.  That's why I filed 14006.

> Nevertheless, the 'lost' network connection is not solved yet.
>
> In my case of the 'lost' default gateway i am still thinking that it
> should not happen in either case of a running or not running in.routed
> daemon.
> I thought i had disabled the route yesterday but it is running (?). The
> 'history' shows that i disabled it at 19:55 yesterday. Maybe
> routing-setup did re-enable it at boot this morning..
>
> $ svcs -a|grep rout
> disabled6:36:37 svc:/network/routing/ripng:default
> disabled6:36:37 svc:/network/routing/legacy-routing:ipv4
> disabled6:36:37 svc:/network/routing/legacy-routing:ipv6
> disabled6:36:37 svc:/network/routing/rdisc:default
> online  6:36:40 svc:/network/routing-setup:default
> online  6:36:40 svc:/network/routing/route:default
> online  6:36:48 svc:/network/routing/ndp:default

As suggested in the ticket, I would:

# routeadm -d ipv4-routing -u

The "svc:/network/routing/route:default" instance should then be
disabled, unlike in your output above.

When you're having the connectivity issue, it would likely help to
look at some of the basic network diagnostic tools; e.g.,

$ routeadm
$ netstat -rnv
$ ipadm show-addr
$ nwamadm list
$ netstat -D
$ cat /etc/resolv.conf


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/12/22 21:47, Joshua M. Clulow via openindiana-discuss wrote:

On Tue, 12 Apr 2022 at 12:21, Udo Grabowski (IMK)  wrote:

In principle, the easiest fix is to revert to

in the respective services in /lib/svc/manifest/network/routing/ .
But I've not seen a 202* OI version, I'm still on 2017...

I don't believe that is quite right.  There is specific machinery in
the OS to enable ipv4-routing under some conditions when a specific
policy has not been specified by routeadm that will need to be
unwound; e.g., see "cmd/svc/milestone/net-routing-setup" where it
mentions "routeadm/ipv4-routing-set".


Cheers.


Hi!

Thanks all for your professional input to this topic.

WRT "should in.routed be enabled by default"

From my point of view of a Openindiana end user i think the 'default 
network topology' in a soho office is a bunch of network devices 
connected to an internet router which provides dhcp for all devices.
I  enabled 'always same ip for this device' for some devices, and have 
some static ip adresses for a (sort of) fileserver, a sane server and a 
MFU printer.
The workload for some IO users includes the use of virtualisation via 
virtualbox/bhyve and non-global-zones as these topics are key features 
for illumos-based systens.
I think the use of nwam as default is very welcome, and can be changed 
by the user if needed.


So, the default for the default routing features 'needed' for this 
scenario should be enabled. If in.routed is not necessary, it should be 
disabled by default. If it is needed for virtualisation network to 
operate correctly (mostly  thinking of dhcp-enabled vm-clients) it 
should be enabled by default.


Nevertheless, the 'lost' network connection is not solved yet.

In my case of the 'lost' default gateway i am still thinking that it 
should not happen in either case of a running or not running in.routed 
daemon.
I thought i had disabled the route yesterday but it is running (?). The 
'history' shows that i disabled it at 19:55 yesterday. Maybe 
routing-setup did re-enable it at boot this morning..


$ svcs -a|grep rout
disabled    6:36:37 svc:/network/routing/ripng:default
disabled    6:36:37 svc:/network/routing/legacy-routing:ipv4
disabled    6:36:37 svc:/network/routing/legacy-routing:ipv6
disabled    6:36:37 svc:/network/routing/rdisc:default
online  6:36:40 svc:/network/routing-setup:default
online  6:36:40 svc:/network/routing/route:default
online  6:36:48 svc:/network/routing/ndp:default

I don't know the case details for Mr.Richardson right now and i am sorry 
for hijacking, but i use at least the same ethernet device i think 
(Ethernet Connection (5) I219-LM 8086:15e3).


Stephan


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022 at 12:14 PM Judah Richardson 
wrote:

>
>
> On Tue, Apr 12, 2022 at 11:53 AM s...@pandora.be  wrote:
>
>>
>> There is a brief but good description at
>>
>>
>> http://docs.openindiana.org/handbook/systems-administration/#configuring-networking
>
> Took a cursory glance at this. I suspect NWAM is set to Automatic on my
> OI machine because MATE's system tray networking icon toast message says
> something like Setting profile: Automatic (I don't recall exactly) during
> initial startup.
>
I can confirm that mousing over the network tray icon in MATE results in a
popup that shows both the network profile and location are set to Automatic.

>
> I'll check, though.
>
>>
>>
>> in the section 'configuring networking' the OpenIndiana handbook
>> discusses the NWAM.
>>
>> Specifically :
>>
>> "Network Auto-Magic (NWAM) is a new approach to managing network
>> interfaces that was introduced with OpenSolaris. NWAM introduced network
>> profiles to be able to change network settings on the fly."
>>
>> However the question from John D Groenveld was what the output of
>> 'routeadm' was,
>> and whether the service route:default was enabled.
>>
>> So whether you have a requirement for enabling any routing daemons and if
>> not whether it helps to disable in.routed.
>>
>> Regards,
>> David Stes
>>
>> - Op 12 apr 2022 om 18:48 schreef Judah Richardson
>> judahrichard...@gmail.com:
>>
>> > On Tue, Apr 12, 2022 at 11:46 AM s...@pandora.be 
>> wrote:
>> >
>> >>
>> >> - Op 11 apr 2022 om 15:47 schreef John D Groenveld
>> groenv...@acm.org:
>> >>
>> >> > Does disabling in.routed with routeadm(8) prevent your default
>> >> > route from being disappeared?
>> >> > https://illumos.org/man/8/routeadm>
>> >>
>> >> I also wonder why this system that becomes unreachable after a a
>> certain
>> >> uptime,
>> >> runs 'in.routed'.   And indeed whether disabling in.routed can be done,
>> >> or is it (according to the original poster) a requirement for the setup
>> >> that route:default is enabled ?
>> >>
>> >> Another basic thing to verify is perhaps whether the server is running
>> >> nwam ?
>> >> Is svcs physical:default disabled and svcs physical:nwam enabled ?
>> >
>> > I've never heard of any of these. How do I check their status?
>> >
>> >>
>> >>
>> >> Regards,
>> >> David Stes
>> >>
>> >> ___
>> >> openindiana-discuss mailing list
>> >> openindiana-discuss@openindiana.org
>> >> https://openindiana.org/mailman/listinfo/openindiana-discuss
>> >>
>> > ___
>> > openindiana-discuss mailing list
>> > openindiana-discuss@openindiana.org
>> > https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>> ___
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Tue, 12 Apr 2022 at 12:21, Udo Grabowski (IMK)  wrote:
> In principle, the easiest fix is to revert to
> 
> in the respective services in /lib/svc/manifest/network/routing/ .
> But I've not seen a 202* OI version, I'm still on 2017...

I don't believe that is quite right.  There is specific machinery in
the OS to enable ipv4-routing under some conditions when a specific
policy has not been specified by routeadm that will need to be
unwound; e.g., see "cmd/svc/milestone/net-routing-setup" where it
mentions "routeadm/ipv4-routing-set".


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 21:21, Udo Grabowski (IMK) wrote:



On 12/04/2022 21:12, Joshua M. Clulow via openindiana-discuss wrote:
On Tue, 12 Apr 2022 at 11:52, Udo Grabowski (IMK) 
 wrote:

On 12/04/2022 20:42, Bob Friesenhahn wrote:

On Tue, 12 Apr 2022, Judah Richardson wrote:
On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 


wrote:


On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo

Grabowski (IMK)

" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso

...

...


This is indeed a bug:

 14006 ipv4-routing should not be enabled by default
 https://www.illumos.org/issues/14006

>> 

In principle, the easiest fix is to revert to

in the respective services in /lib/svc/manifest/network/routing/ .
...Hm, probably not *that* easy, routeadm interferes with that based

on the existence of an entry in /etc/defaultrouter (which we've always
set on our machines, so I've never seen this problem).
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 21:12, Joshua M. Clulow via openindiana-discuss wrote:

On Tue, 12 Apr 2022 at 11:52, Udo Grabowski (IMK)  wrote:

On 12/04/2022 20:42, Bob Friesenhahn wrote:

On Tue, 12 Apr 2022, Judah Richardson wrote:

On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
wrote:


On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo

Grabowski (IMK)

" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


Why ?? This hasn't been the case for at least two decades of
Solaris and beyond.


Probably an oversight, I'd guess. As with many such situations, things
that
aren't obviously and critically broken don't get much attention ;)


It is not really an oversight since all computers with a TCP/IP stack
need to deal with some level of routing even if they are not acting as a
gateway.  If there is ever more than one way to get "there" via the L2
network then running a higher-level routing protocol (e.g. RIP) can help
the TCP/IP stack make the right decisions if the involved routers use
the same protocol.  The host might participate in RIP or it might just
act as an observer.

In many cases one or more computers are attached to a shared L2 network
with a single upstream router. In this case, using DHCP to configure the
default route, or static configuration to provide the default route, can
be a good choice. There are other means such as ICMP Router Discovery
Protocol (https://en.wikipedia.org/wiki/ICMP_Router_Discovery_Protocol)
or even ICMP redirects.


I have a few machines with two L2 networks (a.k.a. tagged VPN), and even
those don't require the routing service. In fact, in my over 3 decades
of experience with Sun machines, I only once have seen that the routing
service had to be active. That one case was when I experimented with the
COMSTAR network simulation tools to play with virtual switches and
routers.


Goodness, what a lot of mails!

This is indeed a bug:

 14006 ipv4-routing should not be enabled by default
 https://www.illumos.org/issues/14006

I haven't had time to work on it, but I am happy to talk it through
with people who would like to pick it up and get it fixed!


In principle, the easiest fix is to revert to

in the respective services in /lib/svc/manifest/network/routing/ .
But I've not seen a 202* OI version, I'm still on 2017...
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Tue, 12 Apr 2022 at 11:52, Udo Grabowski (IMK)  wrote:
> On 12/04/2022 20:42, Bob Friesenhahn wrote:
> > On Tue, 12 Apr 2022, Judah Richardson wrote:
> >> On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
> >> wrote:
> >>
> >>> On 12/04/2022 20:00, John D Groenveld wrote:
>  In message , "Udo
> >>> Grabowski (IMK)
>  " writes:
> > No, it isn't, it's controlled by
> > /lib/svc/manifest/network/routing/route.xml ,
> > which is not enabled by default, as practically no machine
> > in the field is working as a router, you have to specifically
> > enable the route:default service.
> 
>  svc:/network/routing/route is enabled out of the box with
>  OI-hipster-text-20211031.iso
> >>>
> >>> Why ?? This hasn't been the case for at least two decades of
> >>> Solaris and beyond.
> >>
> >> Probably an oversight, I'd guess. As with many such situations, things
> >> that
> >> aren't obviously and critically broken don't get much attention ;)
> >
> > It is not really an oversight since all computers with a TCP/IP stack
> > need to deal with some level of routing even if they are not acting as a
> > gateway.  If there is ever more than one way to get "there" via the L2
> > network then running a higher-level routing protocol (e.g. RIP) can help
> > the TCP/IP stack make the right decisions if the involved routers use
> > the same protocol.  The host might participate in RIP or it might just
> > act as an observer.
> >
> > In many cases one or more computers are attached to a shared L2 network
> > with a single upstream router. In this case, using DHCP to configure the
> > default route, or static configuration to provide the default route, can
> > be a good choice. There are other means such as ICMP Router Discovery
> > Protocol (https://en.wikipedia.org/wiki/ICMP_Router_Discovery_Protocol)
> > or even ICMP redirects.
>
> I have a few machines with two L2 networks (a.k.a. tagged VPN), and even
> those don't require the routing service. In fact, in my over 3 decades
> of experience with Sun machines, I only once have seen that the routing
> service had to be active. That one case was when I experimented with the
> COMSTAR network simulation tools to play with virtual switches and
> routers.

Goodness, what a lot of mails!

This is indeed a bug:

14006 ipv4-routing should not be enabled by default
https://www.illumos.org/issues/14006

I haven't had time to work on it, but I am happy to talk it through
with people who would like to pick it up and get it fixed!


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 20:52, Udo Grabowski (IMK) wrote:

... (a.k.a. tagged VPN) ...

... should be tagged VLAN.

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 20:42, Bob Friesenhahn wrote:

On Tue, 12 Apr 2022, Judah Richardson wrote:


On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
wrote:


On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo

Grabowski (IMK)

" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


Why ?? This hasn't been the case for at least two decades of
Solaris and beyond.


Probably an oversight, I'd guess. As with many such situations, things 
that

aren't obviously and critically broken don't get much attention ;)


It is not really an oversight since all computers with a TCP/IP stack 
need to deal with some level of routing even if they are not acting as a 
gateway.  If there is ever more than one way to get "there" via the L2 
network then running a higher-level routing protocol (e.g. RIP) can help 
the TCP/IP stack make the right decisions if the involved routers use 
the same protocol.  The host might participate in RIP or it might just 
act as an observer.


In many cases one or more computers are attached to a shared L2 network 
with a single upstream router. In this case, using DHCP to configure the 
default route, or static configuration to provide the default route, can 
be a good choice. There are other means such as ICMP Router Discovery 
Protocol (https://en.wikipedia.org/wiki/ICMP_Router_Discovery_Protocol) 
or even ICMP redirects.


I have a few machines with two L2 networks (a.k.a. tagged VPN), and even
those don't require the routing service. In fact, in my over 3 decades
of experience with Sun machines, I only once have seen that the routing
service had to be active. That one case was when I experimented with the
COMSTAR network simulation tools to play with virtual switches and
routers.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Tue, 12 Apr 2022, Udo Grabowski (IMK) wrote:


Probably an oversight, I'd guess. As with many such situations, things that
aren't obviously and critically broken don't get much attention ;)


In fact, it is critically broken, as a routing service introduces
a whole new security context that can open critical intrusion pathes.


This is true, and in fact RIP 
(https://en.wikipedia.org/wiki/Routing_Information_Protocol) has been 
known to be flawed since the early '90s.


Any service not needed by a host should be disabled if possible.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Tue, 12 Apr 2022, Judah Richardson wrote:


On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
wrote:


On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo

Grabowski (IMK)

" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


Why ?? This hasn't been the case for at least two decades of
Solaris and beyond.


Probably an oversight, I'd guess. As with many such situations, things that
aren't obviously and critically broken don't get much attention ;)


It is not really an oversight since all computers with a TCP/IP stack 
need to deal with some level of routing even if they are not acting as 
a gateway.  If there is ever more than one way to get "there" via the 
L2 network then running a higher-level routing protocol (e.g. RIP) can 
help the TCP/IP stack make the right decisions if the involved routers 
use the same protocol.  The host might participate in RIP or it might 
just act as an observer.


In many cases one or more computers are attached to a shared L2 
network with a single upstream router. In this case, using DHCP to 
configure the default route, or static configuration to provide the 
default route, can be a good choice. There are other means such as 
ICMP Router Discovery Protocol 
(https://en.wikipedia.org/wiki/ICMP_Router_Discovery_Protocol) or even 
ICMP redirects.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022, 13:36 Udo Grabowski (IMK) 
wrote:

> On 12/04/2022 20:29, Judah Richardson wrote:
> > On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
> > wrote:
> >
> >> On 12/04/2022 20:00, John D Groenveld wrote:
> >>> In message , "Udo
> >> Grabowski (IMK)
> >>> " writes:
>  No, it isn't, it's controlled by
>  /lib/svc/manifest/network/routing/route.xml ,
>  which is not enabled by default, as practically no machine
>  in the field is working as a router, you have to specifically
>  enable the route:default service.
> >>>
> >>> svc:/network/routing/route is enabled out of the box with
> >>> OI-hipster-text-20211031.iso
> >>
> >> Why ?? This hasn't been the case for at least two decades of
> >> Solaris and beyond.
> >
> > Probably an oversight, I'd guess. As with many such situations, things
> that
> > aren't obviously and critically broken don't get much attention ;)
>
> In fact, it is critically broken, as a routing service introduces
> a whole new security context that can open critical intrusion pathes.
>
Ah, TIL. It'll probably be late next week before I can take another crack
at resolving this issue on my end and report anything useful. For now I'm
hoping the adjustment I made earlier does the trick.

>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 20:29, Judah Richardson wrote:

On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
wrote:


On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo

Grabowski (IMK)

" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


Why ?? This hasn't been the case for at least two decades of
Solaris and beyond.


Probably an oversight, I'd guess. As with many such situations, things that
aren't obviously and critically broken don't get much attention ;)


In fact, it is critically broken, as a routing service introduces
a whole new security context that can open critical intrusion pathes.

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022, 13:27 Udo Grabowski (IMK) 
wrote:

> On 12/04/2022 20:00, John D Groenveld wrote:
> > In message , "Udo
> Grabowski (IMK)
> > " writes:
> >> No, it isn't, it's controlled by
> >> /lib/svc/manifest/network/routing/route.xml ,
> >> which is not enabled by default, as practically no machine
> >> in the field is working as a router, you have to specifically
> >> enable the route:default service.
> >
> > svc:/network/routing/route is enabled out of the box with
> > OI-hipster-text-20211031.iso
>
> Why ?? This hasn't been the case for at least two decades of
> Solaris and beyond.

Probably an oversight, I'd guess. As with many such situations, things that
aren't obviously and critically broken don't get much attention ;)

That's a wrong move.
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 20:00, John D Groenveld wrote:

In message , "Udo Grabowski (IMK)
" writes:

No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.


svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso


Why ?? This hasn't been the case for at least two decades of
Solaris and beyond. That's a wrong move.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[John D Groenveld]

In message , "Udo Grabowski (IMK)
" writes:
>No, it isn't, it's controlled by
>/lib/svc/manifest/network/routing/route.xml ,
>which is not enabled by default, as practically no machine
>in the field is working as a router, you have to specifically
>enable the route:default service.

svc:/network/routing/route is enabled out of the box with
OI-hipster-text-20211031.iso

John
groenv...@acm.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022 at 12:09 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Tue, 12 Apr 2022, s...@pandora.be wrote:
>
> >
> > - Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org
> :
> >
> >> Does disabling in.routed with routeadm(8) prevent your default
> >> route from being disappeared?
> >> https://illumos.org/man/8/routeadm>
> >
> > I also wonder why this system that becomes unreachable after a a certain
> uptime,
> > runs 'in.routed'.   And indeed whether disabling in.routed can be done,
> > or is it (according to the original poster) a requirement for the setup
> that route:default is enabled ?
>
> I think it is the system default to run 'in.routed' since otherwise it
> is possible that routing might not work out of the box in some
> network.

Thanks for this information, because I was having difficulty determining
the defaults from the manpage.


>   However, it is often not needed or actually useful so I
> think it is wise to disable this if it is not needed.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022 at 11:53 AM s...@pandora.be  wrote:

>
> There is a brief but good description at
>
>
> http://docs.openindiana.org/handbook/systems-administration/#configuring-networking

Took a cursory glance at this. I suspect NWAM is set to Automatic on my OI
machine because MATE's system tray networking icon toast message says
something like Setting profile: Automatic (I don't recall exactly) during
initial startup.

I'll check, though.

>
>
> in the section 'configuring networking' the OpenIndiana handbook discusses
> the NWAM.
>
> Specifically :
>
> "Network Auto-Magic (NWAM) is a new approach to managing network
> interfaces that was introduced with OpenSolaris. NWAM introduced network
> profiles to be able to change network settings on the fly."
>
> However the question from John D Groenveld was what the output of
> 'routeadm' was,
> and whether the service route:default was enabled.
>
> So whether you have a requirement for enabling any routing daemons and if
> not whether it helps to disable in.routed.
>
> Regards,
> David Stes
>
> - Op 12 apr 2022 om 18:48 schreef Judah Richardson
> judahrichard...@gmail.com:
>
> > On Tue, Apr 12, 2022 at 11:46 AM s...@pandora.be 
> wrote:
> >
> >>
> >> - Op 11 apr 2022 om 15:47 schreef John D Groenveld
> groenv...@acm.org:
> >>
> >> > Does disabling in.routed with routeadm(8) prevent your default
> >> > route from being disappeared?
> >> > https://illumos.org/man/8/routeadm>
> >>
> >> I also wonder why this system that becomes unreachable after a a certain
> >> uptime,
> >> runs 'in.routed'.   And indeed whether disabling in.routed can be done,
> >> or is it (according to the original poster) a requirement for the setup
> >> that route:default is enabled ?
> >>
> >> Another basic thing to verify is perhaps whether the server is running
> >> nwam ?
> >> Is svcs physical:default disabled and svcs physical:nwam enabled ?
> >
> > I've never heard of any of these. How do I check their status?
> >
> >>
> >>
> >> Regards,
> >> David Stes
> >>
> >> ___
> >> openindiana-discuss mailing list
> >> openindiana-discuss@openindiana.org
> >> https://openindiana.org/mailman/listinfo/openindiana-discuss
> >>
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Udo Grabowski (IMK)]

On 12/04/2022 19:09, Bob Friesenhahn wrote:

On Tue, 12 Apr 2022, s...@pandora.be wrote:



- Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org:


Does disabling in.routed with routeadm(8) prevent your default
route from being disappeared?
https://illumos.org/man/8/routeadm>


I also wonder why this system that becomes unreachable after a a 
certain uptime,

runs 'in.routed'.   And indeed whether disabling in.routed can be done,
or is it (according to the original poster) a requirement for the 
setup that route:default is enabled ?


I think it is the system default to run 'in.routed' 


No, it isn't, it's controlled by
/lib/svc/manifest/network/routing/route.xml ,
which is not enabled by default, as practically no machine
in the field is working as a router, you have to specifically
enable the route:default service.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Tue, 12 Apr 2022, s...@pandora.be wrote:



- Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org:


Does disabling in.routed with routeadm(8) prevent your default
route from being disappeared?
https://illumos.org/man/8/routeadm>


I also wonder why this system that becomes unreachable after a a certain uptime,
runs 'in.routed'.   And indeed whether disabling in.routed can be done,
or is it (according to the original poster) a requirement for the setup that 
route:default is enabled ?


I think it is the system default to run 'in.routed' since otherwise it 
is possible that routing might not work out of the box in some 
network.  However, it is often not needed or actually useful so I 
think it is wise to disable this if it is not needed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

There is a brief but good description at

http://docs.openindiana.org/handbook/systems-administration/#configuring-networking

in the section 'configuring networking' the OpenIndiana handbook discusses the 
NWAM.

Specifically :

"Network Auto-Magic (NWAM) is a new approach to managing network interfaces 
that was introduced with OpenSolaris. NWAM introduced network profiles to be 
able to change network settings on the fly."

However the question from John D Groenveld was what the output of 'routeadm' 
was,
and whether the service route:default was enabled.

So whether you have a requirement for enabling any routing daemons and if not 
whether it helps to disable in.routed.

Regards,
David Stes

- Op 12 apr 2022 om 18:48 schreef Judah Richardson 
judahrichard...@gmail.com:

> On Tue, Apr 12, 2022 at 11:46 AM s...@pandora.be  wrote:
> 
>>
>> - Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org:
>>
>> > Does disabling in.routed with routeadm(8) prevent your default
>> > route from being disappeared?
>> > https://illumos.org/man/8/routeadm>
>>
>> I also wonder why this system that becomes unreachable after a a certain
>> uptime,
>> runs 'in.routed'.   And indeed whether disabling in.routed can be done,
>> or is it (according to the original poster) a requirement for the setup
>> that route:default is enabled ?
>>
>> Another basic thing to verify is perhaps whether the server is running
>> nwam ?
>> Is svcs physical:default disabled and svcs physical:nwam enabled ?
> 
> I've never heard of any of these. How do I check their status?
> 
>>
>>
>> Regards,
>> David Stes
>>
>> ___
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Apr 12, 2022 at 11:46 AM s...@pandora.be  wrote:

>
> - Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org:
>
> > Does disabling in.routed with routeadm(8) prevent your default
> > route from being disappeared?
> > https://illumos.org/man/8/routeadm>
>
> I also wonder why this system that becomes unreachable after a a certain
> uptime,
> runs 'in.routed'.   And indeed whether disabling in.routed can be done,
> or is it (according to the original poster) a requirement for the setup
> that route:default is enabled ?
>
> Another basic thing to verify is perhaps whether the server is running
> nwam ?
> Is svcs physical:default disabled and svcs physical:nwam enabled ?

I've never heard of any of these. How do I check their status?

>
>
> Regards,
> David Stes
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

- Op 11 apr 2022 om 15:47 schreef John D Groenveld groenv...@acm.org:

> Does disabling in.routed with routeadm(8) prevent your default
> route from being disappeared?
> https://illumos.org/man/8/routeadm>

I also wonder why this system that becomes unreachable after a a certain uptime,
runs 'in.routed'.   And indeed whether disabling in.routed can be done,
or is it (according to the original poster) a requirement for the setup that 
route:default is enabled ?

Another basic thing to verify is perhaps whether the server is running nwam ?
Is svcs physical:default disabled and svcs physical:nwam enabled ?  

Regards,
David Stes

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Alan Coopersmith]

On 4/11/22 07:49, Bob Friesenhahn wrote:
The above only applies to how the client gets its name.  At one time I used a 
Solaris DHCP server (and it was great) but I think that server has been 
deprecated in Solaris and likely removed since then. 


Yes, Solaris 11.4 only ships the ISC DHCP server, and no longer includes the old
Sun DHCP server.

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Mon, 11 Apr 2022, Judah Richardson wrote:



Perhaps I misunderstood the documentation, so here's the verbatim quote:

"By default, the Solaris DHCP client does not supply its own host name,
because the client expects the DHCP server to supply the host name. The
Solaris DHCP server is configured to supply host names to DHCP clients by
default. When you use the Solaris DHCP client and server together, these
defaults work well. However, when you use the Solaris DHCP client with some
third-party DHCP servers, the client might not receive a host name from the
server. If the Solaris DHCP client does not receive a host name through
DHCP, the client system looks at the /etc/nodename file for a name to use
as the host name. If the file is empty, the host name is set to unknown."


The above only applies to how the client gets its name.  At one time I 
used a Solaris DHCP server (and it was great) but I think that server 
has been deprecated in Solaris and likely removed since then.  Most 
people will be using whatever DHCP server appears on their network, 
which is often a server in the IP gateway which connects to the 
Internet.


Regardless, it seems that the latest advisement is that the problem is 
that the per interface route is being removed and not that the 
interface IP is being removed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Mon, Apr 11, 2022 at 8:14 AM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Sun, 10 Apr 2022, Judah Richardson wrote:
>
> > OK. The Solaris documentation I linked to says that Solaris (and
> presumably
> > distros downstream of that codebase) expects the DHCP server to be
> another
> > Solaris machine, and so DHCP servers that don't behave like the latter
> can
> > result in unexpected behavior.
>
> The above seems to be a meaningless statement.
>
Perhaps I misunderstood the documentation, so here's the verbatim quote:

"By default, the Solaris DHCP client does not supply its own host name,
because the client expects the DHCP server to supply the host name. The
Solaris DHCP server is configured to supply host names to DHCP clients by
default. When you use the Solaris DHCP client and server together, these
defaults work well. However, when you use the Solaris DHCP client with some
third-party DHCP servers, the client might not receive a host name from the
server. If the Solaris DHCP client does not receive a host name through
DHCP, the client system looks at the /etc/nodename file for a name to use
as the host name. If the file is empty, the host name is set to unknown."

I suppose what I meant by "unexpected behavior" is "behavior different from
other client OSes the user may be accustomed to."

>
> DHCP (and its expectations) are not very complicated.
>
> I use the ISC DHCP server here, but any reasonable DHCP server should
> do.
>
> The DHCP client is expected to contact the server every so often and
> if the server fails to respond for a very long time, the DHCP lease
> will expire and the DHCP client should remove the IP address from the
> interface.
>
> However, it appears likely that the DHCP server and client are not the
> guilty parties here.  It appears that some other software, or
> something in the kernel, is removing the IP address.  The DHCP client
> expects the kernel to retain the IP address until the interface is
> turned down.  It is not going to continually check to verify that
> nothing has disturbed it.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[John D Groenveld]

In message <642ef4d2-e6d0-aa16-dabb-084f67e3f...@duedinghausen.eu>, Stephan 
Althaus writes:
>To clarify the symptoms on my machine: It is only the routing entry that 
>disappears, the IP address remains active. The lease should not be the 
>problem, as the duration is 30 days or the like..
>
>The only related message i see is this:
>
>in.routed[1174]: [ID 559541 daemon.warning] 0.0.0.0 --> 192.168.2.1 
>disappeared from kernel

Does disabling in.routed with routeadm(8) prevent your default
route from being disappeared?
https://illumos.org/man/8/routeadm>

John
groenv...@acm.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/11/22 15:14, Bob Friesenhahn wrote:

On Sun, 10 Apr 2022, Judah Richardson wrote:

OK. The Solaris documentation I linked to says that Solaris (and 
presumably
distros downstream of that codebase) expects the DHCP server to be 
another
Solaris machine, and so DHCP servers that don't behave like the 
latter can

result in unexpected behavior.


The above seems to be a meaningless statement.

DHCP (and its expectations) are not very complicated.

I use the ISC DHCP server here, but any reasonable DHCP server should do.

The DHCP client is expected to contact the server every so often and 
if the server fails to respond for a very long time, the DHCP lease 
will expire and the DHCP client should remove the IP address from the 
interface.


However, it appears likely that the DHCP server and client are not the 
guilty parties here.  It appears that some other software, or 
something in the kernel, is removing the IP address.  The DHCP client 
expects the kernel to retain the IP address until the interface is 
turned down.  It is not going to continually check to verify that 
nothing has disturbed it.


Bob


Hi!

Thanks Bob for your points!

To clarify the symptoms on my machine: It is only the routing entry that 
disappears, the IP address remains active. The lease should not be the 
problem, as the duration is 30 days or the like..


The only related message i see is this:

in.routed[1174]: [ID 559541 daemon.warning] 0.0.0.0 --> 192.168.2.1 
disappeared from kernel


Stephan


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Doug Hughes]

On 4/11/2022 9:14 AM, Bob Friesenhahn wrote:

On Sun, 10 Apr 2022, Judah Richardson wrote:

OK. The Solaris documentation I linked to says that Solaris (and 
presumably
distros downstream of that codebase) expects the DHCP server to be 
another
Solaris machine, and so DHCP servers that don't behave like the 
latter can

result in unexpected behavior.


The above seems to be a meaningless statement.

DHCP (and its expectations) are not very complicated.

I use the ISC DHCP server here, but any reasonable DHCP server should do.

The DHCP client is expected to contact the server every so often and 
if the server fails to respond for a very long time, the DHCP lease 
will expire and the DHCP client should remove the IP address from the 
interface.


However, it appears likely that the DHCP server and client are not the 
guilty parties here.  It appears that some other software, or 
something in the kernel, is removing the IP address.  The DHCP client 
expects the kernel to retain the IP address until the interface is 
turned down.  It is not going to continually check to verify that 
nothing has disturbed it.


Bob


Just a thought:

Maybe that doc (which I didn't chase down since it fell off of thread) 
is referencing the fact that there are special tags used for jumpstart 
server, image server, image name, etc. That's all I could think off: if 
you are trying to jumpstart a machine. And yeah, those tags do have to 
exist, but you can put them on an isc or any other dhcp server too. It's 
all just a matter of what the client is asking for and what the server 
replies with, the specifics of the OS don't matter, frankly. From a pure 
IP request/renew/accept point of view, the protocol is the same.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Sun, 10 Apr 2022, Judah Richardson wrote:


OK. The Solaris documentation I linked to says that Solaris (and presumably
distros downstream of that codebase) expects the DHCP server to be another
Solaris machine, and so DHCP servers that don't behave like the latter can
result in unexpected behavior.


The above seems to be a meaningless statement.

DHCP (and its expectations) are not very complicated.

I use the ISC DHCP server here, but any reasonable DHCP server should 
do.


The DHCP client is expected to contact the server every so often and 
if the server fails to respond for a very long time, the DHCP lease 
will expire and the DHCP client should remove the IP address from the 
interface.


However, it appears likely that the DHCP server and client are not the 
guilty parties here.  It appears that some other software, or 
something in the kernel, is removing the IP address.  The DHCP client 
expects the kernel to retain the IP address until the interface is 
turned down.  It is not going to continually check to verify that 
nothing has disturbed it.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Bob Friesenhahn]

On Sun, 10 Apr 2022, Stephan Althaus wrote:


I have those messages, too.

$ dmesg |grep "0.0.0.0"
Apr 10 14:40:33 dell6510 in.routed[1035]: [ID 749644 daemon.notice] e1000g4 
has a bad address 0.0.0.0


Did you intend to run a RIP routing daemon?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

OK. The Solaris documentation I linked to says that Solaris (and presumably
distros downstream of that codebase) expects the DHCP server to be another
Solaris machine, and so DHCP servers that don't behave like the latter can
result in unexpected behavior.

On Sun, Apr 10, 2022 at 3:13 PM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:

> On 4/10/22 22:10, Judah Richardson wrote:
> > On Sun, Apr 10, 2022 at 3:07 PM Stephan Althaus <
> > stephan.alth...@duedinghausen.eu> wrote:
> >
> >> On 4/10/22 19:56, Judah Richardson wrote:
> >>> Update: I still get the same 0.0.0.0 messages on reboot:
> >>>
> >>> $ dmesg | grep 0.0.0.0
> >>> Apr 10 12:36:58 DellOptiPlex390MT in.routed[562]: [ID 749644
> >> daemon.notice]
> >>> rge0 has a bad address 0.0.0.0
> >>> Apr 10 12:37:03 DellOptiPlex390MT in.routed[562]: [ID 464608
> >> daemon.error]
> >>> route 0.0.0.0/24 --> 0.0.0.0 nexthop is not directly connected
> >>>
> >>> But as before, the machine acquires the proper IP address once the DE
> >>> starts. We'll see if connectivity fails again ... usually takes 5 to 14
> >>> days to happen.
> >>>
> >>> On Sun, Apr 10, 2022 at 12:47 PM Judah Richardson <
> >> judahrichard...@gmail.com>
> >>> wrote:
> >>>
>  I do notice 0.0.0.0 error messages in the onscreen messages displayed
> at
>  boot, but when the DE launches the status bar popup shows a proper IP
>  address acquisition.
> 
>  Does your machine have a static IP address?
> 
>  FWIW I remembered a Reddit thread
>  <
> >>
> https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/
>  about a similar (related?) OI issue
>   I was having. Someone
>  replied
>  <
> >>
> https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/fl9bdoc/
>  with a solution
>  
> >> that
>  I'd totally forgotten to try because I'd been able to work around the
>  original issue. I implemented the suggested fix just now and did #
> >> reboot.
>  Fingers crossed.
> 
>  On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
>  stephan.alth...@duedinghausen.eu> wrote:
> 
> > On 4/10/22 09:38, Stephan Althaus wrote:
> >> On 4/10/22 04:13, Judah Richardson wrote:
> >>> Finally got around to looking into this ongoing issue.
> >>>
> >>> On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson
> >>> 
> >>> wrote:
> >>>
>  On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be  >
>  wrote:
> 
> > Do you still have access to a console when the system is
> > 'unreachable'
> > over the network ?
> >
>  Yes, I do.
> 
> > If you still have a text console on the system which became
> > unreachable,
> > perhaps you could check before rebooting whether you can see any
> > errors on
> > the NIC.
> >
> > For example using:
> >
> > # dladm show-link -s rge0
> >
> > When I run the above command on system with a e1000g0 interface,
> it
> > prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
> > hopefully
> > it also prints those statistics for rge0.
> >
>  Doesn't show any errors on this end.
> > Also maybe there are error messages in the /var/adm/messages
> > related to
> > rge0.
> >
>  No errors there either.
> >>> Seems to be a problem within the OS itself, perhaps in relation to
> >> that
> >>> particular NIC.
> >>>
> >>>
>  These are good ideas, thanks. I'll try them next time it happens
> and
>  then
>  report back.
> 
> > Regards,
> > David Stes
> >
> > - Op 22 dec 2021 om 8:56 schreef Judah Richardson
> > judahrichard...@gmail.com:
> >
> >> On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow <
> j...@sysmgr.org
> > wrote:
> >>> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
> >>>  wrote:
>  On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
> >>> openindiana-discuss 
> wrote:
> >> Any logs or anything like that in particular I should take a
> > look
> > at?
> > What driver is in use?
>  How do I determine this?
> >>> What do you see in "ipadm show-addr"
> >> $ sudo ipadm show-addr
> >> Password:
> >> ADDROBJ   TYPE STATEADDR
> >> lo0/v4static   ok   127.0.0.1/8
> >> rge0/_b   dhcp ok   192.168.0.71/24
> >> lo0/v6static   ok   ::1/128
> >> rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10
> >>
> >> and "dladm 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/10/22 22:10, Judah Richardson wrote:

On Sun, Apr 10, 2022 at 3:07 PM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:


On 4/10/22 19:56, Judah Richardson wrote:

Update: I still get the same 0.0.0.0 messages on reboot:

$ dmesg | grep 0.0.0.0
Apr 10 12:36:58 DellOptiPlex390MT in.routed[562]: [ID 749644

daemon.notice]

rge0 has a bad address 0.0.0.0
Apr 10 12:37:03 DellOptiPlex390MT in.routed[562]: [ID 464608

daemon.error]

route 0.0.0.0/24 --> 0.0.0.0 nexthop is not directly connected

But as before, the machine acquires the proper IP address once the DE
starts. We'll see if connectivity fails again ... usually takes 5 to 14
days to happen.

On Sun, Apr 10, 2022 at 12:47 PM Judah Richardson <

judahrichard...@gmail.com>

wrote:


I do notice 0.0.0.0 error messages in the onscreen messages displayed at
boot, but when the DE launches the status bar popup shows a proper IP
address acquisition.

Does your machine have a static IP address?

FWIW I remembered a Reddit thread
<

https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/

about a similar (related?) OI issue
 I was having. Someone
replied
<

https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/fl9bdoc/

with a solution


that

I'd totally forgotten to try because I'd been able to work around the
original issue. I implemented the suggested fix just now and did #

reboot.

Fingers crossed.

On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:


On 4/10/22 09:38, Stephan Althaus wrote:

On 4/10/22 04:13, Judah Richardson wrote:

Finally got around to looking into this ongoing issue.

On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson

wrote:


On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be 
wrote:


Do you still have access to a console when the system is

'unreachable'

over the network ?


Yes, I do.


If you still have a text console on the system which became
unreachable,
perhaps you could check before rebooting whether you can see any
errors on
the NIC.

For example using:

# dladm show-link -s rge0

When I run the above command on system with a e1000g0 interface, it
prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
hopefully
it also prints those statistics for rge0.


Doesn't show any errors on this end.

Also maybe there are error messages in the /var/adm/messages
related to
rge0.


No errors there either.

Seems to be a problem within the OS itself, perhaps in relation to

that

particular NIC.



These are good ideas, thanks. I'll try them next time it happens and
then
report back.


Regards,
David Stes

- Op 22 dec 2021 om 8:56 schreef Judah Richardson
judahrichard...@gmail.com:


On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 
wrote:

On Mon, 20 Dec 2021 at 22:26, Judah Richardson
 wrote:

On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via

openindiana-discuss  wrote:

Any logs or anything like that in particular I should take a

look

at?

What driver is in use?

How do I determine this?

What do you see in "ipadm show-addr"

$ sudo ipadm show-addr
Password:
ADDROBJ   TYPE STATEADDR
lo0/v4static   ok   127.0.0.1/8
rge0/_b   dhcp ok   192.168.0.71/24
lo0/v6static   ok   ::1/128
rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10

and "dladm show-ether"?

~$ sudo dladm show-ether
LINKPTYPESTATEAUTO  SPEED-DUPLEX
PAUSE
rge0current  up   no1G-f

none

By

default, NICs are named with the driver you're using; e.g.,
"bge0" is
an instance of the "bge" driver.


What model of NIC is it?

It's an onboard Realtek NIC.

If you "pkg install diagnostic/pci" you should be able to:

   /usr/lib/pci/pcieadm show-devs -o
bdf,vid,did,driver,vendor,device


$ sudo /usr/lib/pci/pcieadm show-devs -o

bdf,vid,did,driver,vendor,device

BDF VID   DID   DRIVER VENDORDEVICE
0/0/0   8086  100   -- Intel Corporation

  2nd

Generation Core Processor Family DRAM Controller
0/2/0   8086  102   i9150  Intel Corporation

  2nd

Generation Core Processor Family Integrated Graphics Controller
0/16/0  8086  1c3a  -- Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1
0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #2
0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
Series/C200 Series Chipset Family High Definition Audio Controller
0/1c/0  8086  1c10  -- Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 1
0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 3
0/1c/4  8086  

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Sun, Apr 10, 2022 at 3:07 PM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:

> On 4/10/22 19:56, Judah Richardson wrote:
> > Update: I still get the same 0.0.0.0 messages on reboot:
> >
> > $ dmesg | grep 0.0.0.0
> > Apr 10 12:36:58 DellOptiPlex390MT in.routed[562]: [ID 749644
> daemon.notice]
> > rge0 has a bad address 0.0.0.0
> > Apr 10 12:37:03 DellOptiPlex390MT in.routed[562]: [ID 464608
> daemon.error]
> > route 0.0.0.0/24 --> 0.0.0.0 nexthop is not directly connected
> >
> > But as before, the machine acquires the proper IP address once the DE
> > starts. We'll see if connectivity fails again ... usually takes 5 to 14
> > days to happen.
> >
> > On Sun, Apr 10, 2022 at 12:47 PM Judah Richardson <
> judahrichard...@gmail.com>
> > wrote:
> >
> >> I do notice 0.0.0.0 error messages in the onscreen messages displayed at
> >> boot, but when the DE launches the status bar popup shows a proper IP
> >> address acquisition.
> >>
> >> Does your machine have a static IP address?
> >>
> >> FWIW I remembered a Reddit thread
> >> <
> https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/
> >
> >> about a similar (related?) OI issue
> >>  I was having. Someone
> >> replied
> >> <
> https://www.reddit.com/r/illumos/comments/fndxp7/openindiana_hipster_machine_responds_to_ip/fl9bdoc/
> >
> >> with a solution
> >> 
> that
> >> I'd totally forgotten to try because I'd been able to work around the
> >> original issue. I implemented the suggested fix just now and did #
> reboot.
> >> Fingers crossed.
> >>
> >> On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
> >> stephan.alth...@duedinghausen.eu> wrote:
> >>
> >>> On 4/10/22 09:38, Stephan Althaus wrote:
>  On 4/10/22 04:13, Judah Richardson wrote:
> > Finally got around to looking into this ongoing issue.
> >
> > On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson
> > 
> > wrote:
> >
> >> On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be 
> >> wrote:
> >>
> >>> Do you still have access to a console when the system is
> >>> 'unreachable'
> >>> over the network ?
> >>>
> >> Yes, I do.
> >>
> >>> If you still have a text console on the system which became
> >>> unreachable,
> >>> perhaps you could check before rebooting whether you can see any
> >>> errors on
> >>> the NIC.
> >>>
> >>> For example using:
> >>>
> >>> # dladm show-link -s rge0
> >>>
> >>> When I run the above command on system with a e1000g0 interface, it
> >>> prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
> >>> hopefully
> >>> it also prints those statistics for rge0.
> >>>
> >> Doesn't show any errors on this end.
> >>> Also maybe there are error messages in the /var/adm/messages
> >>> related to
> >>> rge0.
> >>>
> >> No errors there either.
> > Seems to be a problem within the OS itself, perhaps in relation to
> that
> > particular NIC.
> >
> >
> >> These are good ideas, thanks. I'll try them next time it happens and
> >> then
> >> report back.
> >>
> >>> Regards,
> >>> David Stes
> >>>
> >>> - Op 22 dec 2021 om 8:56 schreef Judah Richardson
> >>> judahrichard...@gmail.com:
> >>>
>  On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow  >
> >>> wrote:
> > On Mon, 20 Dec 2021 at 22:26, Judah Richardson
> >  wrote:
> >> On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
> > openindiana-discuss  wrote:
>  Any logs or anything like that in particular I should take a
> >>> look
> >>> at?
> >>> What driver is in use?
> >> How do I determine this?
> > What do you see in "ipadm show-addr"
>  $ sudo ipadm show-addr
>  Password:
>  ADDROBJ   TYPE STATEADDR
>  lo0/v4static   ok   127.0.0.1/8
>  rge0/_b   dhcp ok   192.168.0.71/24
>  lo0/v6static   ok   ::1/128
>  rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10
> 
>  and "dladm show-ether"?
> 
>  ~$ sudo dladm show-ether
>  LINKPTYPESTATEAUTO  SPEED-DUPLEX
>  PAUSE
>  rge0current  up   no1G-f
> >>> none
> By
> > default, NICs are named with the driver you're using; e.g.,
> > "bge0" is
> > an instance of the "bge" driver.
> >
> >>> What model of NIC is it?
> >> It's an onboard Realtek NIC.
> > If you "pkg install diagnostic/pci" you should be able to:
> >
> >   /usr/lib/pci/pcieadm show-devs -o
> > bdf,vid,did,driver,vendor,device
> >
>  $ sudo 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/10/22 19:56, Judah Richardson wrote:

Update: I still get the same 0.0.0.0 messages on reboot:

$ dmesg | grep 0.0.0.0
Apr 10 12:36:58 DellOptiPlex390MT in.routed[562]: [ID 749644 daemon.notice]
rge0 has a bad address 0.0.0.0
Apr 10 12:37:03 DellOptiPlex390MT in.routed[562]: [ID 464608 daemon.error]
route 0.0.0.0/24 --> 0.0.0.0 nexthop is not directly connected

But as before, the machine acquires the proper IP address once the DE
starts. We'll see if connectivity fails again ... usually takes 5 to 14
days to happen.

On Sun, Apr 10, 2022 at 12:47 PM Judah Richardson 
wrote:


I do notice 0.0.0.0 error messages in the onscreen messages displayed at
boot, but when the DE launches the status bar popup shows a proper IP
address acquisition.

Does your machine have a static IP address?

FWIW I remembered a Reddit thread

about a similar (related?) OI issue
 I was having. Someone
replied

with a solution
 that
I'd totally forgotten to try because I'd been able to work around the
original issue. I implemented the suggested fix just now and did # reboot.
Fingers crossed.

On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:


On 4/10/22 09:38, Stephan Althaus wrote:

On 4/10/22 04:13, Judah Richardson wrote:

Finally got around to looking into this ongoing issue.

On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson

wrote:


On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be 
wrote:


Do you still have access to a console when the system is

'unreachable'

over the network ?


Yes, I do.


If you still have a text console on the system which became
unreachable,
perhaps you could check before rebooting whether you can see any
errors on
the NIC.

For example using:

# dladm show-link -s rge0

When I run the above command on system with a e1000g0 interface, it
prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
hopefully
it also prints those statistics for rge0.


Doesn't show any errors on this end.

Also maybe there are error messages in the /var/adm/messages
related to
rge0.


No errors there either.

Seems to be a problem within the OS itself, perhaps in relation to that
particular NIC.



These are good ideas, thanks. I'll try them next time it happens and
then
report back.


Regards,
David Stes

- Op 22 dec 2021 om 8:56 schreef Judah Richardson
judahrichard...@gmail.com:


On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 

wrote:

On Mon, 20 Dec 2021 at 22:26, Judah Richardson
 wrote:

On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via

openindiana-discuss  wrote:

Any logs or anything like that in particular I should take a

look

at?

What driver is in use?

How do I determine this?

What do you see in "ipadm show-addr"

$ sudo ipadm show-addr
Password:
ADDROBJ   TYPE STATEADDR
lo0/v4static   ok   127.0.0.1/8
rge0/_b   dhcp ok   192.168.0.71/24
lo0/v6static   ok   ::1/128
rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10

and "dladm show-ether"?

~$ sudo dladm show-ether
LINKPTYPESTATEAUTO  SPEED-DUPLEX
PAUSE
rge0current  up   no1G-f

none

   By

default, NICs are named with the driver you're using; e.g.,
"bge0" is
an instance of the "bge" driver.


What model of NIC is it?

It's an onboard Realtek NIC.

If you "pkg install diagnostic/pci" you should be able to:

  /usr/lib/pci/pcieadm show-devs -o
bdf,vid,did,driver,vendor,device


$ sudo /usr/lib/pci/pcieadm show-devs -o

bdf,vid,did,driver,vendor,device

BDF VID   DID   DRIVER VENDORDEVICE
0/0/0   8086  100   -- Intel Corporation 2nd
Generation Core Processor Family DRAM Controller
0/2/0   8086  102   i9150  Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller
0/16/0  8086  1c3a  -- Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1
0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #2
0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
Series/C200 Series Chipset Family High Definition Audio Controller
0/1c/0  8086  1c10  -- Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 1
0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 3
0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 5
3/0/0   10ec  8168  rge0   Realtek 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

Update: I still get the same 0.0.0.0 messages on reboot:

$ dmesg | grep 0.0.0.0
Apr 10 12:36:58 DellOptiPlex390MT in.routed[562]: [ID 749644 daemon.notice]
rge0 has a bad address 0.0.0.0
Apr 10 12:37:03 DellOptiPlex390MT in.routed[562]: [ID 464608 daemon.error]
route 0.0.0.0/24 --> 0.0.0.0 nexthop is not directly connected

But as before, the machine acquires the proper IP address once the DE
starts. We'll see if connectivity fails again ... usually takes 5 to 14
days to happen.

On Sun, Apr 10, 2022 at 12:47 PM Judah Richardson 
wrote:

> I do notice 0.0.0.0 error messages in the onscreen messages displayed at
> boot, but when the DE launches the status bar popup shows a proper IP
> address acquisition.
>
> Does your machine have a static IP address?
>
> FWIW I remembered a Reddit thread
> 
> about a similar (related?) OI issue
>  I was having. Someone
> replied
> 
> with a solution
>  that
> I'd totally forgotten to try because I'd been able to work around the
> original issue. I implemented the suggested fix just now and did # reboot.
> Fingers crossed.
>
> On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
> stephan.alth...@duedinghausen.eu> wrote:
>
>> On 4/10/22 09:38, Stephan Althaus wrote:
>> > On 4/10/22 04:13, Judah Richardson wrote:
>> >> Finally got around to looking into this ongoing issue.
>> >>
>> >> On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson
>> >> 
>> >> wrote:
>> >>
>> >>>
>> >>> On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be 
>> >>> wrote:
>> >>>
>>  Do you still have access to a console when the system is
>> 'unreachable'
>>  over the network ?
>> 
>> >>> Yes, I do.
>> >>>
>>  If you still have a text console on the system which became
>>  unreachable,
>>  perhaps you could check before rebooting whether you can see any
>>  errors on
>>  the NIC.
>> 
>>  For example using:
>> 
>>  # dladm show-link -s rge0
>> 
>>  When I run the above command on system with a e1000g0 interface, it
>>  prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
>>  hopefully
>>  it also prints those statistics for rge0.
>> 
>> >>> Doesn't show any errors on this end.
>>  Also maybe there are error messages in the /var/adm/messages
>>  related to
>>  rge0.
>> 
>> >>> No errors there either.
>> >> Seems to be a problem within the OS itself, perhaps in relation to that
>> >> particular NIC.
>> >>
>> >>
>> >>> These are good ideas, thanks. I'll try them next time it happens and
>> >>> then
>> >>> report back.
>> >>>
>> 
>>  Regards,
>>  David Stes
>> 
>>  - Op 22 dec 2021 om 8:56 schreef Judah Richardson
>>  judahrichard...@gmail.com:
>> 
>> > On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 
>>  wrote:
>> >> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
>> >>  wrote:
>> >>> On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
>> >> openindiana-discuss  wrote:
>> > Any logs or anything like that in particular I should take a
>> look
>>  at?
>>  What driver is in use?
>> >>> How do I determine this?
>> >> What do you see in "ipadm show-addr"
>> > $ sudo ipadm show-addr
>> > Password:
>> > ADDROBJ   TYPE STATEADDR
>> > lo0/v4static   ok   127.0.0.1/8
>> > rge0/_b   dhcp ok   192.168.0.71/24
>> > lo0/v6static   ok   ::1/128
>> > rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10
>> >
>> > and "dladm show-ether"?
>> >
>> > ~$ sudo dladm show-ether
>> > LINKPTYPESTATEAUTO  SPEED-DUPLEX
>> > PAUSE
>> > rge0current  up   no1G-f
>>  none
>> >   By
>> >> default, NICs are named with the driver you're using; e.g.,
>> >> "bge0" is
>> >> an instance of the "bge" driver.
>> >>
>>  What model of NIC is it?
>> >>> It's an onboard Realtek NIC.
>> >> If you "pkg install diagnostic/pci" you should be able to:
>> >>
>> >>  /usr/lib/pci/pcieadm show-devs -o
>> >> bdf,vid,did,driver,vendor,device
>> >>
>> > $ sudo /usr/lib/pci/pcieadm show-devs -o
>>  bdf,vid,did,driver,vendor,device
>> > BDF VID   DID   DRIVER VENDORDEVICE
>> > 0/0/0   8086  100   -- Intel Corporation 2nd
>> > Generation Core Processor Family DRAM Controller
>> > 0/2/0   8086  102   i9150  Intel Corporation 2nd
>> > Generation Core Processor Family Integrated Graphics Controller
>> > 0/16/0  8086  1c3a  -- Intel Corporation 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

I do notice 0.0.0.0 error messages in the onscreen messages displayed at
boot, but when the DE launches the status bar popup shows a proper IP
address acquisition.

Does your machine have a static IP address?

FWIW I remembered a Reddit thread

about a similar (related?) OI issue
 I was having. Someone replied

with a solution
 that
I'd totally forgotten to try because I'd been able to work around the
original issue. I implemented the suggested fix just now and did # reboot.
Fingers crossed.

On Sun, Apr 10, 2022 at 7:57 AM Stephan Althaus <
stephan.alth...@duedinghausen.eu> wrote:

> On 4/10/22 09:38, Stephan Althaus wrote:
> > On 4/10/22 04:13, Judah Richardson wrote:
> >> Finally got around to looking into this ongoing issue.
> >>
> >> On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson
> >> 
> >> wrote:
> >>
> >>>
> >>> On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be 
> >>> wrote:
> >>>
>  Do you still have access to a console when the system is 'unreachable'
>  over the network ?
> 
> >>> Yes, I do.
> >>>
>  If you still have a text console on the system which became
>  unreachable,
>  perhaps you could check before rebooting whether you can see any
>  errors on
>  the NIC.
> 
>  For example using:
> 
>  # dladm show-link -s rge0
> 
>  When I run the above command on system with a e1000g0 interface, it
>  prints IERRORS / OERRORS in the show-link -s e1000g0 output, so
>  hopefully
>  it also prints those statistics for rge0.
> 
> >>> Doesn't show any errors on this end.
>  Also maybe there are error messages in the /var/adm/messages
>  related to
>  rge0.
> 
> >>> No errors there either.
> >> Seems to be a problem within the OS itself, perhaps in relation to that
> >> particular NIC.
> >>
> >>
> >>> These are good ideas, thanks. I'll try them next time it happens and
> >>> then
> >>> report back.
> >>>
> 
>  Regards,
>  David Stes
> 
>  - Op 22 dec 2021 om 8:56 schreef Judah Richardson
>  judahrichard...@gmail.com:
> 
> > On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 
>  wrote:
> >> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
> >>  wrote:
> >>> On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
> >> openindiana-discuss  wrote:
> > Any logs or anything like that in particular I should take a look
>  at?
>  What driver is in use?
> >>> How do I determine this?
> >> What do you see in "ipadm show-addr"
> > $ sudo ipadm show-addr
> > Password:
> > ADDROBJ   TYPE STATEADDR
> > lo0/v4static   ok   127.0.0.1/8
> > rge0/_b   dhcp ok   192.168.0.71/24
> > lo0/v6static   ok   ::1/128
> > rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10
> >
> > and "dladm show-ether"?
> >
> > ~$ sudo dladm show-ether
> > LINKPTYPESTATEAUTO  SPEED-DUPLEX
> > PAUSE
> > rge0current  up   no1G-f
>  none
> >   By
> >> default, NICs are named with the driver you're using; e.g.,
> >> "bge0" is
> >> an instance of the "bge" driver.
> >>
>  What model of NIC is it?
> >>> It's an onboard Realtek NIC.
> >> If you "pkg install diagnostic/pci" you should be able to:
> >>
> >>  /usr/lib/pci/pcieadm show-devs -o
> >> bdf,vid,did,driver,vendor,device
> >>
> > $ sudo /usr/lib/pci/pcieadm show-devs -o
>  bdf,vid,did,driver,vendor,device
> > BDF VID   DID   DRIVER VENDORDEVICE
> > 0/0/0   8086  100   -- Intel Corporation 2nd
> > Generation Core Processor Family DRAM Controller
> > 0/2/0   8086  102   i9150  Intel Corporation 2nd
> > Generation Core Processor Family Integrated Graphics Controller
> > 0/16/0  8086  1c3a  -- Intel Corporation 6
> > Series/C200 Series Chipset Family MEI Controller #1
> > 0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
> > Series/C200 Series Chipset Family USB Enhanced Host Controller #2
> > 0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
> > Series/C200 Series Chipset Family High Definition Audio Controller
> > 0/1c/0  8086  1c10  -- Intel Corporation 6
> > Series/C200 Series Chipset Family PCI Express Root Port 1
> > 0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
> > Series/C200 Series Chipset Family PCI Express Root Port 3
> > 0/1c/4  8086  1c18  

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/10/22 09:38, Stephan Althaus wrote:

On 4/10/22 04:13, Judah Richardson wrote:

Finally got around to looking into this ongoing issue.

On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson 


wrote:



On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be  
wrote:



Do you still have access to a console when the system is 'unreachable'
over the network ?


Yes, I do.

If you still have a text console on the system which became 
unreachable,
perhaps you could check before rebooting whether you can see any 
errors on

the NIC.

For example using:

# dladm show-link -s rge0

When I run the above command on system with a e1000g0 interface, it
prints IERRORS / OERRORS in the show-link -s e1000g0 output, so 
hopefully

it also prints those statistics for rge0.


Doesn't show any errors on this end.
Also maybe there are error messages in the /var/adm/messages 
related to

rge0.


No errors there either.

Seems to be a problem within the OS itself, perhaps in relation to that
particular NIC.


These are good ideas, thanks. I'll try them next time it happens and 
then

report back.



Regards,
David Stes

- Op 22 dec 2021 om 8:56 schreef Judah Richardson
judahrichard...@gmail.com:


On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 

wrote:

On Mon, 20 Dec 2021 at 22:26, Judah Richardson
 wrote:

On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via

openindiana-discuss  wrote:

Any logs or anything like that in particular I should take a look

at?

What driver is in use?

How do I determine this?

What do you see in "ipadm show-addr"

$ sudo ipadm show-addr
Password:
ADDROBJ   TYPE STATE    ADDR
lo0/v4    static   ok   127.0.0.1/8
rge0/_b   dhcp ok   192.168.0.71/24
lo0/v6    static   ok   ::1/128
rge0/_a   addrconf ok fe80::7a45:c4ff:fe14:10a4/10

and "dladm show-ether"?

~$ sudo dladm show-ether
LINK    PTYPE    STATE    AUTO  SPEED-DUPLEX
PAUSE
rge0    current  up   no    1G-f

none

  By
default, NICs are named with the driver you're using; e.g., 
"bge0" is

an instance of the "bge" driver.


What model of NIC is it?

It's an onboard Realtek NIC.

If you "pkg install diagnostic/pci" you should be able to:

 /usr/lib/pci/pcieadm show-devs -o 
bdf,vid,did,driver,vendor,device



$ sudo /usr/lib/pci/pcieadm show-devs -o

bdf,vid,did,driver,vendor,device

BDF VID   DID   DRIVER VENDOR    DEVICE
0/0/0   8086  100   -- Intel Corporation 2nd
Generation Core Processor Family DRAM Controller
0/2/0   8086  102   i9150  Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller
0/16/0  8086  1c3a  -- Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1
0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #2
0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
Series/C200 Series Chipset Family High Definition Audio Controller
0/1c/0  8086  1c10  -- Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 1
0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 3
0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 5
3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
0/1d/0  8086  1c26  ehci1  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #1
0/1f/0  8086  1c5c  isa0   Intel Corporation H61
Express Chipset LPC Controller
0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,

ports

0-3)
0/1f/3  8086  1c22  -- Intel Corporation 6
Series/C200 Series Chipset Family SMBus Controller
0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,

ports

4-5)



e.g., I can see, on one of my systems:

    0/1f/6  8086  15b7  e1000g0    Intel Corporation
Ethernet Connection (2) I219-LM


Cheers.

--
Joshua M. Clulow
http://blog.sysmgr.org


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Hi!

The last few weeks i had 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 4/10/22 04:13, Judah Richardson wrote:

Finally got around to looking into this ongoing issue.

On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson 
wrote:



On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be  wrote:


Do you still have access to a console when the system is 'unreachable'
over the network ?


Yes, I do.


If you still have a text console on the system which became unreachable,
perhaps you could check before rebooting whether you can see any errors on
the NIC.

For example using:

# dladm show-link -s rge0

When I run the above command on system with a e1000g0 interface, it
prints IERRORS / OERRORS in the show-link -s e1000g0 output, so hopefully
it also prints those statistics for rge0.


Doesn't show any errors on this end.

Also maybe there are error messages in the /var/adm/messages related to
rge0.


No errors there either.

Seems to be a problem within the OS itself, perhaps in relation to that
particular NIC.



These are good ideas, thanks. I'll try them next time it happens and then
report back.



Regards,
David Stes

- Op 22 dec 2021 om 8:56 schreef Judah Richardson
judahrichard...@gmail.com:


On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 

wrote:

On Mon, 20 Dec 2021 at 22:26, Judah Richardson
 wrote:

On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via

openindiana-discuss  wrote:

Any logs or anything like that in particular I should take a look

at?

What driver is in use?

How do I determine this?

What do you see in "ipadm show-addr"

$ sudo ipadm show-addr
Password:
ADDROBJ   TYPE STATEADDR
lo0/v4static   ok   127.0.0.1/8
rge0/_b   dhcp ok   192.168.0.71/24
lo0/v6static   ok   ::1/128
rge0/_a   addrconf ok   fe80::7a45:c4ff:fe14:10a4/10

and "dladm show-ether"?

~$ sudo dladm show-ether
LINKPTYPESTATEAUTO  SPEED-DUPLEX
PAUSE
rge0current  up   no1G-f

none

  By

default, NICs are named with the driver you're using; e.g., "bge0" is
an instance of the "bge" driver.


What model of NIC is it?

It's an onboard Realtek NIC.

If you "pkg install diagnostic/pci" you should be able to:

 /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device


$ sudo /usr/lib/pci/pcieadm show-devs -o

bdf,vid,did,driver,vendor,device

BDF VID   DID   DRIVER VENDORDEVICE
0/0/0   8086  100   -- Intel Corporation 2nd
Generation Core Processor Family DRAM Controller
0/2/0   8086  102   i9150  Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller
0/16/0  8086  1c3a  -- Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1
0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #2
0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
Series/C200 Series Chipset Family High Definition Audio Controller
0/1c/0  8086  1c10  -- Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 1
0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 3
0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 5
3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
0/1d/0  8086  1c26  ehci1  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #1
0/1f/0  8086  1c5c  isa0   Intel Corporation H61
Express Chipset LPC Controller
0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,

ports

0-3)
0/1f/3  8086  1c22  -- Intel Corporation 6
Series/C200 Series Chipset Family SMBus Controller
0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,

ports

4-5)



e.g., I can see, on one of my systems:

0/1f/6  8086  15b7  e1000g0Intel Corporation
Ethernet Connection (2) I219-LM


Cheers.

--
Joshua M. Clulow
http://blog.sysmgr.org


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Hi!

The last few weeks i had some related symptom, that my 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

Finally got around to looking into this ongoing issue.

On Thu, Dec 23, 2021 at 2:28 PM Judah Richardson 
wrote:

>
>
> On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be  wrote:
>
>> Do you still have access to a console when the system is 'unreachable'
>> over the network ?
>>
> Yes, I do.
>
>>
>> If you still have a text console on the system which became unreachable,
>> perhaps you could check before rebooting whether you can see any errors on
>> the NIC.
>>
>> For example using:
>>
>> # dladm show-link -s rge0
>>
>> When I run the above command on system with a e1000g0 interface, it
>> prints IERRORS / OERRORS in the show-link -s e1000g0 output, so hopefully
>> it also prints those statistics for rge0.
>>
> Doesn't show any errors on this end.

>
>> Also maybe there are error messages in the /var/adm/messages related to
>> rge0.
>>
> No errors there either.

Seems to be a problem within the OS itself, perhaps in relation to that
particular NIC.


> These are good ideas, thanks. I'll try them next time it happens and then
> report back.
>
>>
>>
>> Regards,
>> David Stes
>>
>> - Op 22 dec 2021 om 8:56 schreef Judah Richardson
>> judahrichard...@gmail.com:
>>
>> > On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 
>> wrote:
>> >
>> >> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
>> >>  wrote:
>> >> > On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
>> >> openindiana-discuss  wrote:
>> >> >> > Any logs or anything like that in particular I should take a look
>> at?
>> >> >> What driver is in use?
>> >> > How do I determine this?
>> >>
>> >> What do you see in "ipadm show-addr"
>> >
>> > $ sudo ipadm show-addr
>> > Password:
>> > ADDROBJ   TYPE STATEADDR
>> > lo0/v4static   ok   127.0.0.1/8
>> > rge0/_b   dhcp ok   192.168.0.71/24
>> > lo0/v6static   ok   ::1/128
>> > rge0/_a   addrconf ok   fe80::7a45:c4ff:fe14:10a4/10
>> >
>> > and "dladm show-ether"?
>> >
>> > ~$ sudo dladm show-ether
>> > LINKPTYPESTATEAUTO  SPEED-DUPLEX
>> > PAUSE
>> > rge0current  up   no1G-f
>> none
>> >
>> >  By
>> >> default, NICs are named with the driver you're using; e.g., "bge0" is
>> >> an instance of the "bge" driver.
>> >>
>> >> >> What model of NIC is it?
>> >> >
>> >> > It's an onboard Realtek NIC.
>> >>
>> >> If you "pkg install diagnostic/pci" you should be able to:
>> >>
>> >> /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
>> >>
>> > $ sudo /usr/lib/pci/pcieadm show-devs -o
>> bdf,vid,did,driver,vendor,device
>> > BDF VID   DID   DRIVER VENDORDEVICE
>> > 0/0/0   8086  100   -- Intel Corporation 2nd
>> > Generation Core Processor Family DRAM Controller
>> > 0/2/0   8086  102   i9150  Intel Corporation 2nd
>> > Generation Core Processor Family Integrated Graphics Controller
>> > 0/16/0  8086  1c3a  -- Intel Corporation 6
>> > Series/C200 Series Chipset Family MEI Controller #1
>> > 0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
>> > Series/C200 Series Chipset Family USB Enhanced Host Controller #2
>> > 0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
>> > Series/C200 Series Chipset Family High Definition Audio Controller
>> > 0/1c/0  8086  1c10  -- Intel Corporation 6
>> > Series/C200 Series Chipset Family PCI Express Root Port 1
>> > 0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
>> > Series/C200 Series Chipset Family PCI Express Root Port 3
>> > 0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
>> > Series/C200 Series Chipset Family PCI Express Root Port 5
>> > 3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
>> > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>> > 0/1d/0  8086  1c26  ehci1  Intel Corporation 6
>> > Series/C200 Series Chipset Family USB Enhanced Host Controller #1
>> > 0/1f/0  8086  1c5c  isa0   Intel Corporation H61
>> > Express Chipset LPC Controller
>> > 0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
>> > Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,
>> ports
>> > 0-3)
>> > 0/1f/3  8086  1c22  -- Intel Corporation 6
>> > Series/C200 Series Chipset Family SMBus Controller
>> > 0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
>> > Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,
>> ports
>> > 4-5)
>> >
>> >
>> >>
>> >> e.g., I can see, on one of my systems:
>> >>
>> >>0/1f/6  8086  15b7  e1000g0Intel Corporation
>> >> Ethernet Connection (2) I219-LM
>> >>
>> >>
>> >> Cheers.
>> >>
>> >> --
>> >> Joshua M. Clulow
>> >> http://blog.sysmgr.org
>> >>
>> > ___
>> > openindiana-discuss mailing list
>> > 

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Thu, Dec 23, 2021 at 11:36 AM s...@pandora.be  wrote:

> Do you still have access to a console when the system is 'unreachable'
> over the network ?
>
Yes, I do.

>
> If you still have a text console on the system which became unreachable,
> perhaps you could check before rebooting whether you can see any errors on
> the NIC.
>
> For example using:
>
> # dladm show-link -s rge0
>
> When I run the above command on system with a e1000g0 interface, it prints
> IERRORS / OERRORS in the show-link -s e1000g0 output, so hopefully it also
> prints those statistics for rge0.
>
> Also maybe there are error messages in the /var/adm/messages related to
> rge0.
>
These are good ideas, thanks. I'll try them next time it happens and then
report back.

>
>
> Regards,
> David Stes
>
> - Op 22 dec 2021 om 8:56 schreef Judah Richardson
> judahrichard...@gmail.com:
>
> > On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow 
> wrote:
> >
> >> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
> >>  wrote:
> >> > On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
> >> openindiana-discuss  wrote:
> >> >> > Any logs or anything like that in particular I should take a look
> at?
> >> >> What driver is in use?
> >> > How do I determine this?
> >>
> >> What do you see in "ipadm show-addr"
> >
> > $ sudo ipadm show-addr
> > Password:
> > ADDROBJ   TYPE STATEADDR
> > lo0/v4static   ok   127.0.0.1/8
> > rge0/_b   dhcp ok   192.168.0.71/24
> > lo0/v6static   ok   ::1/128
> > rge0/_a   addrconf ok   fe80::7a45:c4ff:fe14:10a4/10
> >
> > and "dladm show-ether"?
> >
> > ~$ sudo dladm show-ether
> > LINKPTYPESTATEAUTO  SPEED-DUPLEX
> > PAUSE
> > rge0current  up   no1G-f
> none
> >
> >  By
> >> default, NICs are named with the driver you're using; e.g., "bge0" is
> >> an instance of the "bge" driver.
> >>
> >> >> What model of NIC is it?
> >> >
> >> > It's an onboard Realtek NIC.
> >>
> >> If you "pkg install diagnostic/pci" you should be able to:
> >>
> >> /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
> >>
> > $ sudo /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
> > BDF VID   DID   DRIVER VENDORDEVICE
> > 0/0/0   8086  100   -- Intel Corporation 2nd
> > Generation Core Processor Family DRAM Controller
> > 0/2/0   8086  102   i9150  Intel Corporation 2nd
> > Generation Core Processor Family Integrated Graphics Controller
> > 0/16/0  8086  1c3a  -- Intel Corporation 6
> > Series/C200 Series Chipset Family MEI Controller #1
> > 0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
> > Series/C200 Series Chipset Family USB Enhanced Host Controller #2
> > 0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
> > Series/C200 Series Chipset Family High Definition Audio Controller
> > 0/1c/0  8086  1c10  -- Intel Corporation 6
> > Series/C200 Series Chipset Family PCI Express Root Port 1
> > 0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
> > Series/C200 Series Chipset Family PCI Express Root Port 3
> > 0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
> > Series/C200 Series Chipset Family PCI Express Root Port 5
> > 3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
> > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
> > 0/1d/0  8086  1c26  ehci1  Intel Corporation 6
> > Series/C200 Series Chipset Family USB Enhanced Host Controller #1
> > 0/1f/0  8086  1c5c  isa0   Intel Corporation H61
> > Express Chipset LPC Controller
> > 0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
> > Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,
> ports
> > 0-3)
> > 0/1f/3  8086  1c22  -- Intel Corporation 6
> > Series/C200 Series Chipset Family SMBus Controller
> > 0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
> > Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode,
> ports
> > 4-5)
> >
> >
> >>
> >> e.g., I can see, on one of my systems:
> >>
> >>0/1f/6  8086  15b7  e1000g0Intel Corporation
> >> Ethernet Connection (2) I219-LM
> >>
> >>
> >> Cheers.
> >>
> >> --
> >> Joshua M. Clulow
> >> http://blog.sysmgr.org
> >>
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[s...@pandora.be]

Do you still have access to a console when the system is 'unreachable' over the 
network ?

If you still have a text console on the system which became unreachable, 
perhaps you could check before rebooting whether you can see any errors on the 
NIC.

For example using:

# dladm show-link -s rge0  

When I run the above command on system with a e1000g0 interface, it prints 
IERRORS / OERRORS in the show-link -s e1000g0 output, so hopefully it also 
prints those statistics for rge0.

Also maybe there are error messages in the /var/adm/messages related to rge0.


Regards,
David Stes

- Op 22 dec 2021 om 8:56 schreef Judah Richardson judahrichard...@gmail.com:

> On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow  wrote:
> 
>> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
>>  wrote:
>> > On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
>> openindiana-discuss  wrote:
>> >> > Any logs or anything like that in particular I should take a look at?
>> >> What driver is in use?
>> > How do I determine this?
>>
>> What do you see in "ipadm show-addr"
> 
> $ sudo ipadm show-addr
> Password:
> ADDROBJ   TYPE STATEADDR
> lo0/v4static   ok   127.0.0.1/8
> rge0/_b   dhcp ok   192.168.0.71/24
> lo0/v6static   ok   ::1/128
> rge0/_a   addrconf ok   fe80::7a45:c4ff:fe14:10a4/10
> 
> and "dladm show-ether"?
> 
> ~$ sudo dladm show-ether
> LINKPTYPESTATEAUTO  SPEED-DUPLEX
> PAUSE
> rge0current  up   no1G-fnone
> 
>  By
>> default, NICs are named with the driver you're using; e.g., "bge0" is
>> an instance of the "bge" driver.
>>
>> >> What model of NIC is it?
>> >
>> > It's an onboard Realtek NIC.
>>
>> If you "pkg install diagnostic/pci" you should be able to:
>>
>> /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
>>
> $ sudo /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
> BDF VID   DID   DRIVER VENDORDEVICE
> 0/0/0   8086  100   -- Intel Corporation 2nd
> Generation Core Processor Family DRAM Controller
> 0/2/0   8086  102   i9150  Intel Corporation 2nd
> Generation Core Processor Family Integrated Graphics Controller
> 0/16/0  8086  1c3a  -- Intel Corporation 6
> Series/C200 Series Chipset Family MEI Controller #1
> 0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
> Series/C200 Series Chipset Family USB Enhanced Host Controller #2
> 0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
> Series/C200 Series Chipset Family High Definition Audio Controller
> 0/1c/0  8086  1c10  -- Intel Corporation 6
> Series/C200 Series Chipset Family PCI Express Root Port 1
> 0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
> Series/C200 Series Chipset Family PCI Express Root Port 3
> 0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
> Series/C200 Series Chipset Family PCI Express Root Port 5
> 3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
> 0/1d/0  8086  1c26  ehci1  Intel Corporation 6
> Series/C200 Series Chipset Family USB Enhanced Host Controller #1
> 0/1f/0  8086  1c5c  isa0   Intel Corporation H61
> Express Chipset LPC Controller
> 0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
> Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode, ports
> 0-3)
> 0/1f/3  8086  1c22  -- Intel Corporation 6
> Series/C200 Series Chipset Family SMBus Controller
> 0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
> Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode, ports
> 4-5)
> 
> 
>>
>> e.g., I can see, on one of my systems:
>>
>>0/1f/6  8086  15b7  e1000g0Intel Corporation
>> Ethernet Connection (2) I219-LM
>>
>>
>> Cheers.
>>
>> --
>> Joshua M. Clulow
>> http://blog.sysmgr.org
>>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Stephan Althaus]

On 12/21/21 03:36, Carl Brewer wrote:

On 21/12/2021 12:47 pm, Judah Richardson wrote:

I've been having an odd problem over the past few months in which my OI
Hipster installation becomes unreachable over the network after a 
certain
length of uptime. I haven't been able to determine exactly what this 
length
is, but I usually become aware of it when restic jobs that use that 
machine

as a repo start failing.


What version of OI?
I have an old one that drops off the net after a while, running :

SunOS hostie 5.11 illumos-5d539a8 i86pc i386 i86pc Solaris

That's from :
oi151a8-dev  NR /  18.1G static 2013-08-12 22:58

It seemed to be related to traffic, some counter somewhere overflowing 
- since I took a bunch of Virtualbox VM's off it, it's been a lot more 
connectable. Now it's just a LAN fileserver. It's gone from losing 
network once every week or two, to, I can't remember when it last lost 
network.


Haven't had any problems with newer OI's. As a workaround, I had a 
script that rebooted it when it couldn't get a ping response.  Not 
ideal, but it worked!



Carl


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Hello!

I had problems on a OI box running 2 zones with exclusive network, fixed 
IP's IPV4 only. I had reconfigured the network 2 years ago i think 
(don't know the exact old config), and updated every about half a year 
 it seems to be solved.


I had this 'solution', too: "As a workaround, I had a script that 
rebooted it when it couldn't get a ping response.  Not ideal, but it 
worked! " :-D


Stephan


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Dec 21, 2021 at 2:06 AM Joshua M. Clulow  wrote:

> On Mon, 20 Dec 2021 at 22:26, Judah Richardson
>  wrote:
> > On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via
> openindiana-discuss  wrote:
> >> > Any logs or anything like that in particular I should take a look at?
> >> What driver is in use?
> > How do I determine this?
>
> What do you see in "ipadm show-addr"

$ sudo ipadm show-addr
Password:
ADDROBJ   TYPE STATEADDR
lo0/v4static   ok   127.0.0.1/8
rge0/_b   dhcp ok   192.168.0.71/24
lo0/v6static   ok   ::1/128
rge0/_a   addrconf ok   fe80::7a45:c4ff:fe14:10a4/10

and "dladm show-ether"?

~$ sudo dladm show-ether
LINKPTYPESTATEAUTO  SPEED-DUPLEX
PAUSE
rge0current  up   no1G-fnone

  By
> default, NICs are named with the driver you're using; e.g., "bge0" is
> an instance of the "bge" driver.
>
> >> What model of NIC is it?
> >
> > It's an onboard Realtek NIC.
>
> If you "pkg install diagnostic/pci" you should be able to:
>
> /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
>
$ sudo /usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device
BDF VID   DID   DRIVER VENDORDEVICE
0/0/0   8086  100   -- Intel Corporation 2nd
Generation Core Processor Family DRAM Controller
0/2/0   8086  102   i9150  Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller
0/16/0  8086  1c3a  -- Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1
0/1a/0  8086  1c2d  ehci0  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #2
0/1b/0  8086  1c20  audiohd0   Intel Corporation 6
Series/C200 Series Chipset Family High Definition Audio Controller
0/1c/0  8086  1c10  -- Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 1
0/1c/2  8086  1c14  pcieb1 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 3
0/1c/4  8086  1c18  pcieb2 Intel Corporation 6
Series/C200 Series Chipset Family PCI Express Root Port 5
3/0/0   10ec  8168  rge0   Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
0/1d/0  8086  1c26  ehci1  Intel Corporation 6
Series/C200 Series Chipset Family USB Enhanced Host Controller #1
0/1f/0  8086  1c5c  isa0   Intel Corporation H61
Express Chipset LPC Controller
0/1f/2  8086  1c00  pci-ide0   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode, ports
0-3)
0/1f/3  8086  1c22  -- Intel Corporation 6
Series/C200 Series Chipset Family SMBus Controller
0/1f/5  8086  1c08  pci-ide1   Intel Corporation 6
Series/C200 Series Chipset Family Desktop SATA Controller (IDE mode, ports
4-5)


>
> e.g., I can see, on one of my systems:
>
>0/1f/6  8086  15b7  e1000g0Intel Corporation
> Ethernet Connection (2) I219-LM
>
>
> Cheers.
>
> --
> Joshua M. Clulow
> http://blog.sysmgr.org
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Mon, 20 Dec 2021 at 22:26, Judah Richardson
 wrote:
> On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via openindiana-discuss 
>  wrote:
>> > Any logs or anything like that in particular I should take a look at?
>> What driver is in use?
> How do I determine this?

What do you see in "ipadm show-addr" and "dladm show-ether"?  By
default, NICs are named with the driver you're using; e.g., "bge0" is
an instance of the "bge" driver.

>> What model of NIC is it?
>
> It's an onboard Realtek NIC.

If you "pkg install diagnostic/pci" you should be able to:

/usr/lib/pci/pcieadm show-devs -o bdf,vid,did,driver,vendor,device

e.g., I can see, on one of my systems:

   0/1f/6  8086  15b7  e1000g0Intel Corporation
Ethernet Connection (2) I219-LM


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Tue, Dec 21, 2021 at 12:23 AM Joshua M. Clulow via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> On Mon, 20 Dec 2021 at 17:47, Judah Richardson
>  wrote:
> > I've been having an odd problem over the past few months in which my OI
> > Hipster installation becomes unreachable over the network after a certain
> > length of uptime. I haven't been able to determine exactly what this
> length
> > is, but I usually become aware of it when restic jobs that use that
> machine
> > as a repo start failing.
> >
> > When it happens, OI's DE network icon says all is well, and the LEDs on
> the
> > NIC Ethernet port as well as corresponding switch port are blinking.
> > Rebooting makes the machine reachable again, but the problem reoccurs
> later.
> >
> > The machine itself is pretty old so the NIC might be going bad, or maybe
> > the Ethernet cable is to blame (odd, but Ethernt cables apparently fail
> in
> > very strange ways), but I'd like to rule out anything amiss in the OS
> > itself.
> >
> > Any logs or anything like that in particular I should take a look at?
>
> What driver is in use?

How do I determine this?


> What model of NIC is it?
>
It's an onboard Realtek NIC.

>
> Cheers.
>
> --
> Joshua M. Clulow
> http://blog.sysmgr.org
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Joshua M. Clulow via openindiana-discuss]

On Mon, 20 Dec 2021 at 17:47, Judah Richardson
 wrote:
> I've been having an odd problem over the past few months in which my OI
> Hipster installation becomes unreachable over the network after a certain
> length of uptime. I haven't been able to determine exactly what this length
> is, but I usually become aware of it when restic jobs that use that machine
> as a repo start failing.
>
> When it happens, OI's DE network icon says all is well, and the LEDs on the
> NIC Ethernet port as well as corresponding switch port are blinking.
> Rebooting makes the machine reachable again, but the problem reoccurs later.
>
> The machine itself is pretty old so the NIC might be going bad, or maybe
> the Ethernet cable is to blame (odd, but Ethernt cables apparently fail in
> very strange ways), but I'd like to rule out anything amiss in the OS
> itself.
>
> Any logs or anything like that in particular I should take a look at?

What driver is in use?  What model of NIC is it?

Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Judah Richardson]

On Mon, Dec 20, 2021 at 8:37 PM Carl Brewer  wrote:

> On 21/12/2021 12:47 pm, Judah Richardson wrote:
> > I've been having an odd problem over the past few months in which my OI
> > Hipster installation becomes unreachable over the network after a certain
> > length of uptime. I haven't been able to determine exactly what this
> length
> > is, but I usually become aware of it when restic jobs that use that
> machine
> > as a repo start failing.
>
> What version of OI?
>
$ uname -a
SunOS DellOptiPlex390MT 5.11 illumos-8779b44894 i86pc i386 i86pc illumos

Hipster 2021.10

> I have an old one that drops off the net after a while, running :
>
> SunOS hostie 5.11 illumos-5d539a8 i86pc i386 i86pc Solaris
>
> That's from :
> oi151a8-dev  NR /  18.1G static 2013-08-12 22:58
>
> It seemed to be related to traffic, some counter somewhere overflowing -
> since I took a bunch of Virtualbox VM's off it, it's been a lot more
> connectable. Now it's just a LAN fileserver. It's gone from losing
> network once every week or two, to, I can't remember when it last lost
> network.
>
Hmmm sounds like a semi-known issue, then?

>
> Haven't had any problems with newer OI's. As a workaround, I had a
> script that rebooted it when it couldn't get a ping response.  Not
> ideal, but it worked!
>
>
> Carl
>
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OI Hipster becomes unreachable over network after a certain length of uptime

[Carl Brewer]

On 21/12/2021 12:47 pm, Judah Richardson wrote:

I've been having an odd problem over the past few months in which my OI
Hipster installation becomes unreachable over the network after a certain
length of uptime. I haven't been able to determine exactly what this length
is, but I usually become aware of it when restic jobs that use that machine
as a repo start failing.


What version of OI?
I have an old one that drops off the net after a while, running :

SunOS hostie 5.11 illumos-5d539a8 i86pc i386 i86pc Solaris

That's from :
oi151a8-dev  NR /  18.1G static 2013-08-12 22:58

It seemed to be related to traffic, some counter somewhere overflowing - 
since I took a bunch of Virtualbox VM's off it, it's been a lot more 
connectable. Now it's just a LAN fileserver. It's gone from losing 
network once every week or two, to, I can't remember when it last lost 
network.


Haven't had any problems with newer OI's. As a workaround, I had a 
script that rebooted it when it couldn't get a ping response.  Not 
ideal, but it worked!



Carl


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss