MTIN is now a FLexOptic Reseller

MTIN typically is not a reseller for many product lines, for several reasons.  We like to be vendor agnostic and not chasing sales commissions on products, and we are not in the business of stocking product.

Having said this, we now have a reseller relationship with  They have optics you can code for a huge variety of manufacturers.  WISP clients will be intersted to know they support the following vendors:
and a whole bunch more. There are over 150 vendors supported.

The optics are coded with a product called Flexbox. The flexbox has several features to it such as coding, wavelength tuning of DWDM, distance analyzer, power measurement, and diagnostics.

FLEXBOX series - Configure Universal Transceivers | CSFP, SFP, SFP+, XFP, QSFP+, QSFP28, SFP28, CFP, CFP2, CFP4

We are working on some reviews, how-tos and other tutorials for these products. At the very least we are recommending everyone have a few optics of the form factors you use for compatibility troubleshooting.  If you have a device that you wonder if it is recognizing your optics correctly you can pull out this kit, code an optic for your device, and go on with troubleshooting.   Very handy for vendor optic issues.

If this is something you are interested in send us an e-mail for a quote on a starter kit and look for more information coming soon.

Client subnet in DNS requests

Some Light Reading:

Many Authoritative nameservers today return different replies based
   on the perceived topological location of the user.  These servers use
   the IP address of the incoming query to identify that location.
   Since most queries come from intermediate recursive resolvers, the
   source address is that of the recursive rather than of the query

   Traditionally and probably still in the majority of instances,
   recursive resolvers are reasonably close in the topological sense to
   the stub resolvers or forwarders that are the source of queries.  For
   these resolvers, using their own IP address is sufficient for
   authority servers that tailor responses based upon location of the

   Increasingly though a class of remote recursive servers has arisen
   that serves query sources without regard to topology.  The motivation
   for a query source to use a remote recursive server varies but is
   usually because of some enhanced experience, such as greater cache
   security or applying policies regarding where users may connect.
   (Although political censorship usually comes to mind here, the same
   actions may be used by a parent when setting controls on where a
   minor may connect.)  When using a remote recursive server, there can
   no longer be any assumption of close proximity between the originator
   and the recursive, leading to less than optimal replies from the
   authority servers.

   A similar situation exists within some ISPs where the recursive
   servers are topologically distant from some edges of the ISP network,
   resulting in less than optimal replies from the authority servers.

   This draft defines an EDNS0 option to convey network information that
   is relevant to the message but not otherwise included in the
   datagram.  This will provide the mechanism to carry sufficient
   network information about the originator for the authority server to
   tailor responses.  It also provides for the authority server to
   indicate the scope of network addresses that the tailored answer is
   intended.  This EDNS0 option is intended for those recursive and
   authority servers that would benefit from the extension and not for
   general purpose deployment.  It is completely optional and can safely
   be ignored by servers that choose not to implement it or enable it.

   This draft also includes guidelines on how to best cache those
   results and provides recommendations on when this protocol extension
   should be used.

For those of you running BIND here is some practical information