es
> not set the DF flag.
That's not the default behavior. The default is to have DF on, at least
on the Solaris versions I'm familiar with. (I guess Oracle could have
changed this, though I think it would be wrong to do so
"cfgadm -lv"?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Jeppe Toustrup wrote:
> On Mon, Oct 3, 2011 at 16:00, James Carlson wrote:
>> Have you tried "cfgadm -lv"?
>
> Yes, "cfgadm -lv" does not list the drives connected through SAS, but
> "cfgadm -lav" does. The output does however not make me much wis
(a somewhat unsettled area of the
USB world), but will include the ability to open the device with libusb
and communicate from user space.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindia
newer Ethernet
cards. Many of them perform better than Cassini anyway.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
/netmasks
# echo 10.1.0.1 > /etc/hostname.foo0
I recommend doing this instead:
# echo 10.1.0.1/16 > /etc/hostname.foo0
It's easier, and it has the great benefit that it works right with CIDR
netmasks without fuss.
Or just use "ipadm" to administer the addresses ...
--
s 10. I think you're much better off calling Oracle for support,
because I think you're pretty far afield right now ...
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindi
this, including having a
duplicate IP address configured somewhere on your network.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
ally both symptoms of underlying network
trouble?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
2.168.254.200
... but replace that address with the address of the client. If that
query doesn't return immediately with a useful answer (such as
"192.168.254.200 dhcp-200"), that's what's wrong.
--
James Carlson 42.703N 71.076W
a good plan B for an over-constrained problem.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
nuscule bump in performance, they extract many hours and
days of wasted administrative effort.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
tation.)
If you want to use an event hook, create a /etc/dhcp/eventhook script.
See the dhcpagent(1M) man page for details.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
nt dhcpagent from writing the
> /etc/resolv.conf file.
The overwrite occurs when svc:/network/service:default runs.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://ope
#x27;ll almost certainly want to leave the IPv6
loopback address alone. The v6 folks do a lot of compatibility testing
without external v6 addresses, but not without loopback.)
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss
r, "kstat" may be helpful in getting really low-level diagnostic
information.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
t, then it's possible that there's a corner case here (new
entries in llp) that nwamd doesn't handle too well.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
nual control. (It's was originally designed
primarily for laptops. Yes, quite a few of us at Sun ran Solaris on
laptops.)
One option might be trying to contact the project team at
nwam-disc...@opensolaris.org, or by searching around for the project
lead, Renee Sommerfeld (nee Danson).
-
what it's worth, I'd *really* recommend updating that e1000g
configuration to avoid the known problem areas and switching from NWAM
to static configuration for such a system.
But it's obviously your call.
--
James Carlson 42.703N 71.076W
ed by the Borgacle.
http://blogs.oracle.com/drapeau/entry/nagios_is_available_for_opensolaris
Perhaps this would be a better starting point:
http://gibbontech.blogspot.com/2007/04/compiling-nagios-30a3-and-plugins-for.html
--
James Carlso
" one
> Looks like aggregation is not using all the available throughput......what am
> I missing? is there
> any incompatibility between Solaris10/08 and OpenIndiana?
I don't expect that there should be any. More likely, I expect a
misconfiguration somewhere in this set-
ipe the data across the available
devices, parallelizing the I/O operations. To get better error
tolerance, use raidz2 or raidz3.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
that'll
still be a single flow.
Ethernet trunking works great for high levels of aggregation and (with
LACP) as a low-level redundancy mechanism. It doesn't magically make
things go faster, though. If you want that, then you'll
Gernot Wolf wrote:
> Ok, for some reason this attachement refuses to go out :( Have to figure
> that out...
Probably just because it's huge. Try "tail -100 /var/adm/messages".
It's likely that if there's something going nuts on your system,
there'll be enough
eature
will probably have to be added to the code. It's not present in the
current code because the observability node covered the known uses of
that sort of port without extra complications.
--
James Carlson 42.703N 71.076W
carlopmart wrote:
> On 10/24/2011 06:13 PM, James Carlson wrote:
>> carlopmart wrote:
>>> Is it possible to configure a bridge (with n physical nics) with a
>>> span
>>> port like for example FreeBSD does??
>>
>> No, mirror port functionality
ier method? (tcpdump on Linux allows "-i
> any" to capture across interfaces but it's not promiscuous capture and
> I'm not sure if the Solaris version supports it.)
No.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
carlopmart wrote:
> On 10/24/2011 07:08 PM, James Carlson wrote:
>> You didn't say how you're sniffing traffic. If you mean that you must
>> use an _external_ network monitoring device to do this, then the
>> existing built-in mechanism obviously won't be suf
SATA drives), and the other
dedicated for SAS.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
tils.
http://comments.gmane.org/gmane.comp.gnu.inetutils.bugs/1318
In any event "sig_t" isn't defined on OpenIndiana.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http
svcs -xv", and then examine the
log files that the system tells you about in the svcs output.
What happened when you did that?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.or
crontab /tmp/root.cron
what happens?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
sent. Writing portable software is harder than
that. Reading through that problem report, though, makes it sound like
those other developers aren't going to agree with me. :-/
--
James Carlson 42.703N 71.076W
___
OpenIndiana-d
Andrey N. Oktyabrski wrote:
> On 28.10.11 16:29, James Carlson wrote:
>>> In which bug tracker I must create a bug report for this issue?
>>>
>>> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>>> _IOR('f', 1, long)
>>>
Andrey N. Oktyabrski wrote:
> On 28.10.11 18:29, James Carlson wrote:
>> You might have an argument that e2fsprogs shouldn't include this header
>> file. Most projects (for what it's worth) just toss in the kitchen sink
>> -- anything that's built is shipp
RC/2009/232/pfp-psarc.txt
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Andrey N. Oktyabrski wrote:
> On 03.11.11 16:22, James Carlson wrote:
>> Andrey N. Oktyabrski wrote:
>>> More about e2fsprogs. Now from the pkgsrc. There is a same bug as here:
>>> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45499
>>>
>>>
On 11/5/11 5:40 AM, Andrey N. Oktyabrski wrote:
> On 04.11.11 14:14, James Carlson wrote:
>> I'd say #1. ...
> So it is a lot of words in the justification of not to change anything
> in the OI/Illumos...
That's not entirely true. If someone wants to change OI to ma
I suspect
this is caused by an automated installer that is enabled on this system.
I don't know what they might be calling it these days, but there was a
product called "Sun Update Manager" that would do this sort of thing.
Since this is S10 (rather than OpenIndiana or even OpenSolaris
t; on the core file
itself. Or use mdb and the "$c" command to print a stack trace. And
show the result to the developer of the code -- he's likely the only one
who can diagnose the problem correctly.
--
James Carlson 42.703N 71.076W
__
he named pipe:
tcpdump -i bridge0 -s0 -w /dev/stdout | ssh ids "snort-etc-capture"
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
ying their products. Whatever you feel is best.
But speculating here about their motives is probably pointless.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
gh.
http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Edward Martinez wrote:
> On 11/11/11 06:48, James Carlson wrote:
>> But sources were indeed promised at some unspecified date after the
>> binary release. Hope they carry through.
>>
>> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html
&g
ting technical challenges. One is that
the zpool and zfs version numbering space is flat, so unless the new
on-disk (and in-stream) formats can be reverse-engineered, the
compatibility story will be unusual, to say the least.
--
James Carlson 4
t does "ifconfig -a" say about the state of the interfaces? You
will see "DHCP" on the IPv6 interface if DHCPv6 is running.
- If the interface is already running DHCPv6, then try:
dhcpinfo -i bge0 -v6 DNSAddresses
(Replace "bge0" with the
/etc/resolv.conf.new
mv /etc/resolv.conf.new /etc/resolv.conf
;;
esac
exit 0
The exact details will vary depending on how you want your network to
operate.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
t; will see what I can find.
No. If you're getting output from dhcpinfo, then DHCP is running. As I
noted before "ifconfig -a" will also show you that DHCP is running.
The problem appears to be the local plumbing, not the router.
--
James Carlson 42.703N 71.076W
> then press enter, and b
> what I can see is the picture which right bottom corner is "Powered by
> illumo"
You need to turn off graphical boot as well. Use "d" in GRUB to remove
the spashimage, foreground, and background lines, and then remove
&quo
darkblue wrote:
> 2011/11/21 James Carlson
>> You need to turn off graphical boot as well. Use "d" in GRUB to remove
>> the spashimage, foreground, and background lines, and then remove
>> "console=graphics" from the kernel$ line. That should allow you
On 11/23/2011 08:28 AM, Jeppe Toustrup wrote:
Hi
I am in the process of setting up IPv6 for some servers running
OpenIndiana. Each server/zone has it's own IPv6 address which is
configured statically in /etc/hostname6. such as:
addif dead:beef:1000::11/64 up
A default gateway has been se
On 11/24/11 16:45, Jeppe Toustrup wrote:
> On Thu, Nov 24, 2011 at 22:27, James Carlson wrote:
>> Read the ndpd.conf(4) man page. And set "ifdefault StatelessAddrConf off"
>> in /etc/inet/ndpd.conf.
>
> Ah, thank you for the pointer. I tried it out and It is in
sult doesn't fit in the data structure
available. Rather than return a wrong answer, it returns no answer.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Albert Chin wrote:
> On Sun, Nov 27, 2011 at 08:04:33AM -0500, James Carlson wrote:
>> On 11/27/11 02:03, Albert Chin wrote:
>>> On Sun, Nov 27, 2011 at 12:48:39AM -0600, Albert Chin wrote:
>>>> We're running oi_151a and using it to serve up file systems
t
intended to make it work primarily with things other than routing protocols.
http://hub.opensolaris.org/bin/view/Project+vrrp/
Maybe you can find some pointers related to that ...
--
James Carlson 42.703N 71.076W
___
OpenIndiana-dis
4L) has been supported for a long time. The former
(82579LM) is more recent:
https://www.illumos.org/issues/832
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana
Hans J. Albertsson wrote:
> Subject says it all.
>
> I suppose so, at least one shouldn't need to do anything beyond addig a
> line in /etc/driver_aliases, right?
The line for 8086,10a7 should already be there; it's served by "igb".
--
James
d call pppoeisp" or (to do
this with debugging enabled, and debug messages written to your
terminal) "pppd call pppoeisp debug updetach".
More information about the PPP level of configuration (as opposed to the
low-level PPPoE plumbing) is a
ast at the 100Mbps level on cheap commodity hardware. If you're
seeing something else, then I think you probably have other problems.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
127.1 5667" rather than
attempting to use "0" as an alias for the local system.
It's a bit of an old Solaris bug that allows address 0 to work as a
local address (even though it's not a valid address), and there's no
guarantee that it will work on any modern Solaris
fine and when it's slow; the difference may reveal something,
- installing a network interface card that uses a different driver
(e.g., if you have Intel, install Broadcom) and see if that interface
behaves differently.
Note that you'll probably need to know a fair bi
ilding as you've always done (without stub libraries), using all the
same dependencies as you've done before, and it'll keep working.
The stubs are just a build artifact. They're generated automatically
and aren't needed after the build is
quot; parameter.
That's what sets the actual disk area available for swap. It looks
like the existing volume was set to 500MB. Try "zfs list -o
name,volsize rpool/swap".
To change the swap size, I'd do this:
# swap -d /dev/zvol/dsk/rpool/swap
# zfs volsize=2G rp
seful
responses if you described what you were hoping to accomplish by
replacing that component.
For what it's worth, the ssh that comes with OpenIndiana is well
integrated with the existing OS features and performs decently. You may
end up replicating the hard work the Sun ssh team did gett
gn differences, particularly in the area of privilege
separation.
Meaningful source patches for this sort of thing are probably at least
as hard to manage as are the sources themselves -- meaning that I
believe you'd have no real benefit to keeping
necessary occurred, and the
issues were (and are) not trivial.
But, hey, it's your system. Install anything you want on it. Much luck.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openin
am considering putting a pre-crossbow S10,
> oi148, and/or S11 on the front line here to see if the problem goes away. I
> starting to scrape the bottom of the barrel for ideas.
Those symptoms seem to point in the direction of something much broader;
a system-wide issue with interrupts, perhaps.
resting item. The server that has had the 'resets'
> where performance returns to normal but then begins the march of death has a
> link state of 'unknown' on its two vnics.
That is interesting. Unfortunately, I'm not sure what it means.
At this point I think the prime s
horization to do so. I don't
think anything about that message should relate to a "freeze-up."
It could be a symptom, though, of other issues. If this system is
intended for use as a server, it's possible that you might not want to
be using NWAM a
uration.
That's an interesting observation. When running with one port, do you
unplumb the other? Or is "one port" just an application configuration
issue?
If you run "/sbin/route monitor" when the system is working fine and
leave it running until a problem happens, do y
'm guessing that what's really going on is that you have
either interfaces, IREs, or ARP entries flapping in the breeze due to
the odd configuration on this system. "route monitor" should reveal that.
But it could be almost anything else. Looking at kstats and/or
ca
Robin Axelsson wrote:
> On 2012-01-24 21:59, James Carlson wrote:
>> Well, unless you get into playing tricks with IP Filter. And if you do
>> that, then you're in a much deeper world of hurt, at least in terms of
>> performance.
> Here's what the virtualbox m
e). Both connections have now disappeared from 'ifconfig
> -a' (also the IPv6 part is gone as well), even after a reboot, so I
> consider them permanently unplumbed. It looks like this when issuing
> 'ifconfig -a':
>
> lo0: flags=2001000849 mtu
> 8232 index 1
&
k(3DLPI)), at least on OpenIndiana.
If portability to older Solaris systems is necessary, it should be
enumerating DLPI interfaces using libdevinfo.
Piggybacking on IP isn't right at all.
--
James Carlson 42.703N 71.076W
___
OpenI
On 01/27/12 07:51, Robin Axelsson wrote:
> On 2012-01-25 21:50, James Carlson wrote:
>> By default, the first IP layer object created on a given datalink layer
>> object has the same name as that datalink layer object -- even though
>> they're distinct ideas. The
way for the kernel to find it there. And if you could do it,
then you could break the security model, so the limitation is a good thing.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openin
eone is going to a
lot of effort to make things more complex in order to avoid problems.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
what went wrong. Unfortunately, I only
remember details about the "old" one ...
> Perhaps it already does so. If not it should at
> least unplumb one connection to prevent the interference issues the
> James Carlson was talking about, or at least give warning messages about
> it
Robin Axelsson wrote:
> On 2012-01-27 15:32, James Carlson wrote:
>> What NWAM is supposed to do is configure only one usable interface
>> (guided by user selection criteria) for the system. The fact that you
>> got multiple interfaces configured is indeed an anomaly, and o
Robin Axelsson wrote:
> On 2012-01-27 16:45, James Carlson wrote:
>> Robin Axelsson wrote:
>>> On 2012-01-27 15:32, James Carlson wrote:
>>>> What NWAM is supposed to do is configure only one usable interface
>>>> (guided by user selection criteria) f
an independent
> process from the network issue or if they are directly related in some way.
It's possible that they're related. It sounds to me like this is a
pretty good clue.
--
James Carlson 42.703N 71.076W
___
OpenIndi
ot;savecore" directory; usually /var/crash. Look for files there.
Running mdb on the files and using ::status and ::stack commands might
give a good enough signature that someone could identify the cause.
(I'm not a CIFS expert, but if you gather some basic l
minating the useful BE
creation process, why not fix the broken Chef/Puppet behavior?
Modifying the current configuration makes no sense here.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndia
oute. ICMP Router Discovery can also do that. RIP-2 and OSPF
can do the same job, but are much more flexible and can provide
arbitrary network and host routes as well. If you don't use any of
those, then you have to configure the default route manually, along with
some way to ma
pful. It should identify
the process that is removing the route, which will then help focus the
issue.
What about logs?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
han an etherstub. A simnet is a simulated Ethernet interface.
As for the "STATE unknown" bit, I believe that's because etherstubs
don't have physical links and thus don't have physical link status.
It's probably harmless.
--
James Carlson 42.703N 71.076W
- that's
sort of the definition of bridging.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
tention.
I wouldn't be much surprised, with high-speed links, to see the
performance drop to less than what you get by putting all the traffic
over one link.
But if it's worth it to you to try, then by all means, change the driver
and publish the results. ;-}
--
te NFS exports for each of the underlying
datasets -- one for Video and one for Music in this case.
Automount, of course, is your friend. ;-}
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
d they all say that you
shouldn't run DHCPv6 on a prefix, then it will not be run. If you have
no IPv6 routers (a bit of a degenerate case in the standards), then
DHCPv6 is required to run, and the system will run it, but it's almost
completely useless.
See in.ndpd(1M), dhcpagent(1M), and i
n DHCP on a given network.
With IPv6, DHCPv6 is invoked by the actions of in.ndpd, because there's
a standard Router Advertisement based mechanism that tells a node
whether DHCPv6 is in use. For v6, it should have nothing to do with NWAM.
e NWAM.
But it has little to do with how DHCPv6 works.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
ough the "prtpicl -v"
output or in the syslog messages. A key clue is seeing "usb_mid"
attaching to the device when it's inserted. That means that no standard
class driver works on that device, and you're getting the "generic"
driver that
/messages, and the files are dumped in /var/crash.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
;beadm'. Because you just imported the
pool, I suspect that won't work, and you'll have to change the
fpool/ROOT/ mount point to something temporary, and then change
it back to "/" when done.
--
James Carlson 42.703N 71.076W
__
" mount to fail.
Where there errors when you mounted these file systems? Perhaps one
saying that the system was unable to mount fpool/ROOT/openindiana
because the "/mnt" directory was not empty?
--
James Carlson 42.703N 71.076W
__
ZFS attributes; they tell you everything you might want to know.
zfs get -o all all fpool/ROOT/opensolaris
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
is that it doesn't
> quite grok zfs yet. I find myself using "zfs list" quite a bit.
>
> In any event, the confluence of comments got me to the solution. Which is
> what matters.
None of that rings true to me, b
he LAN nic?
> Does mdns have a similar issue? I discovered this by running "bssh" and
> seeing the service both on my bge0 (WAN) and bge1 (LAN) nics.
These should be the same thing -- just block UDP port 5353 in the places
where you don't want Avahi/mDNS stuff to leak.
--
Ja
information produced by
the system -- syslog output, command output, error messages, network
configuration (netstat -ni, netstat -nr, ifconfig -a) -- would probably
be helpful in chasing down problems. Again, posting that information
somewhere would be a good idea.
--
James Carlson 4
1 - 100 of 326 matches
Mail list logo
