Jeremy Friesner's questions

On my test Linux box with a Transcend TS2TMTE662T2-G1 SSD installed. I created a 100GB dummy file on my 1.8TB ext4 partition, and then I ran cat <bigdummy.bin >/dev/null to sequentially read the data from that file as quickly as possible.

With cat running, I ran iostat -t nvme0n1p6 --human 1 in a different shell window to monitor what the SSD's read-performance was like... it looks pretty good, I'm reading in ~2.2 gigabytes per second:

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1p6     18232.00         2.2G         0.0k         0.0k       2.2G       0.0k       0.0k

I then used rm to delete about 600GB of (unrelated) files from the partition, and then I ran fstrim --all to tell the SSD to start erasing the newly-discarded blocks. While that trimming was going on, I looked at iostat's output again to see how my cat process's read-performance was now faring:

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1p6       215.00        18.1M         0.0k         8.8G      18.1M       0.0k       8.8G

Ecch, not very good at all. Read bandwidth has been reduced to a measly 18MB/sec, and the transactions-per-second is similarly down by a factor of 100.

It's probably unreasonable for me to expect 100% of normal read performance from an SSD that is also in the middle of doing 8.8G/s of kb_dscd's... but since the block-discarding operation isn't particularly time-critical (in that I don't care that much whether it completes in 30 seconds or continues for 30 minutes), is there any way for me to slow that process down so that my drive's read-performance won't be so badly impacted while it is going on? e.g. if the SSD was only doing 500 M/s of kb_dscd operations, it would (perhaps) have more time left over to handle its normal read-I/O tasks at something approaching its usual rate?

(motivation: this is for a media streaming box that will eventually want to do simultaneous recording and playback, potentially 24/7, and it would be really nice if I could periodically initiate TRIM operations without significantly impacting the box's ability to continue streaming content at the same time.)

In network programming, it's common to pass INADDR_ANY (or IN6ADDR_ANY) as part of the second argument to bind(), telling the networking stack that you want the socket to receive connections/traffic from any network interface that the machine happens to have. Many programs do this, as it is often the most useful behavior. The other common option is to specify a single network interface to bind to, instead.

However, I have a use-case where I'd like one particular network interface on my Linux machine be "reserved", in the sense that it is not included in the set of network interfaces used by sockets bound to INADDR_ANY. In particular, I'd like this network interface to be usable only by sockets that have bound themselves to its IP address explicitly (or perhaps have performed some other explicit step to indicate that they are aware of this network interface's special status and wish to use it anyway) -- sort of a "socket whitelist", if you will, to guarantee that only a few hand-picked apps can send/receive traffic over this network interface. (These apps will likely be ones I wrote and personally control, if that matters)

Is there any mechanism to accomplish this in Linux?

Some approaches that I have considered but am not entirely satisfied with:

1. Modifying all apps to bind explicitly to the network interfaces they want to use, instead of binding to INADDR_ANY, and not including this network interface in the set. (too much work, and I probably don't have access to modify all such apps anyway)
2. Setting up a firewall on the network interface such that only traffic on certain ports is accepted. (this might sort-of work, but it means I have to specify in advance all ports that I will use on the interface, which precludes software that required dynamic port allocation... and of course there would still be the chance that some unexpected app gets "lucky" and happens to bind to one of the whitelisted ports, which would be undesirable)
3. Switch to SELinux or similar security-oriented distribution that has fine-grained ACLs (not a realistic option here, for various reasons I won't get into)

From what I read online, an IPv6 link-local address is generated by taking the network interface's MAC address, inserting an FF:FE word into the middle of it, OR'ing in some additional bits, et voila: e.g. MAC address 00:3E:E1:c6:20:c2 corresponds to IPv6 link-local address fe80::23e:e1ff:fec6:20c2%en0, and a program that knows the MAC address can compute the IPv6 address, or vice-versa.

That seems to work fine on my Macintosh, but on my co-worker's Windows machine we see this (from ipconfig's output):

Connection-specific DNS Suffix  . :
Link-local IPv6 Address . . . . . : fe80::eb:b41:3e4c:fd9e%11
IPv4 Address. . . . . . . . . . . : 192.168.0.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Here it looks like the network interface's MAC address (which is 0b:41:3e:4c:fd:9e ) has had only the byte "eb" OR'd in to the front of it, rather than inserting ff:fe into the middle as I would have expected.

Can anyone explain why that is? i.e. is Windows doing something contrary to the IPv6 link-local address specification here, or is it just using some other acceptable MAC->IPv6 convention that I'm unaware of? Or perhaps vendors are just allowed to do whatever they want when generating an fe80 address from a MAC address?

First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.

IGMP and MLD do this by having the switch maintain a table that tracks which connected devices are currently joined to which multicast groups, and when a multicast packet comes in, the switch forwards it only to the ports that are joined to the group indicated by the packet's destination address. So far, so good.

But according to my co-worker, there is an odd special case: If no devices have joined a particular multicast group, then the switch must forward any incoming multicast packets to all ports (well, technically to all ports with an IGMP router attached, but he says it amounts to the same thing, since most switches don't know which ports have an IGMP router attached and so will fall back to flooding to all ports).

This seems very counterintuitive to me -- why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data? Is this done to ensure backwards compatibility with broken multicast implementations that expect to receive multicast packets they never requested? If not, what is the motivation for this? It seems like it significantly reduces the usefulness of the algorithm.

For reference, the guidelines my co-worker points to are in section 2.1.2 of RFC 4541:

3) An unregistered packet is defined as an IPv4 multicast packet with
   a destination address which does not match any of the groups
   announced in earlier IGMP Membership Reports.

  If a switch receives an unregistered packet, it must forward that
  packet on all ports to which an IGMP router is attached.  A switch
  may default to forwarding unregistered packets on all ports.
  Switches that do not forward unregistered packets to all ports
  must include a configuration option to force the flooding of
  unregistered packets on specified ports.

I think the following paragraph may explain the motivation, but I don't understand it:

In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic.  Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.

i.e. why would failure to flood unregistered streams prevent v3 hosts from receiving their traffic? (wouldn't v3 hosts know to join any groups they want to receive traffic on?) And in the alternative scenario, wouldn't traffic lossage due to flooding be just as bad a problem as traffic loss due not flooding?

My company makes an embedded Debian Linux device that boots from an ext3 partition on an internal SSD drive. Because the device is an embedded "black box", it is usually shut down the rude way, by simply cutting power to the device via an external switch.

This is normally okay, as ext3's journalling keeps things in order, so other than the occasional loss of part of a log file, things keep chugging along fine.

However, we've recently seen a number of units where after a number of hard-power-cycles the ext3 partition starts to develop structural issues -- in particular, we run e2fsck on the ext3 partition and it finds a number of issues like those shown in the output listing at the bottom of this Question. Running e2fsck until it stops reporting errors (or reformatting the partition) clears the issues.

My question is... what are the implications of seeing problems like this on an ext3/SSD system that has been subjected to lots of sudden/unexpected shutdowns?

My feeling is that this might be a sign of a software or hardware problem in our system, since my understanding is that (barring a bug or hardware problem) ext3's journalling feature is supposed to prevent these sorts of filesystem-integrity errors. (Note: I understand that user-data is not journalled and so munged/missing/truncated user-files can happen; I'm specifically talking here about filesystem-metadata errors like those shown below)

My co-worker, on the other hand, says that this is known/expected behavior because SSD controllers sometimes re-order write commands and that can cause the ext3 journal to get confused. In particular, he believes that even given normally functioning hardware and bug-free software, the ext3 journal only makes filesystem corruption less likely, not impossible, so we should not be surprised to see problems like this from time to time.

Which of us is right?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

Just a shot in the dark here, but I thought I'd ask in case anyone has some ideas:

I've got a testing scenario where some (GUI-less/embedded) IPv6 devices are going to be temporarily plugged into the ports of a managed Ethernet switch, and a control program (running on a separate Linux PC, also connected to the switch) will detect when one of these devices appears on the LAN, and automatically run a test to make sure the device is working correctly.

There will typically be a dozen or so of these devices connected at once (so we can run tests in parallel), and devices will be connected and disconnected on a regular basis by people who don't necessarily know anything about networking; they only know how to plug in an Ethernet cable, then (some hours later) look at the PC's screen to see if the test passed or not.

The issue at hand how to indicate to the testing person when a particular device has failed a test. One option is for the error log/message to include the device's MAC address (derived from its link-local IPv6 address), and that might be sufficient in a pinch, but it would be much nicer if the testing program could also say something like "The device connected to port #5 isn't working right, have a look at that one". That way the tester can just follow the ethernet cable to faulty device, rather than having to figure out what each device's MAC address is until he/she finds the matching one.

I don't think that it's possible for the Linux computer to tell which switch port a particular device is connected to (let me know if I'm wrong about that). But assuming that's the case, the next best thing would be if I could program the switch to do MAC address translations, e.g. so that any device that is plugged in to port #n always appears (to the Linux computer) as if it has MAC address foo:bar:baz:n, and therefore shows up as IPv6 address fe80::2foo:bar:baz:n. If the switch did MAC address translation like that, then the control software could determine which port the device was connected to simply by looking at the last section of the fake MAC address.

So my question is, is this behavior something that any managed Ethernet switches support? If so, what is this feature called (so I can find a switch that does it)? If not, is there a better approach to this problem that I should be looking at instead?

I work on a product that is a headless Debian Linux system with removable Intel X-25M solid state drives. Recently we noticed that the read/write performance of these drives degrades over time, and sure enough the culprit was SSD block problems, as described here. So we did a secure erase of the SSD drive (as described here) and the SSD drives' performance is restored to its original/factory level.

Which is great, but what I'm wondering now is if there is some quick-and-easy way to query hdparm (or some other Linux shell command) so it will print out an indication of how badly degraded the SSD's block-structure currently is. If so, then I could add some logic to my own program to automatically notify the user when a secure-erase would significantly improve his system's performance. As it is, the user just has to sort of guess based on observed I/O performance compared to what it was previously... which isn't the end of the world, but it would be nicer if he just got a warning message "your data SSD is currently 35% scrambled, consider doing a secure-erase to get better SSD performance", or something like that.

I have a situation like this:

1. Isolated Gigabit Ethernet LAN with a handful of Linux boxes and Macs on it
2. Airport Extreme wireless access point is also connected to the LAN
3. Two iPads talking to the system via the Airport Extreme and Wifi
4. The iPads are set to use static IP address settings. One iPad is set to IP address 192.168.8.38 and the other is set to 192.168.8.39.
5. One of the Linux boxes periodically runs arp-scan and reports if any duplicate IP addresses are present on the LAN.

The issue is that sometimes (not always), the arp-scan process will report that both iPads' MAC addresses are using the same IP address. When this happens, arp-scan's output shows both iPad's MAC addresses associated with IP address 192.168.8.39. (This despite us manually verifying that the two iPads have distinct IP addresses and MAC addresses by looking at their network settings pages on-screen)

Other than this report from arp-scan, communication with the iPads appears to work fine.

Does anyone know what might cause this behavior? All I can think of is that the iPads' MAC addresses might be hashed to the same value somehow and thus they are overwriting each other in some data structure... or that the iPad set to address 192.168.8.38 occasionally "wanders over" and uses the address next door instead, despite being set to a static IP address. Neither of those hypotheses seems very likely to me though. :^(

I work on a product that consists of a number of headless Linux boxes that work together as a cluster.
These boxes synchronize their state with each other by sending proprietary-format link-local IPv6 multicast packets (to ff12::xxxx%en0). These packets can take up a non-trivial amount of bandwidth when the system state is changing quickly, but that's okay because the Linux boxes are running over a Gigabit Ethernet LAN and there is plenty of bandwidth to spare.

The problem happens when a customer decides he'd like to use his laptop (or iPad) as a client to the system while roaming the building, and so the customer adds a WiFi access point to the LAN and sets up his laptop to communicate (via unicast) with one of the Linux boxes over the WiFi.

This typically "sort of" works, but the problem is that all the multicast synchronization packets sent by the Linux boxes are now being sent over WiFi, even though the client(s) don't need them or use them. As a result, WiFi bandwidth is often impacted, sometimes to an unusable state, and the customer complains that our system isn't working properly.

We could, of course, just tell the customer "don't do that", but WiFi is very useful and I'd like to find a more constructive solution to this problem than just forbidding WiFi. Is there some (reasonably simple) way to configure a WiFi access point to filter out these synchronization multicast-packets? Simply getting the WiFi access point to not handle IPv6 packets would be sufficient for our purposes, since the client software can run over IPv4 if necessary, but some more nuanced filtering that doesn't preclude all IPv6 traffic would be nicer.

Note that the most common access point installed by our customers is Apple's Airport, but if there is another (more configurable) WiFi access point product that would work better, replacing the access point with a different model is an option.

My situation is that my company makes a product that (currently) requires the user to set up a dozen or so VLANs on a managed switch that is dedicated to the exclusive use with our product.

Currently, the way it works is this: The user enters his system-configuration preferences into a proprietary (Qt-based) GUI that we provide, and when he's done the GUI spits out a "VLAN configuration report" indicating what VLANs need to be set up, and which Ethernet ports should be members of which VLANs. The user is then responsible for using the switch's Web interface to manually enter those settings into the switch.

This "sort of" works, but requiring the user to enter all of that data is both tedious and error-prone, so we'd like to somehow automate the process: that is, have our program connect to the managed switch directly and tell the switch what VLANs to set up and what ports to assign to them.

What is the best way to do this? Is this something that can be accomplished using SNMP? If so, where do I look to start implementing such a function? (I'm fairly experienced with basic TCP/IP programming, but I don't know where to start with SNMP.)

First, some background: We've got a lab containing a handful of dedicated Linux servers that run on an isolated LAN. All the servers run the same OS (Debian Linux) and the same proprietary server software, and the server processes communicate with each other to keep their data in sync. That means that as far as any clients are concerned, it doesn't matter which server the client connects to -- any server will return the same data as any other.

These Linux servers all run avahi-daemon to publish mDNS hostnames for themselves, which means that a client can enter e.g. "http://linux-server-1.local." into his web browser and connect to Linux server #1, and so on.

This is all well and good, except it means that a user sitting at the client machine (typically a Mac or Windows laptop with Bonjour installed) has to know (or figure out) which of the Linux servers are currently online, and he has to make sure he connects to one of those. For example, if server #2 is offline today, and the client enters "http://linux-server-2.local." into his URL bar, he's not going to get a response. That isn't the end of the world, of course, but it is annoying for newbie users who expect everything to "just work", and also it makes the development of robust client-side scripting more complicated (since the client-side script would need to know how to deal with offline servers explicitly).

With that in mind, my question is this: is it possible to configure Avahi to publish an anycast-style mDNS hostname alias as well? The goal is that anyone could sit down with his laptop, enter "http://any-linux-server.local." (or similar), and get connected to one of the servers that is currently on line (again, it doesn't matter which one).

Note that this needs to work without any special configuration of client laptops, as we have no control over them (other than the requirement that they have Bonjour installed).

Also note that we can't rely on the presence of a separate nameserver or proxy box, or on the presence of any particular Linux server, since that would introduce a single point of failure, which we're trying to avoid.

My company sells an "embedded device" which is implemented as a headless Linux box with ext4 on an internal SSD. Some of our users have a habit of doing a "save current settings" on this box, and then cutting power to the unit as soon as the unit reports that the save completed (ie two seconds later). This was causing occasional corruption of the saved files, as the data wouldn't always get flushed to the SSD before the power went out. So I tweaked my software to run /bin/sync immediately after writing the file (after closing the file handle but before notifying the user that the save completed). This appears to fix the issue, but my coworker says that one call to /bin/sync isn't sufficient, and that to be really safe I ought to run /bin/sync twice in a row.

That sounds like paranoia to me... Perhaps a habit from earlier versions of Linux or unix whose sync utility didn't work reliably. Does his advice have merit, or should one call to /bin/sync suffice?

This is perhaps an unusual request: I'm trying to get a Debian Linux box to always give itself a self-assigned IP address (i.e. 169.254.x.y) on boot. In particular, I want it to do that even when there is a DHCP server present on the LAN. That is, it should not request an IP address from the DHCP server.

From what I can see in the "man interfaces" text, there is an option for "manual", and an option for "dhcp". Manual assignment won't do, since I need multiple boxes to work on the same LAN without requiring any manual configuration... and "dhcp" does what I want, but only if there is no DHCP server on the LAN. (A requirement is that the functionality of these boxes should not be affected by the presence or absence of a DHCP server).

Is there a trick that I can use to get this behavior?

EDIT: By "no manual configuration", I mean that I should be able to take this box (headless) to any LAN anywhere, plug in the Ethernet cable, and have it do its thing. I shouldn't have to ssh to the box and edit files to get it working each time it is moved to a different LAN.

On my LAN I have three essentially identical Debian Linux boxes running Avahi. One of them has both an IPv4 address and and IPv6 address, and the other two have only IPv6 addresses. They all show up in Bonjour Browser on my Mac, like this:

Workgroup Manager (_workstation._tcp.) - 4
  box-1 [00:60:2b:02:45:f8]
    [fe80::260:2bff:fe02:45f8]:9
    192.168.1.78:9
  box-2 [00:60:2b:02:46:1b]
    [fe80::260:2bff:fe02:461b]:9
  box-3 [00:60:2b:02:42:e2]
    [fe80::260:sbff:fe02:42e2]:9

From my Mac, all is well and good... I can resolve box-1.local., box-2.local., and box-3.local., ping6 to any of them, ssh to any of them, etc.

My Windows 7 machine, however, can only see box-1. For example, doing a dns-sd in a Command Prompt window gets me this:

C:\>dns-sd -B _ssh._tcp
Browsing for _ssh._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
12:41:14.492  Add     2 17 local.                    _ssh._tcp.                box-1 SSH

Pinging that box via its Bonjour name and IPv6 works:

C:\>ping -6 msli-dcm-2-10330688.local.

Pinging msli-dcm-2-10330688.local. [fe80::260:2bff:fe02:45f8%17] with 32 bytes of data:
Reply from fe80::260:2bff:fe02:45f8%17: time=1ms
Reply from fe80::260:2bff:fe02:45f8%17: time<1ms
Reply from fe80::260:2bff:fe02:45f8%17: time<1ms

... as does pinging the other boxes via their IPv6 addresses:

C:\>ping -6 fe80::260:2bff:fe02:461b

Pinging fe80::260:2bff:fe02:461b with 32 bytes of data:
Reply from fe80::260:2bff:fe02:461b: time=4ms
Reply from fe80::260:2bff:fe02:461b: time<1ms
Reply from fe80::260:2bff:fe02:461b: time<1ms
Reply from fe80::260:2bff:fe02:461b: time<1ms

Ping statistics for fe80::260:2bff:fe02:461b:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 4ms, Average = 1ms

C:\>ping -6 fe80::260:2bff:fe02:42e2

Pinging fe80::260:2bff:fe02:42e2 with 32 bytes of data:
Reply from fe80::260:2bff:fe02:42e2: time<1ms
Reply from fe80::260:2bff:fe02:42e2: time<1ms
Reply from fe80::260:2bff:fe02:42e2: time<1ms
Reply from fe80::260:2bff:fe02:42e2: time<1ms

Ping statistics for fe80::260:2bff:fe02:42e2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

.... it seems that Bonjour for Windows simply won't recognize a published host unless it has an IPv4 address. Is this a bug In Bonjour for Windows, or am I doing something wrong? FWIW, my Windows 7 machine is running Bonjour 2.0.2.0

I apologize for this blatantly newbie-ish question, but I'd like to do this "the right way" and not just muck about until it seems to work, and the documentation I have doesn't seem to address this case.

Currently, a Debian Linux box that I am working with has the following /etc/network/interfaces file:

auto lo
iface lo inet loopback
auto bond0
iface bond0 inet dhcp
pre-up modprobe bonding mode=active-backup miimon=100 primary=eth0
pre-up ip link set bond0 up
pre-up /sbin/ifenslave bond0 eth0
pre-up /sbin/ifenslave bond0 eth1

The above works fine, and mostly does what I want -- on boot, the box comes up and the two Ethernet jacks are used for failover/redundancy (i.e. the box uses the first jack for communications if it is working, otherwise it uses the second jack).

However, for my purposes I don't want to use IPv4 or DHCP. I'd like the box to come up with bond0 using ONLY the box's IPv6 self-assigned address (i.e. fe80::whatever:it:is) and no other IP addresses (well... loopback is okay). What's the proper way to specify this? Should I change "iface bond0 inet dhcp" to "iface bond0 inet6" ? Remove that line completely? Something else? Ideally I'd like to be able to use the exact same file on multiple boxes without modifying it for each one, btw.

First, the situation: I've got a Linux computer with two eSATA drive bays that accept removable SSD drives. I'm trying to write a little GUI application that makes it easier for the user to mount/unmount/format/backup/etc the drives that he puts into these bays.

It all mostly works. One small problem, however, is that I don't know how to find out any information about what's on the inserted drive(s) until after the drives have been successfully mounted.

So, for example, if the user inserts a drive that I can't mount (e.g. because it is unformatted, or formatted with an unexpected filesystem), all my app can say about it is "Drive failed to mount".

This isn't very satisfactory, because if the drive is unformatted, the user will probably want to format it... but if the drive contains data from an unrecognized filesystem, the user will probably NOT want to format it.... or at least, I want to be able to warn him that by doing so he'll be erasing potentially valuable data.

So my question is: is there any method for querying some basic information (especially filesystem-type) from a drive that doesn't require that the drive already be mounted? Or do I just have to try to mount it with various known filesystems until one of the mount attempts succeeds, and give a vague "be careful" message if none of them do?

In case it matters, the paths I use to mount the drives in the drive bays are:

/dev/disk/by-path/pci-0000:00:1f.2-scsi-2:0:0:0
/dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0

I've got a program that sends out a IPv6 multicast packet (to ff12::2:0:8afb:382b:c053:85f%en1) every 50ms. I've got it running on a very simple single-computer LAN (Mac mini <-wifi-> Linksys wifi router <-cat5-> DSL modem <-> Internet). In my test there are no computers joined to this multicast group (i.e. nobody is listening to these packets)

My problem is that when this program is running, the Mac's WiFi performance drops by over 50%. Presumably the problem is that all of these multicast packets are eating up a lot of my WiFi bandwidth and causing congestion... but I don't understand why the packets are being transmitted at all. It was my understanding that multicast uses a spanning tree algorithm to ensure that multicast packets are only routed to hosts that are actually interested in receiving them. If that's true, and given that there are no other computers on my LAN joined to this multicast address, shouldn't my Mac realize that and not actually send out any packets unless/until some other host joins the multicast group? Or is the spanning tree culling only implemented at the switch, and not by hosts themselves?

We're seeing some very strange behavior on one of our LANs, I'm hoping someone might recognize what it is.

The LAN consists of several Linux boxes and several MacOS/X boxes, all connected by 100MBps Ethernet through a switch. It's not connected to the Internet.

What we've found is that when we put one of the MacOS/X boxes (a Mac Pro) to sleep (via the the "Sleep" menu item in the Apple menu), the LAN stops working for about 10 seconds. We see this in the applications we are running, and also we set up "ping" processes from and to various of the other machines and we can see the ping times go way up (to the 2000-8000 millisecond range!) during this 10 second period.

After 10 seconds, the network seems to recover and work again. As a test, we tried just disconnecting the Mac Pro's Ethernet cable (without putting the Mac to sleep), and that had no effect on the LAN... it's only when the Mac goes to sleep that trouble occurs.

Any thoughts on what might be wrong, or how to figure this out?

First, a little background: my company makes an audio streaming device that is a headless, rack-mounted Linux box with a Solid State e-SATA drive attached. The drive is formatted with ext4. The users can connect to the system using Samba/CIFS to upload new audio files or access existing ones. There is also custom software for streaming out audio over the network.

This is all fine. The only problem is that the users are audio people, not computer people, and see the system as a 'black box', not as a computer. Which means that at the end of the day, they aren't going to ssh in to the box and enter "/sbin/shutdown -h"; they are just going to cut power to the rack and leave, and expect things to still work properly the next day.

Since ext4 has journalling, journal checksumming, etc, this mostly works. The only time it doesn't work is when someone uploads a new file via Samba and then cuts power to the system before the uploaded data has been fully flushed to the disk. In that case, they come in the next day and find that their new file has been truncated or is missing entirely, and are unhappy.

My question is, what is the best way to avoid this problem? Is there a way to get smbd to call "sync" at the end of every upload? (Performance on uploads isn't so important, since they only happen occasionally). Or is there a way to tell ext4 to automatically flush within a few seconds of any change to a file? (Again, performance can be sacrificed for safety here) Should I set a particular write-ordering mode, activate barriers, etc?

My apologies if this is an obvious question, I'm a newbie as far as redundant networking goes, and I'm not sure what keywords to Google for. My application scenario is this:

The obvious thing to do in order to get network redundancy is to have two high-speed Ethernet switches, and connect each Linux server to both switches. That way if one of the switches fails, or somebody accidentally cuts through an Ethernet cable, communication can continue via the other cable/switch, and the system will remain fully functional.

My question is, is there a way to make the redundancy 100% transparent to the application software? (By transparent, I mean that the application software shouldn't have to know or care that there is more than one Ethernet port; ideally it would only see an eth0 and not an eth1... and if data stops flowing over one of the two physical Ethernet ports for whatever reason, the application software shouldn't have to detect the fault or do anything special in order to keep working).

Extra bandwidth isn't important for my purposes (one "lane" of gigabit ethernet is fast enough), but simplicity and reliability are.